Hi all, I am a engineer/programmer (fortran,C++) with some experience in system admin, but not nearly to the level of the people on this list. I'm looking into buying a new computer system and would like the opinion of someone on this list how difficult they think it would be to set up with Suse. I've used numerous versions of Mandrake before and am now looking to try something better. I've never compiled a kernel or added a patch before, but would not be afraid to try it. Mostly, I'm worried about 3D accelerated video card support for some of the graphics intense applications I run. OK, here's the computer (from www.hypersonic-pc.com). It's an AMD64 laptop system for about $3100. 1 Type II PCMCIA PC Card Slot 4 USB 2.0 ports, 1 Mini IEEE 1394 Firewire port, and 1 Parallel port Built-in 3-in-1 Media Card Reader for SD/SM/MMC HyperSense™ Advanced Remote Diagnostics Aviator AX6 in Metallic Silver with Graphite Accents 3400+ AMD Athlon™ 64 DTR Processor w/ PowerNow!™ Tech. (800MHz FSB) VIA K8T800 + VT8235 Chipset Mobile Motherboard for AX6 512MB PC3200 DDR400 RAM SODIMM 512MB PC3200 DDR400 RAM SODIMM ATI Radeon Mobility 9600 Pro 64MB (w/ TV Out) Guaranteed No Dead Pixels 60GB 7200rpm Ultra ATA Hard Disk Drive w/ 8MB Cache 8X DVD / 24X-10X-24 CD-R/W Combo Drive w/ Recording Software 15.1" SXGA+ High Contrast Active Matrix LCD Display (1400x1050) Built-in Sound Blaster Compatible Audio (AX6) Integrated 10/100 Fast Ethernet Controller Internal 802.11a+b+g Triband Wireless Mini PCI Network Adapter Integrated V.92 56K Fax/Data Modem MS Windows XP Professional SP1 CD & Manual Pre-Installed & Configured Targus USB Mobile Port Replicator with Ethernet 1Year 24/7 Toll-Free Tech Support Platinum Service & Lifetime Support Any insights you have would be appreciated. Thanks again. Ryan -- Ryan P. Starkey, Ph.D. Faculty Research Scientist Reusable Launch Vehicle Institute Department of Aerospace Engineering University of Maryland, College Park College Park, MD, 20742-3015 phone: (301) 405-7248 fax: (301) 314-9001 mailto:rstarkey@umd.edu
On Thu, 29 Jan 2004 16:02:54 -0500
rstarkey
ATI Radeon Mobility 9600 Pro 64MB (w/ TV Out)
Accelerated 3d won't run at this time with that card on a 64bit kernel. It requires ATI to release an 64bit version of their closed source driver first. On 32bit it will likely work (but no guarantees, check with ATI) -Andi
Hi Ryan, Just a few lines: - Use for the moment a 32-bit OS unless you really need 64 bits for development or your application. In some integer performance sensitive applications the 64-bit version might run much faster but my experience with floating point extensive applications (like Gaussian - quantum chemistry) shows the opposite for now, however, in theory the floating point part should be able to reach the same speed than on 32-bit when the compilers learn how to do it ;-). The AMD64 processors as far as I can tell perform extremely well when running a P4 optimized code in 32-bit mode - If you really need 64-bit now with hardware acceleration, choose a machine with NVidia graphics card, their driver support seems to be reasonable for 64-bit Linux (I use a Geforce FX 5200). - The first 64-bit OS I installed on my machine was SuSE 9.0, so I cannot tell about the others, but since this was my first time with SuSE I just can tell that I was impressed. I like it and can advise using it. As I can see if you choose your hardware well you need no time for learning how to compile a kernel. Have a look to the problems reported in the messages here and make your choice. Best wishes, Ödön ------------------------------------- Odon Farkas Department of Organic Chemistry, Eotvos Lorand University, P.O.Box 32 Budapest 112.,H-1518 E-mail: farkas@chem.elte.hu URL: http://organ.elte.hu/farkas Phone: (36)-(1)-209-0555, ext. 1325 (36)-(1)-372-2570 (36)-(30)-255-3111 FAX: (36)-(1)-209-0602 (36)-(1)-372-2620 ------------------------------------- On Thu, 2004-01-29 at 22:02, rstarkey wrote:
Hi all,
I am a engineer/programmer (fortran,C++) with some experience in system admin, but not nearly to the level of the people on this list. I'm looking into buying a new computer system and would like the opinion of someone on this list how difficult they think it would be to set up with Suse. I've used numerous versions of Mandrake before and am now looking to try something better. I've never compiled a kernel or added a patch before, but would not be afraid to try it. Mostly, I'm worried about 3D accelerated video card support for some of the graphics intense applications I run.
OK, here's the computer (from www.hypersonic-pc.com). It's an AMD64 laptop system for about $3100.
1 Type II PCMCIA PC Card Slot 4 USB 2.0 ports, 1 Mini IEEE 1394 Firewire port, and 1 Parallel port Built-in 3-in-1 Media Card Reader for SD/SM/MMC HyperSense™ Advanced Remote Diagnostics
Aviator AX6 in Metallic Silver with Graphite Accents 3400+ AMD Athlon™ 64 DTR Processor w/ PowerNow!™ Tech. (800MHz FSB) VIA K8T800 + VT8235 Chipset Mobile Motherboard for AX6 512MB PC3200 DDR400 RAM SODIMM 512MB PC3200 DDR400 RAM SODIMM ATI Radeon Mobility 9600 Pro 64MB (w/ TV Out) Guaranteed No Dead Pixels 60GB 7200rpm Ultra ATA Hard Disk Drive w/ 8MB Cache 8X DVD / 24X-10X-24 CD-R/W Combo Drive w/ Recording Software 15.1" SXGA+ High Contrast Active Matrix LCD Display (1400x1050) Built-in Sound Blaster Compatible Audio (AX6) Integrated 10/100 Fast Ethernet Controller Internal 802.11a+b+g Triband Wireless Mini PCI Network Adapter Integrated V.92 56K Fax/Data Modem MS Windows XP Professional SP1 CD & Manual Pre-Installed & Configured Targus USB Mobile Port Replicator with Ethernet 1Year 24/7 Toll-Free Tech Support Platinum Service & Lifetime Support
Any insights you have would be appreciated. Thanks again. Ryan
-- Ryan P. Starkey, Ph.D. Faculty Research Scientist Reusable Launch Vehicle Institute Department of Aerospace Engineering University of Maryland, College Park College Park, MD, 20742-3015
phone: (301) 405-7248 fax: (301) 314-9001 mailto:rstarkey@umd.edu
Odon Farkas
Hi Ryan,
Just a few lines: - Use for the moment a 32-bit OS unless you really need 64 bits for development or your application. In some integer performance sensitive applications the 64-bit version might run much faster but my experience
Do you have some example code that we can look at? I'd like to give it to our GCC developers to check that we optimize properly. If it's really ints, the code should be faster due to the more registers... but you might do some evil things ;-)
with floating point extensive applications (like Gaussian - quantum chemistry) shows the opposite for now, however, in theory the floating point part should be able to reach the same speed than on 32-bit when the compilers learn how to do it ;-). The AMD64 processors as far as I can tell perform extremely well when running a P4 optimized code in 32-bit mode [...]
Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj SuSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Hi Ödön, On Fri, 30 Jan 2004, Odon Farkas wrote:
- Use for the moment a 32-bit OS unless you really need 64 bits for
I wouldn't give such advice at all. Run benchmarks and then decide. If you recompile the stuff the 64bit version should win in most cases.
development or your application. In some integer performance sensitive applications the 64-bit version might run much faster but my experience with floating point extensive applications (like Gaussian - quantum chemistry) shows the opposite for now, however, in theory the floating point part should be able to reach the same speed than on 32-bit when the compilers learn how to do it ;-)
Hmm, I would be interested in some example code showing such behaviour. Because on AMD64 (in 64bit mode) we have twice as many registers and use SSE2 by default. This means that in theory (and mostly in practice too) floating point on AMD64 should outperform anything on 32bit quite a bit. This has nothing to do with 64bit or not, but rather with the much better instruction set available in 64bit mode. One usual problem with loops (in C(++)) is the use of 'int' loop indices if they are used also as array indices because of the necessary sign extension. This can be helped by either using 'unsigned int' or 'long' indices. Ciao, Michael.
Hi Michael, On Mon, 2004-02-02 at 07:56, Michael Matz wrote:
Hi Ödön,
On Fri, 30 Jan 2004, Odon Farkas wrote:
- Use for the moment a 32-bit OS unless you really need 64 bits for
I wouldn't give such advice at all. Run benchmarks and then decide. If you recompile the stuff the 64bit version should win in most cases.
development or your application. In some integer performance sensitive applications the 64-bit version might run much faster but my experience with floating point extensive applications (like Gaussian - quantum chemistry) shows the opposite for now, however, in theory the floating point part should be able to reach the same speed than on 32-bit when the compilers learn how to do it ;-)
Hmm, I would be interested in some example code showing such behaviour. Because on AMD64 (in 64bit mode) we have twice as many registers and use SSE2 by default. This means that in theory (and mostly in practice too) floating point on AMD64 should outperform anything on 32bit quite a bit. This has nothing to do with 64bit or not, but rather with the much better instruction set available in 64bit mode.
I was also surprised, since I expected the same. Gaussian uses the PGI fortran compiler and the code was linked with AMD's ACML. It is very likely a current handicap of the PGI compiler. Also a possible reason is that the cache can store more 32 bit integers than the default 64-bit ones when compiled with i8. Gaussian is not open source (see www.gausssian.com), so I am not allowed to give example code, the whole program is cca. 1M lines in Fortran. I could not find any SpecFP benchmark which was done on Opteron/Athlon64 in 64/bit mode and could outperform the same machine in 32-bit mode. However, I really hope this will happen...
One usual problem with loops (in C(++)) is the use of 'int' loop indices if they are used also as array indices because of the necessary sign extension. This can be helped by either using 'unsigned int' or 'long' indices.
Ciao, Michael.
Best wishes, Ödön
On Mon, 2 Feb 2004, Odon Farkas wrote:
Hmm, I would be interested in some example code showing such behaviour. Because on AMD64 (in 64bit mode) we have twice as many registers and use SSE2 by default. This means that in theory (and mostly in practice too) floating point on AMD64 should outperform anything on 32bit quite a bit. This has nothing to do with 64bit or not, but rather with the much better instruction set available in 64bit mode.
I was also surprised, since I expected the same. Gaussian uses the PGI fortran compiler and the code was linked with AMD's ACML. It is very likely a current handicap of the PGI compiler. Also a possible reason is that the cache can store more 32 bit integers than the default 64-bit ones when compiled with i8. Gaussian is not open source (see www.gausssian.com), so I am not allowed to give example code, the whole program is cca. 1M lines in Fortran. I could not find any SpecFP benchmark which was done on Opteron/Athlon64 in 64/bit mode and could outperform the same machine in 32-bit mode. However, I really hope this will happen...
This is surprising. We've been using the PGI 64 bit compilers on Opteron since this summer with very good results. Haven't tried Gaussian, but various self-written mathematical (including floating point) applications have run with the expected speed. SLES 8 for AMD64 and PGI 5.0, now up to PGI 5.1. With this said, we've mostly been using the C++ compiler. I would contemplate the possibility of a weakness in the Gaussian code, though. Bjørn -- Bjørn Tore Sund Phone: (+47) 555-84894 Stupidity is like a System administrator Fax: (+47) 555-89672 fractal; universal and Math. Department Mobile: (+47) 918 68075 infinitely repetitive. University of Bergen VIP: 81724 teknisk@mi.uib.no Email: bjornts@mi.uib.no http://www.mi.uib.no/
Hi Bjørn, On Mon, 2004-02-02 at 10:04, Bjorn Tore Sund wrote:
On Mon, 2 Feb 2004, Odon Farkas wrote:
Hmm, I would be interested in some example code showing such behaviour. Because on AMD64 (in 64bit mode) we have twice as many registers and use SSE2 by default. This means that in theory (and mostly in practice too) floating point on AMD64 should outperform anything on 32bit quite a bit. This has nothing to do with 64bit or not, but rather with the much better instruction set available in 64bit mode.
I was also surprised, since I expected the same. Gaussian uses the PGI fortran compiler and the code was linked with AMD's ACML. It is very likely a current handicap of the PGI compiler. Also a possible reason is that the cache can store more 32 bit integers than the default 64-bit ones when compiled with i8. Gaussian is not open source (see www.gausssian.com), so I am not allowed to give example code, the whole program is cca. 1M lines in Fortran. I could not find any SpecFP benchmark which was done on Opteron/Athlon64 in 64/bit mode and could outperform the same machine in 32-bit mode. However, I really hope this will happen...
This is surprising. We've been using the PGI 64 bit compilers on Opteron since this summer with very good results. Haven't tried Gaussian, but various self-written mathematical (including floating point) applications have run with the expected speed. SLES 8 for AMD64 and PGI 5.0, now up to PGI 5.1. With this said, we've mostly been using the C++ compiler.
I did not say that the performance in the 64-bit environment is not good, just that the floating point performance is currently somewhat better in the 32-bit environment.
I would contemplate the possibility of a weakness in the Gaussian code, though.
I wouldn't blame Gaussian at all, since it has practically the same code compiled on a wide range of machines, with a mature support for 64-bit machines. Anyway, we will see when Gaussian provides official support Opterons. I did what I could, however, my port was not an "official" one.
Bjørn
Best wishes, Ödön
Hi, On Mon, 2 Feb 2004, Odon Farkas wrote:
I did not say that the performance in the 64-bit environment is not good, just that the floating point performance is currently somewhat better in the 32-bit environment.
Hmm, hmm. You didn't by chance have tried to use GCC? I don't care about performance of code compiled by PGI. Anyway, right now this whole thing about fp performance on amd64 just being equal to pentium is just hearsay, as long as there is nothing demonstratable. At least our tests and also the published SPEC results tell another thing. Namely that the performance in SPECfp2000 of x86 class machines is just laughable compared to AMD64. See http://www.spec.org/cpu2000/results/cfp2000.html . I.e. something is strange on your side. Ciao, Michael.
Hi Micheal, Please, note the architecture and compiler also published (clik on the right side) and than you can see the used OS and compiler. Like the first one in the linked page: SOFTWARE -------- Operating System: SuSE Linux Enterprise Server 8 for x86 Compiler: Intel C/C++ 7.0 build 20021212Z and Intel Fortran 7.0 build 20021212Z I guess this is not a 64-bit compiler... Best wishes, Ödön P.S. By the way, I personally use Athlon64/SuSE 9.0 x86_64 and Gaussian compiled for 64-bit, but the facts are still facts. On Mon, 2004-02-02 at 11:11, Michael Matz wrote:
Hi,
On Mon, 2 Feb 2004, Odon Farkas wrote:
I did not say that the performance in the 64-bit environment is not good, just that the floating point performance is currently somewhat better in the 32-bit environment.
Hmm, hmm. You didn't by chance have tried to use GCC? I don't care about performance of code compiled by PGI. Anyway, right now this whole thing about fp performance on amd64 just being equal to pentium is just hearsay, as long as there is nothing demonstratable. At least our tests and also the published SPEC results tell another thing. Namely that the performance in SPECfp2000 of x86 class machines is just laughable compared to AMD64.
See http://www.spec.org/cpu2000/results/cfp2000.html .
I.e. something is strange on your side.
Ciao, Michael.
Hi Mike, Sorry, I just realized, that there are some new SpecFP results, like Advanced Micro Devices ASUS SK8N Motherboard, AMD Opteron (TM) 148 1514 1505 1 AMD Opteron (TM) 148 Dec-2003 Advanced Micro Devices ASUS SK8N Motherboard, AMD Opteron (TM) 148 1490 1393 1 AMD Opteron (TM) 148 Dec-2003 where the better one was compiled for 64-bit (SuSE 9.0) and the other using WindowsXP and Intel compilers. The only thing I am still missing are results using 32-bit Linux. Best wishes, Ödön On Mon, 2004-02-02 at 11:11, Michael Matz wrote:
Hi,
On Mon, 2 Feb 2004, Odon Farkas wrote:
I did not say that the performance in the 64-bit environment is not good, just that the floating point performance is currently somewhat better in the 32-bit environment.
Hmm, hmm. You didn't by chance have tried to use GCC? I don't care about performance of code compiled by PGI. Anyway, right now this whole thing about fp performance on amd64 just being equal to pentium is just hearsay, as long as there is nothing demonstratable. At least our tests and also the published SPEC results tell another thing. Namely that the performance in SPECfp2000 of x86 class machines is just laughable compared to AMD64.
See http://www.spec.org/cpu2000/results/cfp2000.html .
I.e. something is strange on your side.
Ciao, Michael.
Hi, On Mon, 2 Feb 2004, Odon Farkas wrote:
Please, note the architecture and compiler also published (clik on the right side) and than you can see the used OS and compiler.
I have of course.
Like the first one in the linked page:
SOFTWARE -------- Operating System: SuSE Linux Enterprise Server 8 for x86 Compiler: Intel C/C++ 7.0 build 20021212Z and Intel Fortran 7.0 build 20021212Z
Ermh, yeah, well, this is a 32bit compiler. No wonder it doesn't better than 32bit. You should actually look at Opteron systems where a 64bit compiler is used, like e.g. http://www.spec.org/cpu2000/results/res2003q4/cpu2000-20031117-02630.html Score ~ > 1500.
I guess this is not a 64-bit compiler...
Yes, so what did you want to say here? I thought this thread was about 64bit mode vs. compatibility mode performance. Citing compatibility mode compilers isn't going to help then.
P.S. By the way, I personally use Athlon64/SuSE 9.0 x86_64 and Gaussian compiled for 64-bit, but the facts are still facts.
True. But fact is that most people see real performance improvements, that's why I said that something must be fishy on your side. Wrong options, wrong inline assembler, wrong glibc, I don't know. Something. Or simply code which the compiler is not happy about. Ciao, Michael.
Hi, On Mon, 2 Feb 2004, Odon Farkas wrote:
where the better one was compiled for 64-bit (SuSE 9.0) and the other using WindowsXP and Intel compilers. The only thing I am still missing are results using 32-bit Linux.
Running an amd64 system in 32-bit linux makes no sense IMHO (except for the curious). But it should be comparable to a fast Athlon system. Ciao, Michael.
Hi, On Mon, 2004-02-02 at 11:49, Michael Matz wrote:
Hi,
On Mon, 2 Feb 2004, Odon Farkas wrote:
Please, note the architecture and compiler also published (clik on the right side) and than you can see the used OS and compiler.
I have of course.
Like the first one in the linked page:
SOFTWARE -------- Operating System: SuSE Linux Enterprise Server 8 for x86 Compiler: Intel C/C++ 7.0 build 20021212Z and Intel Fortran 7.0 build 20021212Z
Ermh, yeah, well, this is a 32bit compiler. No wonder it doesn't better than 32bit. You should actually look at Opteron systems where a 64bit compiler is used, like e.g. http://www.spec.org/cpu2000/results/res2003q4/cpu2000-20031117-02630.html
Score ~ > 1500.
I guess this is not a 64-bit compiler...
Yes, so what did you want to say here? I thought this thread was about 64bit mode vs. compatibility mode performance. Citing compatibility mode compilers isn't going to help then.
P.S. By the way, I personally use Athlon64/SuSE 9.0 x86_64 and Gaussian compiled for 64-bit, but the facts are still facts.
True. But fact is that most people see real performance improvements, that's why I said that something must be fishy on your side. Wrong options, wrong inline assembler, wrong glibc, I don't know. Something. Or simply code which the compiler is not happy about.
This was not my first time compiling Gaussian and even the "compatibility" mode (PGI 32-bit) runs cca. 8% faster then the 64-bit compiled one. It seems that none of us has other example showing the floating point performance of the same machine using a pure 32-bit Linux environment and a 64-bit one. Best wishes, Ödön
Ciao, Michael.
Hi, On Mon, 2004-02-02 at 11:53, Michael Matz wrote:
Hi,
On Mon, 2 Feb 2004, Odon Farkas wrote:
where the better one was compiled for 64-bit (SuSE 9.0) and the other using WindowsXP and Intel compilers. The only thing I am still missing are results using 32-bit Linux.
Running an amd64 system in 32-bit linux makes no sense IMHO (except for the curious). But it should be comparable to a fast Athlon system.
You are partially right, however, since AMD64 can use SSE2, the other part is not true. Just for Gaussian I could detect a nice 30-50% boost over non-sse2 code on P4 systems. The same can be expected when moving from Athlon to Athlon-SSE2.
Ciao, Michael.
Best wishes, Ödön
Hi,
This was not my first time compiling Gaussian and even the "compatibility" mode (PGI 32-bit) runs cca. 8% faster then the 64-bit compiled one.
I realize this, and it's not good. That's why Andreas asked for code exhibiting this in order for us to be able to fix it (if it's in GCC, not PGI), because it's not a general problem. Without such we can't do much about it, except stating that this is not true in general and that this should not be the base of advice for people looking at AMD64 to use it under an 32 bit OS. Ciao, Micha.
Hi, On Mon, 2 Feb 2004, Odon Farkas wrote:
Running an amd64 system in 32-bit linux makes no sense IMHO (except for the curious). But it should be comparable to a fast Athlon system.
You are partially right, however, since AMD64 can use SSE2, the other part is not true.
Like I said, a fast Athlon, which includes SSE2 in my definition of fast ;-) Ciao, Michael.
Hi Micheal, Can you run SFP2000 under both, 32-bit linux and 64-bit on the same machine, or show results published by others? If you can, please, do so, and then I'll go back and see what was wrong in my compilation and also people can see that this is very likely just a temporary issue with Gaussian and PGI. Best wishes, Ödön On Mon, 2004-02-02 at 12:13, Michael Matz wrote:
Hi,
This was not my first time compiling Gaussian and even the "compatibility" mode (PGI 32-bit) runs cca. 8% faster then the 64-bit compiled one.
I realize this, and it's not good. That's why Andreas asked for code exhibiting this in order for us to be able to fix it (if it's in GCC, not PGI), because it's not a general problem. Without such we can't do much about it, except stating that this is not true in general and that this should not be the base of advice for people looking at AMD64 to use it under an 32 bit OS.
Ciao, Micha.
participants (6)
-
Andi Kleen -
Andreas Jaeger -
Bjorn Tore Sund -
Michael Matz -
Odon Farkas -
rstarkey