That's exactly my point. My guess is that "Linux License" is actually a support contract. Notice that the cost is 3 x 35K, which is consistent with the rest of their "analysis" (3 years), and $35K sounds about right for the premium contract. However, there is no mention of support contract for Windows/Exchange solution (which is NOT free). Apparently they read the recent/. article and decided to get support from Phychic Friends Network instead:-)
You can stop reading it as soon as you reach the line
Linux License (1 x $250 + 3 x $35K) $105,250
Also, there was no mention of what "groupware" they were using under Linux. The only piece of information in this article is that Exchange is insanely expensive and requires a lot of hardware, but we kinda knew this already.
How quickly do we forget that CPRM proposal was defeated and Maxtor was one of the high-profile companies to vote against it. IBM, Microsoft, Iomega and others wanted to push it through.
What I really don't understand is why MS fucked Alpha down. In my experience Alpha is STILL pretty nice player in server level (my uni runs mostly on alphas/ x86+linux)
Ah, that's because DEC did all the porting. Yes, you heard it right: DEC did Microsoft's job for them in order to get NT on their own hardware. (Similarly, SGI ported NT to MIPS). A year or two after DEC was bought out by Compaq, they told Microsoft they are not going to do porting for them any more. Microsoft decided to kill Alpha port and made the spin that it was all Compaq's fault. There was a story on The Register about it maybe a year ago.
DoJ can ask the judge for a preliminary injunction against XP, that is, an injunction that is issued *before* the trial. The judge will do it if 1) he/she thinks that there is high likelihood that he/she will come to the same conclusion after the trial, and 2) the plaintiff can demonstrate irreparable harm if the injunction is not issued immediately. In this case it's easy: MS is arrogantly using the same anti-competitive tactics they were sued for, and if injunction is not issued before XP is out, it will be too late.
Microsoft is well aware of that. This is why they are trying very hard to delay the case and push forwrard the release of XP. First they re-appealed to the appeals court (The Register had a funny title for this "Microsoft asks the court to find it a little bit not guiltier":-) Then they appealed to the Supreme Court and simultaneously asked the appeals court to put the case on hold until the supreme's decision. Appeals court refused. The case is moving forward.
Two questions remain: will DoJ ask for preliminary injunction against XP? (so far they have given several indications that they will). Will the judge grant it? That remains to be seen....
"The glibc situation is even more frightening if one realizes the story
behind it. When I started porting glibc 1.09 to Linux (which
eventually became glibc 2.0) Stallman threatened me and tried to force
me to contribute rather to the work on the Hurd."
Exactly how can you "force" someone to contribute to a project? Especially since this library is released under LGPL, Drepper would be free to port it to whatever he wanted. Give me more details and some evidence. I'm not about buy rhetoric.
If i'm not reading this wrong, Drepper is the maintainer of glibc, and so should decide what goes on
You may have noticed the list of the main contributors. This is not, repeat not, a one-man project. Therefore, no one person should have complete control.
I find this completely unacceptable and can assure
everybody that I consider none of the code I contributed to glibc
(which is quite a lot) to be as part of the GNU project and so a major
part of what Stallman claims credit for is simply going away.
That's funny cause glibc is GNU libc. This guy contributes some code to it and now suddenly it's no longer a part of the GNU project. Interesting. If I take the Linux kernel, contribute to it, then turn around and say I don't consider it a part of the Linux project, would that go over well?
Sure, Drepper is an important contributor, but he is by no means the only contributor. Therefore, it seems to me rather that he is the control freak here: when he realized that other contributors have a say in "his" project, he started whining. This is nothing more than his ego.
So let me get this straight: some guy accuses RMS of "hostile takeover" of a *GNU* project. This guy makes some strong claims in his article. He uses terms like "conspiracy", "embrace and extend", "stab in the back", etc. Such extraordinary claims require extraordinary evidence... and he offers none. There are only two pieces of information in the article:
1) Steering Comittee was formed so that one person (the whining guy) does not have complete control over the project
2) glibc license was changed from LGPL 2.0 to LGPL 2.1.
And this is supposed to be bad how? How does that justify the claim that RMS is a "control freak"? Everything else in the article is pure rhetoric without even a shed of evidence.
People, please, before you do your usual "some guy good, RMS bad" knee-jerk reaction read the damn article and think. glibc is GNU libc, it is not a one man's project. It sounds to me like this guy is a control freak -- he started whining after he realized that other people have a say in the project development. So yeah, this entire article is a troll.
I wouldn't be surprised if this was exactly what he thought but for a very different reason than what you think and imply in your message. The reason is the design of the kernel. Hurd was a microkernel -- a completely new design at the time. Linux was a traditional monolithic kernel. Microkernels were supposed to take over the world, so, from that standpoint HURD was, in fact, the future. FWIW, RMS was not the only one who thought Linux was a waste of time. Once upon the time there was a long flamewar in which Andrew Tannenbaum (the creator of Minix) claimed that Linus would have failed his OS course if he ever took it.
The DoJ will ask the district court to issue a preliminary injunction against XP. That is, the injunction to be issued *before* the trial actually begins. The judge will do it if 1) he has strong reason to believe that he will arrive to the same conclusion after the trial and 2) DoJ can demonstrate irreparable harm if injunction is delayed. In this case, it's easy: 1) MS continues to use exact same monopolistic practices they were sued for, and 2) if injunction is not issued immediately, XP will be released and it will be too late. So yeah, DoJ has a good chance of stopping XP release.
You obviously didn't pay attention to our last election.
I did. Canadian election happened on November 27 (several weeks after US) and we knew the results the next morning (several weeks before US). The entire country used paper ballots which you mark with pencil and drop in the box. No pregnant chads. No butterfly ballots. No punchcards. No nonsense.
If KDE can run on a diskless machine with 128MB RAM (with an NFS-mounted/home directory)
- this would be a real winner.
A diskless X terminal runs only the X server. It is irrelevant what window manager and apps you are using -- the system requirements would still be the same. (All the apps, including the window manager run on the app server). So, even 32 MB would do. The only thing you need to ensure is that the client and network are able to handle the resolution and color depth you want to use. Obviously the higher the resolution and color depth the more bandwidth and client resourses it will take, but still at 1280x1024x16 bit color a low-end pentium with 32 MB RAM and 100MB/s network would do just fine.
Increase scalability. Apart from RAM, KDE spawns a bunch of processes. On a workstation this isn't a problem,
but scale it up to a several hundred users on a large box and things can get a bit ugly. (Haven't pushed it this far -
extrapolating for a handful of trial users.) Do you really need so many kdeinit jobs?
Apparently you are not aware of shared memory. If two users run the same app, they will not use twice the memory. The program text is shared among all instances, only data is private. In fact using a one big box shared amoung a number of clients is a lot more efficient than lots of less-powerful workstations both in terms of memory and CPU utilization: 90% of the time a workstation is idle (a secretary types a document; a developer types code, etc.) and 10% of the time it is too slow for a given task (start word processor; compile program, etc.)
As for the kdeinit processes they each run a different thing. They are not copies of the same process. The explanation I heard is that kdeinit is used as a wrapper because Linux's ld works slow for C++ apps. (Somebody in the know, please post a more detailed expanation about it.)
Are you aware how much MS "thin client" network would cost in licensing fees? Let me give you a clue. You'd have to pay for windows 9x to run it on each "thin client", NT Terminal Server, and client access licenses. The license cost makes NT thin client network unfeasible.
Yes, one of the most frustrating things I see is the lack of humour. Sigh... I guess next time I'll have to use tags.
But hey it's not too bad, maybe I'll use the car advice after all.:-)
I've been using public transportation for over a year and I'm getting really tired of it. So finally I decided to get a car. The next question is which model do I get? What's a good starter version? I'm just looking to get the feel of it and to play around a little.
Oh man, fro your last post I got the impression that you saw the light. Apparently I was mistaken.
Actually, I was providing a counter-example to a specific comment of yours: If software was optimized for P4 and Athlon, P4 would still be pathetic.
OK, let me repeat what I said in my last post. Your benchmarks show that P4 with RDRAM is faster than Athlon with DDR DRAM. This does *not* imply that P4 is faster than Athlon. To give you a mathematical analogy, if you know that A + B > C + D, you cannot claim that A > C : you do not have enough information for that. (This is especially true when you know that B > D). In the case of your benchmarks, you cannot claim that P4 is faster than Athlon, especially since you know that two channels of RDRAM have a greater bandwidth than once channel of DDR DRAM.
They do all favor high memory bandwidth systems, but that's the nature of the beast in HPC -- almost all scientific applications are memory bandwidth hungry.
Who cares if the benchmarks use different algorithms? They all test exactly the same thing: memory bandwidth. This statement of yours actually makes my point above stronger. You admit that all of these benchmarks are highly dependent on memory bandwidth. It appears that you agree with my supposition that these benchmarks depend more on the memory bandwidth than the CPU speed (integer sort for example would be 100% memory I/O). Yet you are still trying to claim that P4 is faster than Athlon. These benchmarks do not prove that. They prove that the bandwidth of two channels of RDRAM is greater than that of one channel of DDR DRAM, but we kind of knew that already, didn't we?
So, your counterexample is invalid and my claim stands. I really think that we are starting to go around in circles.
And I suppose the fact that width of the P4's memory bus interface (256 bits wide) is twice as wide as
that of the Athlon (128 bits wide) has no influence on the memory bandwidth available?
That's just plain not true. The P4 memory bus is 32 bit wide (16 bits for each RDRAM channel). Athlon memory bus is 64 bit wide (one DDR DRAM channel). You are probably thinking of the width of the L2 cache datapath, which is 256 bit for P3 and P4 (I don't recall what it is for Athlon).
Or that I can't
get an optimizing compiler for the Athlon that's comparable to the Intel Fortran compiler?
I think I said it 3 times already, but I'll repeat it again for posterity. AMD has never had software optimized for their CPUs. They always fought an uphill battle. Yet they still managed to beat the shit out of intel.
Look, I don't have the luxury of caring which processor is better in a "fair" test with the same memory,
etc. -- my job is to figure out which system (processor/memory/IO/etc.) is fastest for our users'
applications
That's fine and that's a reasonable thing to do. But you cannot use your benchmarks to claim that P4 is faster than Athlon. You benchmarks show that P4 with RDRAM is faster than Athlon with DDR DRAM. This does not imply that P4 is faster than Athlon, which is what you were trying to claim. Also, you cannot make such a claim based on only one benchmark.
Once again, I have no problem with people trying to find the best system for their needs. I have a problem with unsubstantiated claims.
BTW, I suspect that for your particular application, memory bandwidth matters more than the CPU speed. So you may actually be benchmarking memory instead of CPU.
P4 Xeons have been available for several weeks now; we've had a dual P4 machine on site for about a month.
OK, I was not aware of that, but tell me where I can actually buy them. I looked at Dell's site before I posted. If Dell doesn't have them, nobody else does.
The NAS Parallel Benchmarks would seem to indicate you are wrong.
You pointed to the single (type of) benchmark that makes P4 look good, though not because of P4's virtues. P4 has two channels of RDRAM giving it 1600 * 2 = 3200 MB/s of memory bandwidth. The Athlon machine in the benchmark you pointed to had a single channel of DDR DRAM, giving it 2128MB/s of memory bandwidth. Fluid Dynamic simulation is one of the _few_ things that can really take advantage of greater memory bandwidth. Therefore P4 wins this round by riding on Rambus's coat-tails. Prove me wrong. Point me to the same benchmark where both P4 and Athlon have the same type of memory (both support SDRAM now, you know).
x87 FPU, sure. But that was only on for backwards compatability. Once SSE2 turned on (which, unlike the
Athlon, is contained in a seperate unit on the processor and does not run in the FPU), the Pentium 4's FPU
becomes a force to be reckoned with (surely you saw the SPEC scores?)
That's like saying Windows supports win32 binaries only for backwards compatibility. P4's FPU really stinks and now all of a sudden intel wants everybody to switch to SSE. Well, sure it will help (and, as you noted, it will also help Athlon which currently supports SSE, and future versions will support SSE2 as well), but high-precision floating point arithmetic is impossible with SSE, so x87 FPU is not going to go away. As for having x87 FPU and SSE in separate ALUs, well, that won't really matter if, as you claim, everybody will up and switch to SSE, will it? So my claim stands: P4's FPU is pathetic. If software was optimized for P4 and Athlon, P4 would still be pathetic. If future software uses SSE2, Athlon's performance would improve just as much as that of P4. And, furthermore: using the "compiler is not able to take advantage of some wiz-bang feature" is a strawman's argument. I repeat: AMD has always fought an uphill battle and has never had software optimized specifically for their CPUs, yet they still managed to beat the crap out of intel.
They're called Intel Xeons. While it's true that it's not technically a "Pentium 4" by name, it is a P4
A Xeon is based on P3 core. Xeon is just an overpriced P3 with a larger L2 cache. My claim stands: there is no such thing as dual P4. If and when Xeons with P4 core are relased, then we'll talk.
Oh man, technical errors abound.
The P4 is actually faster than the Athlon for scientific computing, except for the compiler fact
Pentium 4 has an absolutely pathetic floating point performance. Even Pentium 3 at 1000MHz outperforms Pentium 4 at 1500MHz on floating point. See here for example. Your claim that Pentium 4 can do 3 floating point operations per clock cycle is nothing more than pulling numbers out of your ass. (unless you can somehow substantiate your ridiculous claim).
The P4 looses to the Athlon simply by the reason that the compilers can not use the vector instructions
properly.
AMD has never had code optimized for their CPUs. They have always fought an uphill battle. Yet they managed to beat the crap out of intel in absolute performance (price/performance they had for a long time). The whole compiler crap is a strawman's argument. AMD has 3Dnow instructions which nobody uses. If current software was optimized for AMD, P4 would look even more pathetic.
Why anyone would be an Itanium instead of a dual P4/Athlon beats me.
Uhhh, perhaps because there is no such thing as dual P4?
It has less on-chip cache than a Celeron (128kb total)!! Sure it's packaged with
a lot of sram, but still.
I don't know how to break it to you, but 1) Celeron has exactly 128KB L2 cache, and 2) SRAM stands for Static RAM, which is used for cache (as opposed to Dynamic RAM, which is used for the main memory).
Symantec has equally stupid patents. Why, wasn't it less than a year ago since Symantec was granted a patent on... virus definition updates. That puts Symantec right in line with McAffe and Amazon. Fortunately, Symantec management came to their sences and decided not to sue over it, realizing that the patent would be thrown out by the first judge who looked at it.
Sounds good, but it is unenforcible. How do you know they released all the specs? "You changed your file formats!" "No we didn't. Fuck off."
Also, I doubt this remedy would ever be ordered.
BTW, I would also add to the list the right of OEMs to customize the desktop (not the current crap of install MSN if you are installing AOL).
Slashdot Mirror
here is a more relevant link:
t ro -pal-isr-primer.html
http://www.merip.org/palestine-israel_primer/in
here is a good start. Note that this barely scratches the surface. Read more articles at zmag.org
That's exactly my point. My guess is that "Linux License" is actually a support contract. Notice that the cost is 3 x 35K, which is consistent with the rest of their "analysis" (3 years), and $35K sounds about right for the premium contract. However, there is no mention of support contract for Windows/Exchange solution (which is NOT free). Apparently they read the recent /. article and decided to get support from Phychic Friends Network instead :-)
Also, there was no mention of what "groupware" they were using under Linux. The only piece of information in this article is that Exchange is insanely expensive and requires a lot of hardware, but we kinda knew this already.
How quickly do we forget that CPRM proposal was defeated and Maxtor was one of the high-profile companies to vote against it. IBM, Microsoft, Iomega and others wanted to push it through.
Ah, that's because DEC did all the porting. Yes, you heard it right: DEC did Microsoft's job for them in order to get NT on their own hardware. (Similarly, SGI ported NT to MIPS). A year or two after DEC was bought out by Compaq, they told Microsoft they are not going to do porting for them any more. Microsoft decided to kill Alpha port and made the spin that it was all Compaq's fault. There was a story on The Register about it maybe a year ago.
IANAL, yada, yada, yada....
:-) Then they appealed to the Supreme Court and simultaneously asked the appeals court to put the case on hold until the supreme's decision. Appeals court refused. The case is moving forward.
DoJ can ask the judge for a preliminary injunction against XP, that is, an injunction that is issued *before* the trial. The judge will do it if 1) he/she thinks that there is high likelihood that he/she will come to the same conclusion after the trial, and 2) the plaintiff can demonstrate irreparable harm if the injunction is not issued immediately. In this case it's easy: MS is arrogantly using the same anti-competitive tactics they were sued for, and if injunction is not issued before XP is out, it will be too late.
Microsoft is well aware of that. This is why they are trying very hard to delay the case and push forwrard the release of XP. First they re-appealed to the appeals court (The Register had a funny title for this "Microsoft asks the court to find it a little bit not guiltier"
Two questions remain: will DoJ ask for preliminary injunction against XP? (so far they have given several indications that they will). Will the judge grant it? That remains to be seen....
Exactly how can you "force" someone to contribute to a project? Especially since this library is released under LGPL, Drepper would be free to port it to whatever he wanted. Give me more details and some evidence. I'm not about buy rhetoric.
If i'm not reading this wrong, Drepper is the maintainer of glibc, and so should decide what goes on
You may have noticed the list of the main contributors. This is not, repeat not, a one-man project. Therefore, no one person should have complete control.
I find this completely unacceptable and can assure everybody that I consider none of the code I contributed to glibc (which is quite a lot) to be as part of the GNU project and so a major part of what Stallman claims credit for is simply going away.
That's funny cause glibc is GNU libc. This guy contributes some code to it and now suddenly it's no longer a part of the GNU project. Interesting. If I take the Linux kernel, contribute to it, then turn around and say I don't consider it a part of the Linux project, would that go over well?
Sure, Drepper is an important contributor, but he is by no means the only contributor. Therefore, it seems to me rather that he is the control freak here: when he realized that other contributors have a say in "his" project, he started whining. This is nothing more than his ego.
So let me get this straight: some guy accuses RMS of "hostile takeover" of a *GNU* project. This guy makes some strong claims in his article. He uses terms like "conspiracy", "embrace and extend", "stab in the back", etc. Such extraordinary claims require extraordinary evidence... and he offers none. There are only two pieces of information in the article:
1) Steering Comittee was formed so that one person (the whining guy) does not have complete control over the project
2) glibc license was changed from LGPL 2.0 to LGPL 2.1.
And this is supposed to be bad how? How does that justify the claim that RMS is a "control freak"? Everything else in the article is pure rhetoric without even a shed of evidence.
People, please, before you do your usual "some guy good, RMS bad" knee-jerk reaction read the damn article and think. glibc is GNU libc, it is not a one man's project. It sounds to me like this guy is a control freak -- he started whining after he realized that other people have a say in the project development. So yeah, this entire article is a troll.
I wouldn't be surprised if this was exactly what he thought but for a very different reason than what you think and imply in your message. The reason is the design of the kernel. Hurd was a microkernel -- a completely new design at the time. Linux was a traditional monolithic kernel. Microkernels were supposed to take over the world, so, from that standpoint HURD was, in fact, the future. FWIW, RMS was not the only one who thought Linux was a waste of time. Once upon the time there was a long flamewar in which Andrew Tannenbaum (the creator of Minix) claimed that Linus would have failed his OS course if he ever took it.
#include
The DoJ will ask the district court to issue a preliminary injunction against XP. That is, the injunction to be issued *before* the trial actually begins. The judge will do it if 1) he has strong reason to believe that he will arrive to the same conclusion after the trial and 2) DoJ can demonstrate irreparable harm if injunction is delayed. In this case, it's easy: 1) MS continues to use exact same monopolistic practices they were sued for, and 2) if injunction is not issued immediately, XP will be released and it will be too late. So yeah, DoJ has a good chance of stopping XP release.
I did. Canadian election happened on November 27 (several weeks after US) and we knew the results the next morning (several weeks before US). The entire country used paper ballots which you mark with pencil and drop in the box. No pregnant chads. No butterfly ballots. No punchcards. No nonsense.
A diskless X terminal runs only the X server. It is irrelevant what window manager and apps you are using -- the system requirements would still be the same. (All the apps, including the window manager run on the app server). So, even 32 MB would do. The only thing you need to ensure is that the client and network are able to handle the resolution and color depth you want to use. Obviously the higher the resolution and color depth the more bandwidth and client resourses it will take, but still at 1280x1024x16 bit color a low-end pentium with 32 MB RAM and 100MB/s network would do just fine.
Increase scalability. Apart from RAM, KDE spawns a bunch of processes. On a workstation this isn't a problem, but scale it up to a several hundred users on a large box and things can get a bit ugly. (Haven't pushed it this far - extrapolating for a handful of trial users.) Do you really need so many kdeinit jobs?
Apparently you are not aware of shared memory. If two users run the same app, they will not use twice the memory. The program text is shared among all instances, only data is private. In fact using a one big box shared amoung a number of clients is a lot more efficient than lots of less-powerful workstations both in terms of memory and CPU utilization: 90% of the time a workstation is idle (a secretary types a document; a developer types code, etc.) and 10% of the time it is too slow for a given task (start word processor; compile program, etc.)
As for the kdeinit processes they each run a different thing. They are not copies of the same process. The explanation I heard is that kdeinit is used as a wrapper because Linux's ld works slow for C++ apps. (Somebody in the know, please post a more detailed expanation about it.)
Are you aware how much MS "thin client" network would cost in licensing fees? Let me give you a clue. You'd have to pay for windows 9x to run it on each "thin client", NT Terminal Server, and client access licenses. The license cost makes NT thin client network unfeasible.
Yes, one of the most frustrating things I see is the lack of humour. Sigh... I guess next time I'll have to use tags. :-)
But hey it's not too bad, maybe I'll use the car advice after all.
I've been using public transportation for over a year and I'm getting really tired of it. So finally I decided to get a car. The next question is which model do I get? What's a good starter version? I'm just looking to get the feel of it and to play around a little.
oops I screed up html. pressed post too soon.
They do all favor high memory bandwidth systems, but that's the nature of the beast in HPC -- almost all scientific applications are memory bandwidth hungry.
Who cares if the benchmarks use different algorithms? They all test exactly the same thing: memory bandwidth. This statement of yours actually makes my point above stronger. You admit that all of these benchmarks are highly dependent on memory bandwidth. It appears that you agree with my supposition that these benchmarks depend more on the memory bandwidth than the CPU speed (integer sort for example would be 100% memory I/O). Yet you are still trying to claim that P4 is faster than Athlon. These benchmarks do not prove that. They prove that the bandwidth of two channels of RDRAM is greater than that of one channel of DDR DRAM, but we kind of knew that already, didn't we?
So, your counterexample is invalid and my claim stands. I really think that we are starting to go around in circles.
That's just plain not true. The P4 memory bus is 32 bit wide (16 bits for each RDRAM channel). Athlon memory bus is 64 bit wide (one DDR DRAM channel). You are probably thinking of the width of the L2 cache datapath, which is 256 bit for P3 and P4 (I don't recall what it is for Athlon).
Or that I can't get an optimizing compiler for the Athlon that's comparable to the Intel Fortran compiler?
I think I said it 3 times already, but I'll repeat it again for posterity. AMD has never had software optimized for their CPUs. They always fought an uphill battle. Yet they still managed to beat the shit out of intel.
Look, I don't have the luxury of caring which processor is better in a "fair" test with the same memory, etc. -- my job is to figure out which system (processor/memory/IO/etc.) is fastest for our users' applications
That's fine and that's a reasonable thing to do. But you cannot use your benchmarks to claim that P4 is faster than Athlon. You benchmarks show that P4 with RDRAM is faster than Athlon with DDR DRAM. This does not imply that P4 is faster than Athlon, which is what you were trying to claim. Also, you cannot make such a claim based on only one benchmark.
Once again, I have no problem with people trying to find the best system for their needs. I have a problem with unsubstantiated claims.
BTW, I suspect that for your particular application, memory bandwidth matters more than the CPU speed. So you may actually be benchmarking memory instead of CPU.
OK, I was not aware of that, but tell me where I can actually buy them. I looked at Dell's site before I posted. If Dell doesn't have them, nobody else does.
The NAS Parallel Benchmarks would seem to indicate you are wrong.
You pointed to the single (type of) benchmark that makes P4 look good, though not because of P4's virtues. P4 has two channels of RDRAM giving it 1600 * 2 = 3200 MB/s of memory bandwidth. The Athlon machine in the benchmark you pointed to had a single channel of DDR DRAM, giving it 2128MB/s of memory bandwidth. Fluid Dynamic simulation is one of the _few_ things that can really take advantage of greater memory bandwidth. Therefore P4 wins this round by riding on Rambus's coat-tails. Prove me wrong. Point me to the same benchmark where both P4 and Athlon have the same type of memory (both support SDRAM now, you know).
Well, not yet. This is what they are fighting about. But if Rambus prevails, this is what will happen. Let's just hope they die a horrible death.
x87 FPU, sure. But that was only on for backwards compatability. Once SSE2 turned on (which, unlike the Athlon, is contained in a seperate unit on the processor and does not run in the FPU), the Pentium 4's FPU becomes a force to be reckoned with (surely you saw the SPEC scores?)
That's like saying Windows supports win32 binaries only for backwards compatibility. P4's FPU really stinks and now all of a sudden intel wants everybody to switch to SSE. Well, sure it will help (and, as you noted, it will also help Athlon which currently supports SSE, and future versions will support SSE2 as well), but high-precision floating point arithmetic is impossible with SSE, so x87 FPU is not going to go away. As for having x87 FPU and SSE in separate ALUs, well, that won't really matter if, as you claim, everybody will up and switch to SSE, will it? So my claim stands: P4's FPU is pathetic. If software was optimized for P4 and Athlon, P4 would still be pathetic. If future software uses SSE2, Athlon's performance would improve just as much as that of P4. And, furthermore: using the "compiler is not able to take advantage of some wiz-bang feature" is a strawman's argument. I repeat: AMD has always fought an uphill battle and has never had software optimized specifically for their CPUs, yet they still managed to beat the crap out of intel.
They're called Intel Xeons. While it's true that it's not technically a "Pentium 4" by name, it is a P4
A Xeon is based on P3 core. Xeon is just an overpriced P3 with a larger L2 cache. My claim stands: there is no such thing as dual P4. If and when Xeons with P4 core are relased, then we'll talk.
Pentium 4 has an absolutely pathetic floating point performance. Even Pentium 3 at 1000MHz outperforms Pentium 4 at 1500MHz on floating point. See here for example. Your claim that Pentium 4 can do 3 floating point operations per clock cycle is nothing more than pulling numbers out of your ass. (unless you can somehow substantiate your ridiculous claim).
The P4 looses to the Athlon simply by the reason that the compilers can not use the vector instructions properly.
AMD has never had code optimized for their CPUs. They have always fought an uphill battle. Yet they managed to beat the crap out of intel in absolute performance (price/performance they had for a long time). The whole compiler crap is a strawman's argument. AMD has 3Dnow instructions which nobody uses. If current software was optimized for AMD, P4 would look even more pathetic.
Why anyone would be an Itanium instead of a dual P4/Athlon beats me.
Uhhh, perhaps because there is no such thing as dual P4?
It has less on-chip cache than a Celeron (128kb total)!! Sure it's packaged with a lot of sram, but still.
I don't know how to break it to you, but 1) Celeron has exactly 128KB L2 cache, and 2) SRAM stands for Static RAM, which is used for cache (as opposed to Dynamic RAM, which is used for the main memory).
Symantec has equally stupid patents. Why, wasn't it less than a year ago since Symantec was granted a patent on... virus definition updates. That puts Symantec right in line with McAffe and Amazon. Fortunately, Symantec management came to their sences and decided not to sue over it, realizing that the patent would be thrown out by the first judge who looked at it.
Sounds good, but it is unenforcible. How do you know they released all the specs? "You changed your file formats!" "No we didn't. Fuck off."
Also, I doubt this remedy would ever be ordered.
BTW, I would also add to the list the right of OEMs to customize the desktop (not the current crap of install MSN if you are installing AOL).
___