Athlon 64 not so fast?
Hello list! I just installed opensuse 10.1 X86_64 on my new Athlon 64 base system, 160GB sata II 3GB drive and I am not seeing what I perceive as a speed demon. On my Athlon XP 1800 with 10.1 and all updates applied when (for example) I click on the terminal icon in kde it takes roughly ~3 sec. to open and have a terminal I can type in. On this new system it takes about the same amount of time, this is one of those places that I thought I would see a noticeable time difference as in I would click the icon and would have seemingly instaneous opening of the terminal. I notice the same thing with other apps which I would have thought would be extremely faster but I am not seeing the performance difference I expected. Still 4 to 5 seconds to open the gimp, 7 to 8 seconds to open openoffice writer. I have loaded all of the optimized defaults in the bios and 512Mb of pc3200 ram. Maybe I am was just deluding myself and built myself up for an extremely fast machine, one that would pale my athlon xp machines by comparison. Is there something that I should have/could have done during the installation that is affecting the performance? Did I miss something? TIA John -- Registered Linux User 263680, get counted at http://counter.li.org
On Sunday 22 October 2006 15:16, John Pierce wrote:
Still 4 to 5 seconds to open the gimp, 7 to 8 seconds to open openoffice writer.
These times are mostly down to the speed of HD, the amount of memory available and the DMA settings for the drives. The processor is hardly involved in starting up apps.
I have loaded all of the optimized defaults in the bios and 512Mb of pc3200 ram.
That's not a lot of memory - another 512 might well show a greater speed improvement.
Maybe I am was just deluding myself and built myself up for an extremely fast machine, one that would pale my athlon xp machines by comparison.
Is there something that I should have/could have done during the installation that is affecting the performance? Did I miss something?
You'll notice the greatest speed increase when doing processor intensive work. For example, I do a fair amount of audio-video processing and tasks which might have taken a week or more to complete on a 32-bit system can be finished in under a day on 64-bit. Dylan
TIA
John -- Registered Linux User 263680, get counted at http://counter.li.org
John, On Sunday 22 October 2006 07:16, John Pierce wrote:
Hello list!
I just installed opensuse 10.1 X86_64 on my new Athlon 64 base system, 160GB sata II 3GB drive and I am not seeing what I perceive as a speed demon.
You should not expect 64-bit machines to be faster 32-bit machines with comparable clock speeds. Quite the opposite, really. The only good reason to go to 64-bit machines is when you need the virtual address range they afford.
...
I notice the same thing with other apps which I would have thought would be extremely faster but I am not seeing the performance difference I expected. Still 4 to 5 seconds to open the gimp, 7 to 8 seconds to open openoffice writer.
As others have pointed out, the times you're mentioning are strongly dominated by disk performance and are largely independent of CPU and RAM speeds. You should note that it is possible to get 10,000 RPM SATA drives. If you want a snappy system, there's two things you should acquire: 1) Fast drives 2) More drives In particular, w.r.t. (2), having at least one drive for system functions and another for user data files is very helpful. On the most recent system I put together, I have a small (-ish) 15,000 RPM Ultra-320 SCSI drive for the root file system and swap (which will be rarely used, since I have 4 GB of RAM) and a medium-capacity (150 GB) 10,000 RPM SATA drive for /home. Also, RAM continues to be a bottleneck for CPU-bound activities, so getting the fastest RAM that your mainboard can exploit is worthwhile.
I have loaded all of the optimized defaults in the bios and 512Mb of pc3200 ram.
Maybe I am was just deluding myself and built myself up for an extremely fast machine, one that would pale my athlon xp machines by comparison.
This is an extremely fast machine (based on the Asus P5B mainboard): - Core 2 Duo @ 3.0 GHz (overclocked from the rated 2.67 GHz) - 4 GB PC6400 DDR2 RAM @ 900 MHz FSB (overclocked from rated 800 MHz) - Ultra-320 SCSI Adaptor - 36 GB, 15,000 RPM, Ultra-320 disk - 6 SATA-III ports - 150 GB 10,000 RPM, SATA-III disk - nVidia GeForce 7300
Is there something that I should have/could have done during the installation that is affecting the performance? Did I miss something?
Probably not. You're seeing performance commensurate with the hardware you put together, I'd say.
TIA
John
Randall Schulz
I don't agree. Because of the extra registers and other tweaks I get considerably more performance on processor intensive computational tasks. YMMV depending on your task mix. mike. On Sunday 22 October 2006 11:44, Randall R Schulz wrote:
You should not expect 64-bit machines to be faster 32-bit machines with comparable clock speeds. Quite the opposite, really. The only good reason to go to 64-bit machines is when you need the virtual address range they afford.
On Sunday 22 October 2006 08:01, Mike wrote:
I don't agree. Because of the extra registers and other tweaks I get considerably more performance on processor intensive computational tasks. YMMV depending on your task mix.
mike.
Just how much of the standard load of software other than games are computational intensive? Any gains in computation speed are wiped out by the mundane tasks . Every program needs to use pointers for just about every single memory reference. These all double in size and moving one byte from one memory to another now requires in excess of twice the overhead. Twice the pointer size, twice the minimum memory access size. If you move big chunks its faster to to move 8 bytes at a time than 4, but the minimum memory access is now 8 bytes rather than 4. -- _____________________________________ John Andersen
On Sunday 22 October 2006 23:25, John Andersen wrote:
On Sunday 22 October 2006 08:01, Mike wrote:
I don't agree. Because of the extra registers and other tweaks I get considerably more performance on processor intensive computational tasks. YMMV depending on your task mix.
mike.
Just how much of the standard load of software other than games are computational intensive?
en/decoding of movies and music
On Sun, 2006-10-22 at 23:36 +0200, Anders Johansson wrote:
On Sunday 22 October 2006 23:25, John Andersen wrote:
On Sunday 22 October 2006 08:01, Mike wrote:
I don't agree. Because of the extra registers and other tweaks I get considerably more performance on processor intensive computational tasks. YMMV depending on your task mix.
mike.
Just how much of the standard load of software other than games are computational intensive?
en/decoding of movies and music
compiling src
/Peo Registered Linux user #432116 http://counter.li.org/ http://www.whylinuxisbetter.net/
On Sunday 22 October 2006 13:34, Peo Nilsson wrote:
en/decoding of movies and music
compiling src
Sorry, but No. Compilation is not computational intensive. Its largely see this, write that. You don't even need a floating point processor. Not even to compile floating point code. -- _____________________________________ John Andersen
On Sun, 2006-10-22 at 13:45 -0800, John Andersen wrote:
On Sunday 22 October 2006 13:34, Peo Nilsson wrote:
en/decoding of movies and music
compiling src
Sorry, but No. Compilation is not computational intensive. Its largely see this, write that. You don't even need a floating point processor. Not even to compile floating point code.
I think we're moving into 32bit performance vs. 64bit performance while the question was Athlon64 performance vs. AthlonXP performance. I know from running 32bit SUSE 10.1 on both AthlonXP and a wide variety of Athlon64 based processors (Sempron64, Athlon64, Turion64) that the Athlon64 based chips perform better. In both compiling source and in encoding video and audio (the heaviest tasks I do on my notebook and home PC). Note, I'm not comparing 64bit linux with 32bit linux - I have 32bit on both. Hans
I know from running 32bit SUSE 10.1 on both AthlonXP and a wide variety of Athlon64 based processors (Sempron64, Athlon64, Turion64) that the Athlon64 based chips perform better. In both compiling source and in encoding video and audio (the heaviest tasks I do on my notebook and home PC).
Just to throw in another 2 cents... I recently moved from an AthlonXP to an AMD X2 64. Where I notice the biggest difference is when I'm doing something that maxes out the first CPU. When it pegs at 100%, I still have a whole other CPU to deal with other tasks... so I still have a completely responsive system rather than the sluggish "feel" that the AthlonXP used to exhibit when the single CPU was "pegged". Ok, obvious I know, but worth stating that little feature. Granted on day-to-day stuff it's essentially impossible for me to see a difference (for example opening a terminal window). C.
Clayton wrote:
I know from running 32bit SUSE 10.1 on both AthlonXP and a wide variety of Athlon64 based processors (Sempron64, Athlon64, Turion64) that the Athlon64 based chips perform better. In both compiling source and in encoding video and audio (the heaviest tasks I do on my notebook and home PC).
Just to throw in another 2 cents... I recently moved from an AthlonXP to an AMD X2 64. Where I notice the biggest difference is when I'm doing something that maxes out the first CPU. When it pegs at 100%, I still have a whole other CPU to deal with other tasks... so I still have a completely responsive system rather than the sluggish "feel" that the AthlonXP used to exhibit when the single CPU was "pegged". Ok, obvious I know, but worth stating that little feature. Granted on day-to-day stuff it's essentially impossible for me to see a difference (for example opening a terminal window).
C.
Of course, that X2 64 makes for a fast game of solitaire! ;-)
On Sunday 22 October 2006 22:45, John Andersen wrote:
On Sunday 22 October 2006 13:34, Peo Nilsson wrote:
en/decoding of movies and music
compiling src
Sorry, but No. Compilation is not computational intensive.
Er, sorry, but yes. Some of the larger C++ source files in projects I work on take over a minute of 100% saturation of CPU with virtually no I/O to compile with optimisation turned on. This on machines with 1GB+ main memory, RAID-0 storage, etc. Some of this '100%' is taken up by memory/cache transfers, sure, but by no means all of it. There's an awful lot of computation going on in there somewhere. Mostly in the optimiser, since unoptimised builds are a great deal faster .....
Its largely see this, write that. You don't even need a floating point processor. Not even to compile floating point code.
Sure, there's little to no fp in the mix, but that doesn't mean it isn't computationally intensive! -- Bill Gallafent.
Mike wrote:
I don't agree. Because of the extra registers and other tweaks I get considerably more performance on processor intensive computational tasks. YMMV depending on your task mix.
mike.
On Sunday 22 October 2006 11:44, Randall R Schulz wrote:
You should not expect 64-bit machines to be faster 32-bit machines with comparable clock speeds. Quite the opposite, really. The only good reason to go to 64-bit machines is when you need the virtual address range they afford.
I have a dual processor AMD 64-bit 2.4 Ghz 250 Opteron with 4-GB of RAM. I have an Intel 2.4-GHZ 32-bit machine with 1-GB of RAM. I am running folding@home (something like seti@home) but doing protein analysis) I watch the folding cranking results and can tell you that the Intel machine is doing computational stuff and returning results at about twice the speed of the AMD. By watch, I mean I have two terminal windows open watching both machines do there work. By the way, the AMD machine has no one on it and no work to do but this project. The Intel has multiple people on it and lots of stuff going on. The results were a complete surprise to me and somewhat shocking. By the way, for those of you interested in joining this project we have setup a SuSE Linux Users group. So if you register you may wish to join our group. http://folding.stanford.edu/ Cheers, Bob
Bob, On Monday 23 October 2006 10:31, Robert Lewis wrote:
...
I have a dual processor AMD 64-bit 2.4 Ghz 250 Opteron with 4-GB of RAM.
I have an Intel 2.4-GHZ 32-bit machine with 1-GB of RAM.
I am running folding@home (something like seti@home) but doing protein analysis)
I watch the folding cranking results and can tell you that the Intel machine is doing computational stuff and returning results at about twice the speed of the AMD. By watch, I mean I have two terminal windows open watching both machines do there work. By the way, the AMD machine has no one on it and no work to do but this project. The Intel has multiple people on it and lots of stuff going on. The results were a complete surprise to me and somewhat shocking.
Interesting, but also lacking any real significance due to the lack of information on the FSB and memory components. I've told the story before of the performance of my theorem prover (very computationally expensive--as in 100% CPU-bound and single-threaded, apart from the JVM's garbage collection). The performance comparison between my 3.0 GHz Hyperthreading Linux box with DDR2 400 MHz RAM and my 2.0 GHz Core Duo iMac (_not_ Core 2 Duo) with DDR2 667 MHz RAM exactly reflects the difference in the speed of _the RAM_, not the CPUs. So, unless you tell us about the FSB and RAM speed on these two machines, it's impossible to really interpret your reported results.
...
Cheers, Bob
Randall Schulz
Randall R Schulz wrote:
Bob,
On Monday 23 October 2006 10:31, Robert Lewis wrote:
...
I have a dual processor AMD 64-bit 2.4 Ghz 250 Opteron with 4-GB of RAM.
I have an Intel 2.4-GHZ 32-bit machine with 1-GB of RAM.
I am running folding@home (something like seti@home) but doing protein analysis)
I watch the folding cranking results and can tell you that the Intel machine is doing computational stuff and returning results at about twice the speed of the AMD. By watch, I mean I have two terminal windows open watching both machines do there work. By the way, the AMD machine has no one on it and no work to do but this project. The Intel has multiple people on it and lots of stuff going on. The results were a complete surprise to me and somewhat shocking.
Interesting, but also lacking any real significance due to the lack of information on the FSB and memory components.
I've told the story before of the performance of my theorem prover (very computationally expensive--as in 100% CPU-bound and single-threaded, apart from the JVM's garbage collection). The performance comparison between my 3.0 GHz Hyperthreading Linux box with DDR2 400 MHz RAM and my 2.0 GHz Core Duo iMac (_not_ Core 2 Duo) with DDR2 667 MHz RAM exactly reflects the difference in the speed of _the RAM_, not the CPUs.
So, unless you tell us about the FSB and RAM speed on these two machines, it's impossible to really interpret your reported results.
Is there some command I can run that will return that information rather than looking it up in the mother-board manuals?
Bob, On Monday 23 October 2006 11:37, Robert Lewis wrote:
...
So, unless you tell us about the FSB and RAM speed on these two machines, it's impossible to really interpret your reported results.
Is there some command I can run that will return that information rather than looking it up in the mother-board manuals?
You can get extreme detail on your RAM using "decode-dimms.pl" from the "sensors" package, though for some reason it's currently working only on my 10.2 system and not on my 10.0 system (the 3.0 GHz HT Linux box mentioned above). I think that's because the lm_sensors people never implemented support for the monitoring chip on this mainboard (an Intel board based on the 965 chipset). The 10.2 system where it works incorporates an Asus P5B board. Randall Schulz
Randall R Schulz wrote:
Bob,
On Monday 23 October 2006 10:31, Robert Lewis wrote:
...
I have a dual processor AMD 64-bit 2.4 Ghz 250 Opteron with 4-GB of RAM. -- snip --
Interesting, but also lacking any real significance due to the lack of information on the FSB and memory components.
-- snip --
So, unless you tell us about the FSB and RAM speed on these two machines, it's impossible to really interpret your reported results.
I may be telling my age, but I recall a debate very similar to this back when everyone was using 8-bit machines, and Texas Instruments introduced a 16-bit. The 16-bit was slower at first, until developers learned to take advantage of the new hardware. Has anyone compared the 32-bit Intel to a 64-bit Intel? -- ED --
On Mon, 2006-10-23 at 18:51 -0400, Ed McCanless wrote:
Randall R Schulz wrote:
Bob,
On Monday 23 October 2006 10:31, Robert Lewis wrote:
...
I have a dual processor AMD 64-bit 2.4 Ghz 250 Opteron with 4-GB of RAM. -- snip --
Interesting, but also lacking any real significance due to the lack of information on the FSB and memory components.
-- snip --
So, unless you tell us about the FSB and RAM speed on these two machines, it's impossible to really interpret your reported results.
I may be telling my age, but I recall a debate very similar to this back when everyone was using 8-bit machines, and Texas Instruments introduced a 16-bit. The 16-bit was slower at first, until developers learned to take advantage of the new hardware. Has anyone compared the 32-bit Intel to a 64-bit Intel?
-- ED --
I have an MSI K9N Neo motherboard with AM2 socket athlon 64 x2 3899+ processor w/2Gbyte RAM. running Suse 10.1. Disks are WEC 160 GByte 7200 RPM. This thing is FAST. Opening a terminal window is almost instantaneous as is opening Konqueror. Clicking on /usr/bin folder in konqueror used to take about 10 seconds with my old ASUS sincle core athelon with the same disks. With the dual core, it takes about 2 seconds. Using the Gnome system monitor, you can see the load on both processors. Pretty neat. My only complaint is that after two weeks, I have not gotten Xen to load a WinXP, Win2k, Win98, or Suse 10.0 viertual machine. It locks up and the only way out is with the reset button or power switch. Am loogin at tring a Giga-Byte motherboard and see what happens. They are pretty cheap here in Taiwan. Art
Running apache and sending out lots of hires jpeg's it really is noticeable. It leaves my old AMD XP 1800+ wind tunnel way behind. Just my €0.02 Steve.
On Mon, 23 Oct 2006 10:31:34 -0700 Robert Lewis <rll@felton.felton.ca.us> wrote:
I don't agree. Because of the extra registers and other tweaks I get considerably more performance on processor intensive computational tasks. YMMV depending on your task mix.
I have a dual processor AMD 64-bit 2.4 Ghz 250 Opteron with 4-GB of RAM.
I have an Intel 2.4-GHZ 32-bit machine with 1-GB of RAM.
I am running folding@home (something like seti@home) but doing protein analysis)
I watch the folding cranking results and can tell you that the Intel machine is doing computational stuff and returning results at about twice the speed of the AMD. By watch, I mean I have two terminal windows open watching both machines do there work. By the way, the AMD machine has no one on it and no work to do but this project. The Intel has multiple people on it and lots of stuff going on. The results were a complete surprise to me and somewhat shocking.
I am not familiar with the folding@home application, but instances have occurred where distributed_computing software has been compiled with "optimized-for-Intel" tools. On other (boinc) projects, their new "equal points for equal work completed" credit schemes give my 2.0 Ghz AMD processor daily average credits that are still in the same ballpark when compared to Intel (non-Conroe) processors. mikus
John Pierce wrote:
Hello list!
I just installed opensuse 10.1 X86_64 on my new Athlon 64 base system, 160GB sata II 3GB drive and I am not seeing what I perceive as a speed demon.
On my Athlon XP 1800 with 10.1 and all updates applied when (for example) I click on the terminal icon in kde it takes roughly ~3 sec. to open and have a terminal I can type in. On this new system it takes about the same amount of time, this is one of those places that I thought I would see a noticeable time difference as in I would click the icon and would have seemingly instaneous opening of the terminal.
I notice the same thing with other apps which I would have thought would be extremely faster but I am not seeing the performance difference I expected. Still 4 to 5 seconds to open the gimp, 7 to 8 seconds to open openoffice writer.
I have loaded all of the optimized defaults in the bios and 512Mb of pc3200 ram.
Maybe I am was just deluding myself and built myself up for an extremely fast machine, one that would pale my athlon xp machines by comparison.
Is there something that I should have/could have done during the installation that is affecting the performance? Did I miss something?
I have an Athlon 64 3200 & 1 GB of memory. It takse roughly a second to open the terminal. I'm also running 10.1
James Knott wrote:
John Pierce wrote:
Hello list!
I just installed opensuse 10.1 X86_64 on my new Athlon 64 base system, 160GB sata II 3GB drive and I am not seeing what I perceive as a speed demon.
On my Athlon XP 1800 with 10.1 and all updates applied when (for example) I click on the terminal icon in kde it takes roughly ~3 sec. to open and have a terminal I can type in. On this new system it takes about the same amount of time, this is one of those places that I thought I would see a noticeable time difference as in I would click the icon and would have seemingly instaneous opening of the terminal.
I notice the same thing with other apps which I would have thought would be extremely faster but I am not seeing the performance difference I expected. Still 4 to 5 seconds to open the gimp, 7 to 8 seconds to open openoffice writer.
I have loaded all of the optimized defaults in the bios and 512Mb of pc3200 ram.
Maybe I am was just deluding myself and built myself up for an extremely fast machine, one that would pale my athlon xp machines by comparison.
Is there something that I should have/could have done during the installation that is affecting the performance? Did I miss something?
I have an Athlon 64 3200 & 1 GB of memory. It takse roughly a second to open the terminal. I'm also running 10.1
I get roughly the same time as you do, 1 second to open a terminal and the system is Athlon 64 4000 w/ 2 GB of memory. Mike
On Sun, 2006-10-22 at 09:16 -0500, John Pierce wrote:
Hello list!
I just installed opensuse 10.1 X86_64 on my new Athlon 64 base system, 160GB sata II 3GB drive and I am not seeing what I perceive as a speed demon.
On my Athlon XP 1800 with 10.1 and all updates applied when (for example) I click on the terminal icon in kde it takes roughly ~3 sec. to open and have a terminal I can type in. On this new system it takes about the same amount of time, this is one of those places that I thought I would see a noticeable time difference as in I would click the icon and would have seemingly instaneous opening of the terminal.
A few things come to mind: 1. You probably had a disc of the same speed (7200rpm?) on the AthlonXP? Unless you increase the drive speed (and the difference between PATA, SATA and SATA-II are largely academic), startup performance won't be much different. Even a 1GHz Pentium-3 can start most desktop aplications much faster than any 72000rpm disc will allow it. Until fairly recently my workstation at the office was a P3-1GHz with two 7200rpm SCSI discs (one for / and swap, the other for /home) and 1GB of PC133 memory. It's still at least as fast and responsive at desktop stuff than any new PC with 7200rpm discs. 2. AthlonXP is a much more powerful CPU than many people give it credit for. 3. You don't say which Athlon64 you have. Even if it is the 1.8GHz (i.e. directly comparable to your AthlonXP), the Athlon64 will be much faster with many CPU intensive things. To give you an example. I have an AthlonXP 2400+ (2GHz, 128+256k cache), 1GB DDR400 mem, and a 7200rpm SATA disc. I used it mainly for video encoding - making AVIs from my DVDs. My notebook is a Turion64 ML34 (1.8GHz, 1MB cache). Guess which one is faster at encoding? With all the quality switches for xvid in mencoder, the AthlonXP encodes at between 3 and 7 FPS, the Turion64 runs at between 10 and 30 FPS. BUT As a desktop, the AthlonXP feels much more responsive, because it has a faster disc. I've remedied this somewhat, by upgrading the notebook's memory to the max - 2GB, but it's still not as snappy as the AthlonXP.
Still 4 to 5 seconds to open the gimp, 7 to 8 seconds to open openoffice writer. Take a nice big image, say this one: http://earthobservatory.nasa.gov/Newsroom/NewImages/Images/palmis_ast_200626...
I have loaded all of the optimized defaults in the bios and 512Mb of pc3200 ram. That's not enough. With that little memory you will never feel a huge
Download it, open in Gimp, right click on the image, go "Image" --> "Scale Image" and take it to 640x791. How long does it take on either machine? I'm guessing the Athlon64 is much quicker. It takes my AthlonXP a good two seconds longer than the Turion64. performance boost, now matter what CPU you put in. Get at least 1GB, more if you can afford it. Hans
On Sun, 2006-10-22 at 19:33 +0200, Hans du Plooy wrote:
On Sun, 2006-10-22 at 09:16 -0500, John Pierce wrote:
Hello list!
I just installed opensuse 10.1 X86_64 on my new Athlon 64 base system, 160GB sata II 3GB drive and I am not seeing what I perceive as a speed demon.
Another thing: (I may be totally wrong on this) I've run both 32 and 64bit versions of SUSE 10.1 on my notebook with 512MB memory, and the 32bit version definitely felt more responsive. I'm guessing in 64bit mode the CPU works with bigger chunks, thus uses more memory, but like I said, I may be completely wrong about this. Hans
Athlon 64 is faster than Athlon XP, yes, but only for some memory-intensive operations. On most workloads, it's only a bit faster, not much faster. So generally it's not very smart to replace Athlon XP with Athlon 64 for desktop apps (unless you need Dual Core). So, no, Athlon 64 won't pale your old Athlon XP. Neither will Pentium 4. (Haven't tried Core 2 yet thorought...)
participants (18)
-
Alexey Eremenko -
Anders Johansson -
Art Fore -
Clayton -
Dylan -
Ed McCanless -
Hans du Plooy -
James Knott -
John Andersen -
John Pierce -
Mike -
Mike Noble -
mikus＠bga.com -
Peo Nilsson -
Primm -
Randall R Schulz -
Robert Lewis -
William Gallafent