Yeah... but what if you wrote the same bit over and over. It probably only takes one bit to fail before the bank is useless. At 34 MB/s, that's only 1/34 s.
What happens in reality is that piracy is not stopped, those interested in a pirated copy can still easily get it, while the legitimate and paying user is bothered, treated like a soon to be criminal, and that legitimate uses of the software are at times prevented.
So.... when has this ever not been the case? The "innocent" always suffer because of the "non-innocent". There are many cases where this is shown:
Drug laws: Because idiots can't handle themselves and commit crimes and such while using them or to gain use of them, recreational use of certain drugs is against the law. Similarly, the issue with alcohol and tobacco (of course, there are health issues and who has to pay the bills in there too).
Gun laws: Because idiots use them to commit crimes, people who have legitimate recreational uses for guns (target shooting, hunting, etc.) are penalized.
Speeding: Because there are folks who refuse to admit that they don't know how to drive fast (and therefore speed and cause accidents), there are laws that penalize us all. (Yes, I know that there are more complex decisions that go into traffic speed laws, but this is an example.)
Mostly, we all have to suffer because of idiots (of which there are way too many). If people stopped being stupid and behaved, then maybe we could do away with a bunch of laws and practices that penalize the innocent (and usually the majority). (Yes, I know this argument is flawed.)
I agree with his notion that being able to easily migrate from one system to another is important. However, this is not entirely unrelated to open source, because open source software makes it easy to migrate between platforms. If there are no binaries available for your platform, you can recompile your application. If the platform itself has bugs, you can fix them. And probably most importantly at all, if your application and the platform aren't interoperating properly, you can read both sets of source code and figure out why.
Yes, but the relationship in your statement is backwards, in my opinion.
Ease of migration isn't related to Open Source. Open Source is related to ease of migration. It may sound nit-picky but Open Source did not bring about ease of migration. To some degree, the desire for ease of migration caused Open Source to come about.
That being said... the majority of the ease of migration provided for by OSS is between different ports of Linux and not necessarily between Linux and other operating systems. The Linux Zealots' goal isn't necessarily about choice. Their version of the world isn't so different from Microsoft's in that there is only one OS... the only difference is which OS it is.
There are some good robotics folks in Canada. Most notably are the Canadarm (robotic arm on the Shuttle) and a few deep diving ocean exploration vehicles that have very advanced robotic arms and such on them (one of which, with some cosmetic changes, was used in "The Abyss").
I have even seen many folks who don't know basic data structure concepts either... things that should be as ingrained into a programmer as breathing is... things like trees, hashes, linked lists, arrays, etc.
There's nothing like talking to a new hire and who is fretting over how to store some data for later lookup and saying something like "just put it in a dictionary or something" and seeing his eyes glaze over.
Getting a degree (actually, in many scientific/engineering fields) isn't as much about what you know as about having exposure to lots of different things, knowing how to find out what you don't know, and having the discipline to do it right and follow through instead of beating it until it fits and then declaring yourself "done".
The *most* common things that I have seen about non-CS (non- engineering/scientific) programmers (especially folks who "taught themselves") is that 1. Degrees are a waste of time because you don't need them and that they are a shining example of not needing a degree (when in many cases, they are a shining example of why you need a degree - they just don't, and won't, realize it). 2. They are always right, even when confronted with indisputable evidence that shows that they might not be right.
They also typically make lots of obvious mistaken conclusions that a basic algorithms or data structures class would have easily avoided.
How can this fellow's opinion turn on a dime like that? Is he really credible to a corporate audience? I don't think people are quite that stupid or so easily manipulated.
Quite easily actually... there's an old saying... there's no greater fanatic than the converted. I've seen staunch supporters of something do a 180 within a day when exposed to something they thought impossible (switching from Windows to Linux or from Linux to Windows... yes, I've seen both).
I have a Linux box at home based on an Athlon 64 3000+ (SuSE 9.1 Professional AMD64 actually) and I like it quite a bit. I plan to upgrade a few more of my machines in the near-term to Athlon 64s as well. The Athlon 64 is still, without a doubt, better bang for the buck in my book.
I think there are a few new instructions in the i486, but it's been a while so I can't remember for sure. The 486 architecture is definitely different though, as another poster said... the 486 was a pipelined implementation where the 386 wasn't fully pipelined. That in itself is a pretty major difference between the two.
1. They are targetted at entirely diffrent markets.
So? Target market is irrelevant.
2. The Xeon has more cache than any current desktop P4
From the article (bold added by me):
Performance Test Configuration Processor(s): Athlon 64 3500+ (130nm, 2.2GHz, 512KB L2 Cache) Intel Xeon 3.6GHz (90nm, 1MB L2 Cache) RAM: 2 x 512MB PC-3500 CL2 (400MHz) 2 x 512MB PC2-3200 CL3 (400MHz) Registered Memory Timings: Default Hard Drives Seagate 120GB 7200RPM IDE (8Mb buffer) Operating System(s): SuSE 9.1 Professional (64 bit) Linux 2.6.4-52-default Linux 2.6.4-52-smp Compiler: GCC 3.3.3 Motherboards: NVIDIA NForce3 250 Reference Board SuperMicro Tumwater X6DA8-G2 (Only 1 CPU)
All currently shipping Prescotts (non-Celeron flavor) have 1M L2 cache. This chip is essentially a Prescott.
3. The clockspeed diffrence is substantial, even with the Athlons IPC being higher.
So, when has this not ever been the case for Athlon XP/64 comparison against a P4?
4. the Xeon is using ECC Ram, so though it is unlikely, if a memory error occurred in the A64 it would take a performance hit, this wouldn't happen on a Xeon system.
If the A64 had a memory error, it would either crash because some instruction got munged or ignore it and use the munged value as a legit value. There'd be no other way for the A64 to know that the value was munged unless there was code in the program itself to check the results for correctness... which would also be the same code that ran on the Xeon box.
If *anything*, the ECC RAM would slow down the Xeon machine because ECC RAM typically has at least one clock cycle penalty over non-ECC RAM. So, your argument would be that "although the Xeon has slower memory than the A64, it still shows those performance figures".
5. The article is invalid on the fact that there are several errors in performance recording, including using a 32bit performance example against a 64bit performance example. And also the fact that none of the tests were labelled as to whether they were 64bit or 32bit tests.
This would be a legit reason.
6. If they are exactly the same, please explain to me why an A64 3400+ Absolutely stomped all over a Prescott 3.4ghz? We have nothing to go on that would give us reason to believ that 64bit would make such a drastic change. And also P4s scale no where near as well as Athlons, so I somehow doubt that the extra 200mhz will make that significant of a change.
Because we are talking about 64-bit mode now. We can make lots of speculations... Perhaps the Prescott was crippled a little by having to support the 64-bit instructions, that is why it is poorer performance than the Northwood at the same clock? They optimized the 64-bit at the expense of the 32-bit in the hardware? I don't know. However, "because it wasn't like that before" is not sufficient reason to say it isn't like that now. That is just as valid as your saying that "because it wasn't like that before, we shouldn't expect it to be different now".
Ah... now I see what you meant... the 486SX *is* a 486DX with the coprocessor disabled. I didn't disagree with that... The part that I disagreed with is that the 486DX is basically a 386DX that runs faster, which is what the "see above" remark was about... where I said that they weren't the same.
Perhaps because the application were workstation and server apps?
And this matters... how again? Explain the difference by using real information other than some belief that the word "Xeon" imparts some magical capabilities upon the Prescott core that wouldn't otherwise be there other than the (current) support of SMP and EM64T...
heh... That's almost what this is... a Prescott with SMP and EM64T enabled. There's really no other differences to speak of. If there are, please elaborate for us.
Anandtech's claim that the upcoming PIV's are exactly like the Nocona chips are specious if for no other reason than the fact that there would be no reason to differentiate the two.
Then you haven't followed the differences between Xeons and Pentium 4s. They are basically the same core with differences in FSB, SMP capability, L2 cache sizes, and sometimes the presence of an L3 cache. Otherwise, the core is the same.
In this case, the Xeon in the article is practically the same as existing Prescotts with the exception of having SMP and EM64T enabled.
Man... lots of folks know very little about Xeon it seems.... expecially the differences between the Xeon and Pentium 4 lines.
Most of the posts denouncing this benchmark say that "Intel server chip vs. AMD Desktop chip" without knowing what they are saying at all... It's almost as if they are grasping at straws in order to invalidate this kick against their puppy.
Hint: The Xeon in the review and currently available Prescotts differ in SMP capability, EM64T being enabled, and that's about it.
That's what they said... It was handy... and even then, the differences between that Xeon and a Prescott aren't that much (they have the same L2 cache and the same FSB and the same core other than the EM64T being enabled).
If folks quit trying to read this thing as Anand saying that "EM64T Prescotts are so much better than Athlon 64s" and simply look at the performance figures for just being data unto themselves, I'm sure lots of folks' blood pressures will go down.
Larger Cache will increase the performance regardless of how good the FPU is.
Well... not strictly true. If your code/data can fit into 256K, then there will be little difference between a 512K or a 1M L2 cache on your problem. As a general guideline, though, larger caches are better.
I agree though, the POVRay score was quite different and kind of invalidates the comment about the FPU. I do think that most of the benchmarks were integer related as well.
Still... what was shown there is interesting in that we've been seeing as to how EM64T "sucks" and is "broken", etc from a number of folks over the last few months... it doesn't necessarily look that way from those benchmarks.
I dunno if you were calling my post BS or not, but we basically were saying the same thing.
However, your comment about The 486 was the first x86 to have a full pipeline which is why most instructions were 1 cycle. is not strictly true. The 486 can retire an instruction per clock. This isn't the same thing as the instruction taking one clock to execute.
To which "classes" are you referring? It is common knowledge that the Xeon and the Pentium4 are practically identical in anything that matters. The only real difference between the two is SMP support. The Xeon has it, it is disabled on the Pentium4... just like the Athlon 64 with 1M L2 cache is an Opteron with a different pinout and the MP capabilities "turned off".
IF there is such a difference between the Xeon and the Pentium4, please post links as to where there are benchmarks that clearly show the difference.
In fact, in the past, the Xeon has lagged behind the Pentium4 in FSB speeds while having larger L2 (and sometimes L3 caches). This Xeon is nothing more than a Prescott with SMP capabilities turned on.
What's silly is that people are using marchitecture in an attempt to apologize for AMD. If you use that, you also have to support the MHz Myth...
I personally have 7 AMD Athlon XP and Athlon 64 machines, so I'm not an Intel fanboi.
You mean the 486DX is the 386DX with the 387 built in.
Nope. There are a number of architectural differences between the i386DX and the i486DX other than the FPU being on-chip.
The 486SX is the 486DX with the coprocessor disabled, which is basically a 386DX that runs faster.
No, see above.
The 386SX is a 16 bit CPU on the outside in stead of the 32 bit 386DX and higher.
The i386SX has a 16-bit memory interface (external pins to the CPU cores) instead of the 32-bit memory interface of the i386DX. Otherwise, they are basically the same.
IIRC a pentium is actually two 486DX's using the same pipeline.
Nope. The Pentium is quite a bit different from an i486DX architecturally... not the least being that the two integer pipelines are asymetric in function, which means that it cannot simply be "two i486DXs using the same pipeline".
The Xeon has exactly the same size cache as the current Prescott cores that are desktop CPUs. To disqualify the Xeon simply for that reason means that you can't compare Prescotts to Athlon 64s either.
Slashdot Mirror
Yeah... but what if you wrote the same bit over and over. It probably only takes one bit to fail before the bank is useless. At 34 MB/s, that's only 1/34 s.
What happens in reality is that piracy is not stopped, those interested in a pirated copy can still easily get it, while the legitimate and paying user is bothered, treated like a soon to be criminal, and that legitimate uses of the software are at times prevented.
So.... when has this ever not been the case? The "innocent" always suffer because of the "non-innocent". There are many cases where this is shown:
Drug laws: Because idiots can't handle themselves and commit crimes and such while using them or to gain use of them, recreational use of certain drugs is against the law. Similarly, the issue with alcohol and tobacco (of course, there are health issues and who has to pay the bills in there too).
Gun laws: Because idiots use them to commit crimes, people who have legitimate recreational uses for guns (target shooting, hunting, etc.) are penalized.
Speeding: Because there are folks who refuse to admit that they don't know how to drive fast (and therefore speed and cause accidents), there are laws that penalize us all. (Yes, I know that there are more complex decisions that go into traffic speed laws, but this is an example.)
Mostly, we all have to suffer because of idiots (of which there are way too many). If people stopped being stupid and behaved, then maybe we could do away with a bunch of laws and practices that penalize the innocent (and usually the majority). (Yes, I know this argument is flawed.)
I agree with his notion that being able to easily migrate from one system to another is important. However, this is not entirely unrelated to open source, because open source software makes it easy to migrate between platforms. If there are no binaries available for your platform, you can recompile your application. If the platform itself has bugs, you can fix them. And probably most importantly at all, if your application and the platform aren't interoperating properly, you can read both sets of source code and figure out why.
Yes, but the relationship in your statement is backwards, in my opinion.
Ease of migration isn't related to Open Source. Open Source is related to ease of migration. It may sound nit-picky but Open Source did not bring about ease of migration. To some degree, the desire for ease of migration caused Open Source to come about.
That being said... the majority of the ease of migration provided for by OSS is between different ports of Linux and not necessarily between Linux and other operating systems. The Linux Zealots' goal isn't necessarily about choice. Their version of the world isn't so different from Microsoft's in that there is only one OS... the only difference is which OS it is.
Can it handle running, as if from a dragon?!?!?!
There are some good robotics folks in Canada. Most notably are the Canadarm (robotic arm on the Shuttle) and a few deep diving ocean exploration vehicles that have very advanced robotic arms and such on them (one of which, with some cosmetic changes, was used in "The Abyss").
I have even seen many folks who don't know basic data structure concepts either... things that should be as ingrained into a programmer as breathing is... things like trees, hashes, linked lists, arrays, etc.
There's nothing like talking to a new hire and who is fretting over how to store some data for later lookup and saying something like "just put it in a dictionary or something" and seeing his eyes glaze over.
Getting a degree (actually, in many scientific/engineering fields) isn't as much about what you know as about having exposure to lots of different things, knowing how to find out what you don't know, and having the discipline to do it right and follow through instead of beating it until it fits and then declaring yourself "done".
The *most* common things that I have seen about non-CS (non- engineering/scientific) programmers (especially folks who "taught themselves") is that
1. Degrees are a waste of time because you don't need them and that they are a shining example of not needing a degree (when in many cases, they are a shining example of why you need a degree - they just don't, and won't, realize it).
2. They are always right, even when confronted with indisputable evidence that shows that they might not be right.
They also typically make lots of obvious mistaken conclusions that a basic algorithms or data structures class would have easily avoided.
How can this fellow's opinion turn on a dime like that? Is he really credible to a corporate audience? I don't think people are quite that stupid or so easily manipulated.
Quite easily actually... there's an old saying... there's no greater fanatic than the converted. I've seen staunch supporters of something do a 180 within a day when exposed to something they thought impossible (switching from Windows to Linux or from Linux to Windows... yes, I've seen both).
Heh, I agree with you :)
I have a Linux box at home based on an Athlon 64 3000+ (SuSE 9.1 Professional AMD64 actually) and I like it quite a bit. I plan to upgrade a few more of my machines in the near-term to Athlon 64s as well. The Athlon 64 is still, without a doubt, better bang for the buck in my book.
I think there are a few new instructions in the i486, but it's been a while so I can't remember for sure. The 486 architecture is definitely different though, as another poster said... the 486 was a pipelined implementation where the 386 wasn't fully pipelined. That in itself is a pretty major difference between the two.
1. They are targetted at entirely diffrent markets.
So? Target market is irrelevant.
2. The Xeon has more cache than any current desktop P4
From the article (bold added by me):
Performance Test Configuration
Processor(s): Athlon 64 3500+ (130nm, 2.2GHz, 512KB L2 Cache)
Intel Xeon 3.6GHz (90nm, 1MB L2 Cache)
RAM: 2 x 512MB PC-3500 CL2 (400MHz)
2 x 512MB PC2-3200 CL3 (400MHz) Registered
Memory Timings: Default
Hard Drives Seagate 120GB 7200RPM IDE (8Mb buffer)
Operating System(s): SuSE 9.1 Professional (64 bit)
Linux 2.6.4-52-default
Linux 2.6.4-52-smp
Compiler: GCC 3.3.3
Motherboards: NVIDIA NForce3 250 Reference Board
SuperMicro Tumwater X6DA8-G2 (Only 1 CPU)
All currently shipping Prescotts (non-Celeron flavor) have 1M L2 cache. This chip is essentially a Prescott.
3. The clockspeed diffrence is substantial, even with the Athlons IPC being higher.
So, when has this not ever been the case for Athlon XP/64 comparison against a P4?
4. the Xeon is using ECC Ram, so though it is unlikely, if a memory error occurred in the A64 it would take a performance hit, this wouldn't happen on a Xeon system.
If the A64 had a memory error, it would either crash because some instruction got munged or ignore it and use the munged value as a legit value. There'd be no other way for the A64 to know that the value was munged unless there was code in the program itself to check the results for correctness... which would also be the same code that ran on the Xeon box.
If *anything*, the ECC RAM would slow down the Xeon machine because ECC RAM typically has at least one clock cycle penalty over non-ECC RAM. So, your argument would be that "although the Xeon has slower memory than the A64, it still shows those performance figures".
5. The article is invalid on the fact that there are several errors in performance recording, including using a 32bit performance example against a 64bit performance example. And also the fact that none of the tests were labelled as to whether they were 64bit or 32bit tests.
This would be a legit reason.
6. If they are exactly the same, please explain to me why an A64 3400+ Absolutely stomped all over a Prescott 3.4ghz? We have nothing to go on that would give us reason to believ that 64bit would make such a drastic change. And also P4s scale no where near as well as Athlons, so I somehow doubt that the extra 200mhz will make that significant of a change.
Because we are talking about 64-bit mode now. We can make lots of speculations... Perhaps the Prescott was crippled a little by having to support the 64-bit instructions, that is why it is poorer performance than the Northwood at the same clock? They optimized the 64-bit at the expense of the 32-bit in the hardware? I don't know. However, "because it wasn't like that before" is not sufficient reason to say it isn't like that now. That is just as valid as your saying that "because it wasn't like that before, we shouldn't expect it to be different now".
From the article (bold added by me):
Performance Test Configuration
Processor(s): Athlon 64 3500+ (130nm, 2.2GHz, 512KB L2 Cache)
Intel Xeon 3.6GHz (90nm, 1MB L2 Cache)
RAM: 2 x 512MB PC-3500 CL2 (400MHz)
2 x 512MB PC2-3200 CL3 (400MHz) Registered
Memory Timings: Default
Hard Drives Seagate 120GB 7200RPM IDE (8Mb buffer)
Operating System(s): SuSE 9.1 Professional (64 bit)
Linux 2.6.4-52-default
Linux 2.6.4-52-smp
Compiler: GCC 3.3.3
Motherboards: NVIDIA NForce3 250 Reference Board
SuperMicro Tumwater X6DA8-G2 (Only 1 CPU)
All Prescotts have 1M L2 cache as well (other than the Celeron-D).
Ah... now I see what you meant... the 486SX *is* a 486DX with the coprocessor disabled. I didn't disagree with that... The part that I disagreed with is that the 486DX is basically a 386DX that runs faster, which is what the "see above" remark was about... where I said that they weren't the same.
Sure thing... here's wikipedia's take on it...
http://en.wikipedia.org/wiki/486SX
Perhaps because the application were workstation and server apps?
And this matters... how again? Explain the difference by using real information other than some belief that the word "Xeon" imparts some magical capabilities upon the Prescott core that wouldn't otherwise be there other than the (current) support of SMP and EM64T...
heh... That's almost what this is... a Prescott with SMP and EM64T enabled. There's really no other differences to speak of. If there are, please elaborate for us.
Anandtech's claim that the upcoming PIV's are exactly like the Nocona chips are specious if for no other reason than the fact that there would be no reason to differentiate the two.
Then you haven't followed the differences between Xeons and Pentium 4s. They are basically the same core with differences in FSB, SMP capability, L2 cache sizes, and sometimes the presence of an L3 cache. Otherwise, the core is the same.
In this case, the Xeon in the article is practically the same as existing Prescotts with the exception of having SMP and EM64T enabled.
Man... lots of folks know very little about Xeon it seems.... expecially the differences between the Xeon and Pentium 4 lines.
Most of the posts denouncing this benchmark say that "Intel server chip vs. AMD Desktop chip" without knowing what they are saying at all... It's almost as if they are grasping at straws in order to invalidate this kick against their puppy.
Hint: The Xeon in the review and currently available Prescotts differ in SMP capability, EM64T being enabled, and that's about it.
That's what they said... It was handy... and even then, the differences between that Xeon and a Prescott aren't that much (they have the same L2 cache and the same FSB and the same core other than the EM64T being enabled).
If folks quit trying to read this thing as Anand saying that "EM64T Prescotts are so much better than Athlon 64s" and simply look at the performance figures for just being data unto themselves, I'm sure lots of folks' blood pressures will go down.
Larger Cache will increase the performance regardless of how good the FPU is.
Well... not strictly true. If your code/data can fit into 256K, then there will be little difference between a 512K or a 1M L2 cache on your problem. As a general guideline, though, larger caches are better.
I agree though, the POVRay score was quite different and kind of invalidates the comment about the FPU. I do think that most of the benchmarks were integer related as well.
Still... what was shown there is interesting in that we've been seeing as to how EM64T "sucks" and is "broken", etc from a number of folks over the last few months... it doesn't necessarily look that way from those benchmarks.
I dunno if you were calling my post BS or not, but we basically were saying the same thing.
However, your comment about The 486 was the first x86 to have a full pipeline which is why most instructions were 1 cycle. is not strictly true. The 486 can retire an instruction per clock. This isn't the same thing as the instruction taking one clock to execute.
To which "classes" are you referring? It is common knowledge that the Xeon and the Pentium4 are practically identical in anything that matters. The only real difference between the two is SMP support. The Xeon has it, it is disabled on the Pentium4... just like the Athlon 64 with 1M L2 cache is an Opteron with a different pinout and the MP capabilities "turned off".
IF there is such a difference between the Xeon and the Pentium4, please post links as to where there are benchmarks that clearly show the difference.
In fact, in the past, the Xeon has lagged behind the Pentium4 in FSB speeds while having larger L2 (and sometimes L3 caches). This Xeon is nothing more than a Prescott with SMP capabilities turned on.
What's silly is that people are using marchitecture in an attempt to apologize for AMD. If you use that, you also have to support the MHz Myth...
I personally have 7 AMD Athlon XP and Athlon 64 machines, so I'm not an Intel fanboi.
What "more on die memory" and "other enhancements"?
The Prescott (the latest P4) has 1M L2 cache, which is the same as this Xeon has. This Xeon is basically the same CPU, with just a different name.
You mean the 486DX is the 386DX with the 387 built in.
Nope. There are a number of architectural differences between the i386DX and the i486DX other than the FPU being on-chip.
The 486SX is the 486DX with the coprocessor disabled, which is basically a 386DX that runs faster.
No, see above.
The 386SX is a 16 bit CPU on the outside in stead of the 32 bit 386DX and higher.
The i386SX has a 16-bit memory interface (external pins to the CPU cores) instead of the 32-bit memory interface of the i386DX. Otherwise, they are basically the same.
IIRC a pentium is actually two 486DX's using the same pipeline.
Nope. The Pentium is quite a bit different from an i486DX architecturally... not the least being that the two integer pipelines are asymetric in function, which means that it cannot simply be "two i486DXs using the same pipeline".
So you compare a highend server/workstation proc to a highend desktop proc. Sure the server chip will win the majority of the benchmarks
Why do you say this? There isn't really difference between the Xeon and the P4 (Prescott in this case).
The Xeon has exactly the same size cache as the current Prescott cores that are desktop CPUs. To disqualify the Xeon simply for that reason means that you can't compare Prescotts to Athlon 64s either.