The phenomina of bad code is not unique to commercial software. Despite the popularity and success of some open source software, there is a lot of bad code out there. Anyone who can figure out the three letters 'gcc' seems to be able to post their code to sunsite or freshmeat.
Despite having the source code, the amount of time and effort required to understand a large amount of code is overwhelming. How many programmers would volunteer to fix Windows bugs?
Consider the lesson of the WWIV BBS software, which was an experiment in Open Source commercial software. The program was written by a C instructor, who distributed the code (although you had to pay). People would "learn to program" by changing the source code, and once the code worked, distributing it.
The sad fact is, most people can't program. The classes don't really teach anything other than the syntax of the language, which they can then put on their resume and get the fast money.
What I'd like to see is: First, quality standards for software. Software is the only form of engineering in which there is not some sort of standard of how many or what sort of bugs are acceptable.
It's possible that C/C++ are not the best languages for Application development. Research has gone into developing new languages, such as Eiffel.
Lastly, software quality ends at the programmer. Think before you vomit unmentionable code at the feet of the rest of us.
I was going to address bus speed in my previous posting, but I digressed too far. I will attempt to remedy that here.
Yes! Bus speed is an issue, but the solution is non-trivial. Those lines on your motherboard have electrical characteristics, based on length and frequency. Simply put, they become radio-transmitters! Even the layout rules for the 100Mhz/133Mhz buses are tight.
Inside the chip, it's a lot easier to push frequency because your lengths are *very* short. Thus, it's likely that there will be consumer-level 1Ghz CPUs next year or so. But the bus speed is still down near 100Mhz (even if you try tricks like double pumping it).
One solution to this problem is to put more on the same chip. These systems on a chip have been created less than happily before, as you lose most upgradeability, *but* you get to use whatever bus speeds you want internally. You also save a few bucks, and a few inches.
If I had to guess (and my crystal ball is down for the RH 6.1 Upgrade;) ), I'd think that as cpus become a commodity item, that systems on a chip will be more and more prevalent. I'd expect alliances between nVidia and 3DFX with the AMDs, VIAs, and even Intel (despite their snapping up Cirrus Logic).
Remember, though, that if your code fits in cache and takes advance of new hints for caching present in the K7/P3, you might not even notice the faster bus speed.
My wish for improving computer performance would not be a faster bus, faster clock speeds - it would be software:
An excellent optimizing compiler!
(And, a Linux port of Intel's VTune would be fairly sweet too).
(I haven't checked lately, but last I looked there was nothing that would generate code that took advantage of P6 instructions, despite conditional moves that would eliminate many branches and give a noticeable speed boost). Here's a nice little advocacy experiment for those so inclined.. Compare the output of VC6.0 under NT (running console), versus latest Cygnus build of GCC with various algorithms, Sieve of E, etc.
Unless you have specifically programmed for an SMP machine, it is easy to think of it as a cure-all. I can speak from experience, and say that this is not the case.
First, a quick summary. SMP, or Symmetric Multi-Processor systems are so called because each processor is effectively equal to the other processors. There are a number of different architectures, either using clustering of procs sharing the same bus, or clusters sharing the same memory, or even clusters expanded out.
As a breakdown:
AMD SMP-to-be: processors in a 'cluster' share the same memory, I/O arbitrated by a complex chipset.
Intel SMP: up to four processors in a 'cluster' share the same bus, arbitrated by a complex bus protocol.
Beowulf - Each cluster has its own bus, I/O, but communication is much slower.
Now, one would think that performance would increase linearly for each CPU? So if you have two CPUs, your performance is 2X? Four, for 4X? Don't bet on it.
In every case, you have to factor in:
(1) SMP programming requires different algorithms to take advantage of multiple CPUs. Some tasks require too much communication, or are too linear to benefit much from having another processor. Remember that adage that you can't have a baby in one month by getting nine women pregnant!
(2) SMP split by 'thread' has limitations as well. Operating system complexity rises dramatically.. As far as I have read, the fined grained SMP necessary to make this work is still under development in all free operating systems. And this code is so complex and the tools to debug this sort of code are so expensive that it is likely to be quite some time. Linux is blessed that some large companies are contributing to the codebase for SMP support -- Intel among them if I recall. Other than operating system issues, this requires many of your programs be re-written to benefit (depending on what you want to do).
(3) In every case, there is a shared resource or cost. If every processor wants to access the memory, who "wins"? Likewise for the bus on the P6 SMP.
I've read numbers at one pointed that showed the most drop-off at four. I suspect that Intel, going for 'profitability', made four the maximum for many reasons based on simulations and probably electrical limitations.
As a final point, look at the Errata listings for Intel processors, now that they are public. Given that Intel has the resources to extensively test their processors, look at how many of these relate to having more than one processor communicating?
Now, consider that with your AMD SMP system, you have a chipset that has to handle complexities of multiple processors sharing resources, with less resources to figure out what could go wrong.
In this light, AMDs decision to focus on a single processor environment makes a huge amount of sense. If you get a huge boost out of parallelism, buy the cheapest Mhz/$ and Beowulf it!
Slashdot Mirror
Despite having the source code, the amount of time and effort required to understand a large amount of code is overwhelming. How many programmers would volunteer to fix Windows bugs?
Consider the lesson of the WWIV BBS software, which was an experiment in Open Source commercial software. The program was written by a C instructor, who distributed the code (although you had to pay). People would "learn to program" by changing the source code, and once the code worked, distributing it.
The sad fact is, most people can't program. The classes don't really teach anything other than the syntax of the language, which they can then put on their resume and get the fast money.
What I'd like to see is: First, quality standards for software. Software is the only form of engineering in which there is not some sort of standard of how many or what sort of bugs are acceptable.
It's possible that C/C++ are not the best languages for Application development. Research has gone into developing new languages, such as Eiffel.
Lastly, software quality ends at the programmer. Think before you vomit unmentionable code at the feet of the rest of us.
Yes! Bus speed is an issue, but the solution is non-trivial. Those lines on your motherboard have electrical characteristics, based on length and frequency. Simply put, they become radio-transmitters! Even the layout rules for the 100Mhz/133Mhz buses are tight.
Inside the chip, it's a lot easier to push frequency because your lengths are *very* short. Thus, it's likely that there will be consumer-level 1Ghz CPUs next year or so. But the bus speed is still down near 100Mhz (even if you try tricks like double pumping it).
One solution to this problem is to put more on the same chip. These systems on a chip have been created less than happily before, as you lose most upgradeability, *but* you get to use whatever bus speeds you want internally. You also save a few bucks, and a few inches.
If I had to guess (and my crystal ball is down for the RH 6.1 Upgrade ;) ), I'd think that as cpus become a commodity item, that systems on a chip will be more and more prevalent. I'd expect alliances between nVidia and 3DFX with the AMDs, VIAs, and even Intel (despite their snapping up Cirrus Logic).
Remember, though, that if your code fits in cache and takes advance of new hints for caching present in the K7/P3, you might not even notice the faster bus speed.
My wish for improving computer performance would not be a faster bus, faster clock speeds - it would be software:
An excellent optimizing compiler!
(And, a Linux port of Intel's VTune would be fairly sweet too).
(I haven't checked lately, but last I looked there was nothing that would generate code that took advantage of P6 instructions, despite conditional moves that would eliminate many branches and give a noticeable speed boost). Here's a nice little advocacy experiment for those so inclined.. Compare the output of VC6.0 under NT (running console), versus latest Cygnus build of GCC with various algorithms, Sieve of E, etc.
First, a quick summary. SMP, or Symmetric Multi-Processor systems are so called because each processor is effectively equal to the other processors. There are a number of different architectures, either using clustering of procs sharing the same bus, or clusters sharing the same memory, or even clusters expanded out.
As a breakdown:
AMD SMP-to-be: processors in a 'cluster' share the same memory, I/O arbitrated by a complex chipset.
Intel SMP: up to four processors in a 'cluster' share the same bus, arbitrated by a complex bus protocol.
Beowulf - Each cluster has its own bus, I/O, but communication is much slower.
Now, one would think that performance would increase linearly for each CPU? So if you have two CPUs, your performance is 2X? Four, for 4X? Don't bet on it.
In every case, you have to factor in:
(1) SMP programming requires different algorithms to take advantage of multiple CPUs. Some tasks require too much communication, or are too linear to benefit much from having another processor. Remember that adage that you can't have a baby in one month by getting nine women pregnant!
(2) SMP split by 'thread' has limitations as well. Operating system complexity rises dramatically.. As far as I have read, the fined grained SMP necessary to make this work is still under development in all free operating systems. And this code is so complex and the tools to debug this sort of code are so expensive that it is likely to be quite some time. Linux is blessed that some large companies are contributing to the codebase for SMP support -- Intel among them if I recall. Other than operating system issues, this requires many of your programs be re-written to benefit (depending on what you want to do).
(3) In every case, there is a shared resource or cost. If every processor wants to access the memory, who "wins"? Likewise for the bus on the P6 SMP.
I've read numbers at one pointed that showed the most drop-off at four. I suspect that Intel, going for 'profitability', made four the maximum for many reasons based on simulations and probably electrical limitations.
As a final point, look at the Errata listings for Intel processors, now that they are public. Given that Intel has the resources to extensively test their processors, look at how many of these relate to having more than one processor communicating?
Now, consider that with your AMD SMP system, you have a chipset that has to handle complexities of multiple processors sharing resources, with less resources to figure out what could go wrong.
In this light, AMDs decision to focus on a single processor environment makes a huge amount of sense. If you get a huge boost out of parallelism, buy the cheapest Mhz/$ and Beowulf it!