Wednesday, March 28, 2007

Some more thoughts about intel.

Guess you could say this is an archive of sorts. Sometimes it can be difficult to trace down particular points I'll make on a forum, in this case MepisLovers, so what follows is three of the postings I made on this thread.


I'll back up what nlyric says. First, with AMD systems you have the option of using OpenBios/LinuxBios... you don't have that option with Intel systems.

Second, with AMD systems you generally get a performance boost when running in 64bit mode (generally). With Intel, you generally either get a performance hit or no change at all (generally).

With Intel systems you run the problem of more recent Northbridge chipsets using 3rd party Parallel-ATA support (e.g. the well known JMicron issue). With AMD chipsets, almost all existing chipsets work out of the box with Linux, ranging from Via, to SiS, to Nvidia, to ATi, to Ali.


****

The next post was made by another member of the forum

64 bit mode is bunk, a scam. You dont need 64-bit computing. unless a program is, a) optomized for 64 bit when developed (hint: they arent) or b) the program has an need for insanely high numbers (scientific computing), then 64bit is pointless. It takes a computer aproximatel 2x as long to process 64bits as it does 32bits. Now in the future we will need these high numbers but thats quite a ways down the road.

*********

And my direct response.

difference in hardware and software emulation modes.

In the case of processors built to run 64bit operations (e.g. Alpha, PPC, x86-64, Itanium with proper compiling), 64bit operations take just as much time as 32bit operations.

For certain operations like Video editing or Sound editing, running
in 64bits presents a decided advantage, not just in how much can be stored to and read from memory, but at the size of the information that can be processed.

Now, in designs like Intel's Prescott where 64bit is supported as an emulation mode, yes, it does take longer to run 64bit operations than identical 32bit operations.

Although you do have a point. For the average user who just wants to surf the web, listen to a bit of music, maybe write a letter or two, 64bits is overkill. For that matter, 32bits is overkill... and probably 16bits as well.

And... no. Core2 Duo is not consistently beating AMD in performance. I've already been over that line of bunk before, multiple times. Core2 Duo does not scale with clockspeed nor front side bus, and Socket AM2 users who run DDR2 timings of 3,3,3,8 are not beaten by identically clocked Core2 processors.


Nor is Core2 Duo beating AMD in processor efficiency. Now, I haven't personally run any tests measuring the voltage between two identically clocked Socket AM2 and Core2 Duo processors... but HP and Dell have... and their conclusion (as well as Googles), is that the AMD chips are more efficient in power per watt.

The only vendor who presents otherwise is Apple Computers, which is one of the starting points if you are looking for rebuttals of energy efficiency pitting Socket AM2 65watt processors against Core2 Duos

not to mention the 35watt processors of which AMD has 6... and Intel has none.

************

Adrian came back with this comment to 64bit being a scam:

Then why my benchmarks test shows a 20% overall increase in performance? There are problems to switch to 64bit but for some uses that might be well worth, besides you can run 32bit software in 64bit OS (with some caveats)

*************


Then my final post

sorry to bump this thread back up to the top... I forgot a point to make...

Specifically speaking of x86-64, the architecture is designed to run x86 / IA32 code natively. What this means is that if you have a 32bit instruction, it is routed through the processor directly, there is no emulation involved.

The advantage is that the code should work natively in both a 32bit Operating System, and a 64bit Operating System. Theoretically, and in practice by Microsoft's x86-64 design group for Windows XP 64, running 32bit operations in a 64bit OS results in a performance boost.

The reason given is that the Host OS is using registers and memory allocations that the 32bit Application is not set to. The result is that when you are running Multiple 32bit programs at once, the larger number of registers available will minimize the performance impact.

Another item that I somewhat mentioned in... this post:

Quote:
Yes and no to whether or not x86-64 is built for Multi-Core systems.

When AMD was creating the Hammer architecture one of their design priorities was to enable seamless / glueless connection of the processors. So, yes, the x86-64 specification does account for running in a Multi-Core / Multi-Processor configuration.

I don't want to say that it was designed to run in SMP from the start since x86-64 does inherit x86 / IA32.
The point to be made here is that if the Linux kernel writers implement the x86-64 specification correctly, you should be able to run 32bit programs at a faster rate than you can under a 32bit kernel. The simple fact is, not all programs benefit from the jump from 32bits to 64bits, just the same as a lot of programs didn't benefit from the jump between 16bits and 32bits. Honestly... how many bits does Notepad or KATE need anyways? (was tempted to say VI or Emacs, but that's just asking for trouble)


One of the advantages Intel does have right now is that it does have a workable Quad Core processor out. Technically, the processor is not a Quad Core, it's just two of Dual Core processors on one ... substrate? I don't think that's the word... lets just call it packaging.

AMD took the route of having all of their Multi-Core processors being connected by Hypertransport, being true Dual and Quad Core systems. You'll also hear AMD reps say now that they probably should have met Intel's Dual Core + Dual Core with an AthlonX2 + AthlonX2 design. Okay, granted, HP, Dell, Sun, and everybody else involved in the server game is saying that AMD's upcoming Quad Core blows Intel's Kentsfield out of the water ... and the upcoming "true" Quad-Core from Intel... that doesn't change the fact that right now I cannot buy a Quad Core from AMD.

The situation is reminiscent a lot of the time period between the AthlonXP 3200 and the first Athlon64's. I wrote about it last year... here. Back then I stated this:

Quote:
Just the same with Core2 and Athlon64. AMD has already been in this position before. Intel, while slow, is capable of competing. The Athlon64 would not always be the most powerful processor available, AMD has never said otherwise. Just as the Pentium4 3.2ghz went beyond the AthlonXp 3200, something would go beyond Athlon64.
The point is that Intel does hold the very top spot on performance... right now. If you have $1000+ to spend on the processor ALONE... go ahead. Get an Intel.

But... if you are stuck on a budget... why pay more... when you don't GET more?

* on the edit... the ending line kinda stuck out at me. Going back to the first post in this thread I outlined where you would be GETTTING less if you went with Intel... e.g. : the drop of direct PATA support from the most recent chipsets, the lack of any support for OpenBios/LinuxBios, and the performance hit or no change when running 64bit code. Then there is the price disparity. I can pick up a 2.6ghz AMD AthlonX2 for only $200 from Newegg. The 2.66ghz Intel E6700 weighs in at $519, over twice as much. In the AMD's price range you have the 1.8ghz E6300 at $180, and the 2.13ghz E6400 at $219. If you are spending $200 on a processor, there isn't even a contest.


So... the ending below is probably more accurate.

But... if you are stuck on a budget... why pay more for Intel Products... when you GET Less?
Post a Comment