One of the nice benefits of rewriting software (or for that matter - redesigning a system) is the lessons learned.
The conventional approach to system engineering is to write a long and detailed spec, then implement the system and finally test it (eventually at the customer's site).
This approach tends to create many unnecessary features and many times important and useful features are missing because they were not anticipated. At this point the product is already late and these features get added as an afterthought (patches...)
The other way: write a simple prototype with the minimum features deemed necessary. Then continue refining or rewriting implementing all lessons learned and feedback received from users. This way unnecessary features are never implemented or get stripped early on, while useful features are continuously refined.
This plan sounds very similar to the one that works great for Akamai:
These guys offer an ISP their servers free of charge and 24x7 tech support. The ISP now has more satisfied customers (traffic gets faster to the customer) and less traffic to the Internet core.
Akami gets to expand its network. The main difficulty is probably maintenance and support.
64 bit mode does not guarantee better performance. In fact, although the UltraSparc chips we have support both 32bit and 64bit software (and we do VLSI CAD -- which is very CPU and memory intensive) most software vendors recommend using the 32bit versions unless your design requires >4GB of memory.
32bit software usually means better use of the processor cache (and memory in general - unless you have many 64bit quantities. Floating point numbers perhaps...)
... and more registers (that AMD64 has) does not necessarily means better performance. A modern x86 processor already uses much more than the software visible limit number of registers. On the fly register renaming is used to improve performnace. It is not immediately clear that adding more software visible registers will improve performance significantly. More registers mean more data to save during context switches, more complicated logic inside the processor, etc.
These new supercomputers are all massively parallel systems. They work well for specialized numerical algorithms and were designed with these algorithms in mind.
It is much more difficult to use them for most applications most of us can think of. For example, VLSI CAD software (simulation/analysis/synthesis) is very compute intesive. However, these systems usually do not even take advantage of the multiple CPUs in a typical general purpose SMP system. You have to manually partition designs and sometimes loose the advantages of global optimization.
Since this feature is not available for all books (and, in fact, wasn't available for any book in my wishlist) the results are necessarily very biased.
Thus, your searches will tend to return more results from books that are fully indexed.
Now that I think about it - this is a major incentive for publishers to get their books indexed.
There were times when I really liked my HP28S. It was cool and made my life in the university much easier.
However, anyway you look at it, any PDA being sold today is *much* more capable (except perhaps for the lack of a decent keyboard).
I mean, if you want to do numeric calculations just run a scaled-down version fo MATLAB (or Octave for those who prefer Free software).
If you need symbolic calculations run Derive, MuPad, Yacas or whatever...
All of these programs are much more capable than the HP calculators. It is also much easier to program them. The HP programming language (Forth-like) is really annoying.
So aside from the historical value and perhaps running some existing applications this not progress - quite the contrary.
Come on... PAE is just plain old bank switching technology. Just like my old 128KB memory extended Apple//e (remember those?)
The software presses a button and bingo one bank gets swapped out and another swapped in! This is good enough for a single application system but definitely not for a multitasking multiuser modern OS.
This is a far cry from the processor's own memory management unit -- no memory protection, no support in the page tables, etc.
This is a hack. A bad one.
I really like P4s (so fast!). But if/when Hammer becomes a reality it will be the only sensible choice for our servers.
The only good reason to switch to 64-bit computing is *memory*. The 4GB limit is a real problem for modern CAD tools.
Where I work (a semiconductors company) we use Sparc64 systems exactly for that reason.
In fact, the CAD tools manufacturers admit that their 64bit versions are *slower* than their 32bit software. The only reason a 64bit version is available is because a lot of customers are hitting the 4GB limit.
The reasons for the performance loss? Well, 64bit software may address more memory but it also CONSUMES more memory.
More importantly the processor's cache can now hold only half the data (if the same program is just recomplied its working set of int's is doubled!).
So for a given processor that have both 32 and 64 bit modes (Sparc, Hammer, PowerPC) the 32 bit mode is preferrable if the application can live with it...
This is what is known today as "ACK traffic shaping". First on the market, I believe, was packeteer (www.packeteer.com) with their PacketShaper.
Unlike most conventional traffic shapers which queue and control the data rate on the outgoing channel, PacketShaper controls the rate of acknowledgements on the reverse channel.
This is usually used to *slow* traffic. I.e., instead of having the router drop packets (thereby wasting resources until the source TCP understands that the net is congested and reduces load) it just slows the ACKs and the sender automatically reduces its sending rate.
Anyway, the real nice thing about the OpenBSD implementation is that they merge their packet filter (pf) with the ALTQ queuing code. Now this is really powerful.
Sounds like a good time for all BSDs to adopt this new combination instead of relying on less-capable mechanisms. E.g. FreeBSD has ipfw for filtering and dummynet for queue management. I don't know how pf compares with ipfw but ALTQ is definitely better than dummynet.
Nimrod.
The reason for all these silly patents...
on
Another Garbage Patent
·
· Score: 2, Insightful
Most big companies try to reward employees for submitting patents on behalf of the company. This usualy involves some bonus to generate some interest at doing these sort of things.
So the fact that the patent has been submitted for approval does not necessarily means Apple intends to use it OR that anyone in Apple actually thinks this is reasonable.
This is just the behavior of a big and inefficient company where engineering time is not considered scarce.
Similarly, the USPTO just "handles" the application without involving any real thinking. People get money for processing these patents -- not for sorting them out.
Nimrod.
Although there will probably never be this OnePerfectTool that will solve all your problems, I tend to agree that some integration can be useful.
For example, one can get the symbolic toolbox for MATLAB and mix symbolic computations with numeric computations.
Similarly, if you are looking for a free alternative you may take a loot at Octave which has an experminal library linking it with GiNaC:
http://users.powernet.co.uk/kienzle/octave/
I personally really like the freedom and ease of expression of a good symbolic algebra system (I have used Maple before). But the truth it, they never have the performance necessary to do any real world computations.
While FPGAs are definitely very useful for specific problems they are way too difficult to use for replacing a general purpose CPU.
At the company I work for we use FPGAs for prototyping our ASIC. Each such Xilinx FPGA costs about $1000! Sure, it beats the hell out of any DSP but it takes an entire development team and a substantial amount of time to design the FPGA equivalent of whatever algorithm you're trying to implement!
It would be nice if we had a C->FPGA compiler but... just take a look at how much difficulty Intel is having with their VLIW Itanic!
Good parallelizing compilers are still a good research project rather than a proven product.
Nonetheless, I would love to get my hands on that machine...
Slashdot Mirror
For startups, it's always nice to show an impressive patent list to investors. Usually easier to get more funding.
Large companies encourage engineers to file patents (they sometimes get a small bonus, etc.) and again almost never try to make any money of them.
These are the reasons we see many less-than-amazing patents filed these days. It *looks* good.
There are some obvious counter-examples but these are usually more sophisticated patents.
The conventional approach to system engineering is to write a long and detailed spec, then implement the system and finally test it (eventually at the customer's site).
This approach tends to create many unnecessary features and many times important and useful features are missing because they were not anticipated. At this point the product is already late and these features get added as an afterthought (patches...)
The other way: write a simple prototype with the minimum features deemed necessary. Then continue refining or rewriting implementing all lessons learned and feedback received from users. This way unnecessary features are never implemented or get stripped early on, while useful features are continuously refined.
It really works.
Nimrod.
These guys offer an ISP their servers free of charge and 24x7 tech support. The ISP now has more satisfied customers (traffic gets faster to the customer) and less traffic to the Internet core.
Akami gets to expand its network. The main difficulty is probably maintenance and support.
-Nimrod.
32bit software usually means better use of the processor cache (and memory in general - unless you have many 64bit quantities. Floating point numbers perhaps...)
It is much more difficult to use them for most applications most of us can think of. For example, VLSI CAD software (simulation/analysis/synthesis) is very compute intesive. However, these systems usually do not even take advantage of the multiple CPUs in a typical general purpose SMP system. You have to manually partition designs and sometimes loose the advantages of global optimization.
So don't run and order your new Blue Gene yet :)
Thus, your searches will tend to return more results from books that are fully indexed.
Now that I think about it - this is a major incentive for publishers to get their books indexed.
There were times when I really liked my HP28S. It was cool and made my life in the university much easier.
However, anyway you look at it, any PDA being sold today is *much* more capable (except perhaps for the lack of a decent keyboard).
I mean, if you want to do numeric calculations just run a scaled-down version fo MATLAB (or Octave for those who prefer Free software).
If you need symbolic calculations run Derive, MuPad, Yacas or whatever...
All of these programs are much more capable than the HP calculators. It is also much easier to program them. The HP programming language (Forth-like) is really annoying.
So aside from the historical value and perhaps running some existing applications this not progress - quite the contrary.
Come on... PAE is just plain old bank switching technology. Just like my old 128KB memory extended Apple //e (remember those?)
The software presses a button and bingo one bank gets swapped out and another swapped in! This is good enough for a single application system but definitely not for a multitasking multiuser modern OS.
This is a far cry from the processor's own memory management unit -- no memory protection, no support in the page tables, etc.
This is a hack. A bad one.
I really like P4s (so fast!). But if/when Hammer becomes a reality it will be the only sensible choice for our servers.
The only good reason to switch to 64-bit computing is *memory*. The 4GB limit is a real problem for modern CAD tools.
Where I work (a semiconductors company) we use Sparc64 systems exactly for that reason.
In fact, the CAD tools manufacturers admit that their 64bit versions are *slower* than their 32bit software. The only reason a 64bit version is available is because a lot of customers are hitting the 4GB limit.
The reasons for the performance loss? Well, 64bit software may address more memory but it also CONSUMES more memory.
More importantly the processor's cache can now hold only half the data (if the same program is just recomplied its working set of int's is doubled!).
So for a given processor that have both 32 and 64 bit modes (Sparc, Hammer, PowerPC) the 32 bit mode is preferrable if the application can live with it...
This is what is known today as "ACK traffic shaping". First on the market, I believe, was packeteer (www.packeteer.com) with their PacketShaper.
Unlike most conventional traffic shapers which queue and control the data rate on the outgoing channel, PacketShaper controls the rate of acknowledgements on the reverse channel.
This is usually used to *slow* traffic. I.e., instead of having the router drop packets (thereby wasting resources until the source TCP understands that the net is congested and reduces load) it just slows the ACKs and the sender automatically reduces its sending rate.
Anyway, the real nice thing about the OpenBSD implementation is that they merge their packet filter (pf) with the ALTQ queuing code. Now this is really powerful.
Sounds like a good time for all BSDs to adopt this new combination instead of relying on less-capable mechanisms. E.g. FreeBSD has ipfw for filtering and dummynet for queue management. I don't know how pf compares with ipfw but ALTQ is definitely better than dummynet.
Nimrod.
Most big companies try to reward employees for submitting patents on behalf of the company. This usualy involves some bonus to generate some interest at doing these sort of things. So the fact that the patent has been submitted for approval does not necessarily means Apple intends to use it OR that anyone in Apple actually thinks this is reasonable. This is just the behavior of a big and inefficient company where engineering time is not considered scarce. Similarly, the USPTO just "handles" the application without involving any real thinking. People get money for processing these patents -- not for sorting them out. Nimrod.
Although there will probably never be this OnePerfectTool that will solve all your problems, I tend to agree that some integration can be useful.
For example, one can get the symbolic toolbox for MATLAB and mix symbolic computations with numeric computations.
Similarly, if you are looking for a free alternative you may take a loot at Octave which has an experminal library linking it with GiNaC:
http://users.powernet.co.uk/kienzle/octave/
I personally really like the freedom and ease of expression of a good symbolic algebra system (I have used Maple before). But the truth it, they never have the performance necessary to do any real world computations.
While FPGAs are definitely very useful for specific problems they are way too difficult to use for replacing a general purpose CPU. At the company I work for we use FPGAs for prototyping our ASIC. Each such Xilinx FPGA costs about $1000! Sure, it beats the hell out of any DSP but it takes an entire development team and a substantial amount of time to design the FPGA equivalent of whatever algorithm you're trying to implement! It would be nice if we had a C->FPGA compiler but... just take a look at how much difficulty Intel is having with their VLIW Itanic! Good parallelizing compilers are still a good research project rather than a proven product. Nonetheless, I would love to get my hands on that machine...