Re: confused about performance
On Thu, 14 Jun 2007, M. Edward (Ed) Borasky wrote: All of these provide vastly better performance than the current incarnations of ATLAS in 64bit. How recent is your data? I was under the impression that Atlas had caught up with GOTO and ACML, and possibly even the Intel libraries on the Core 2 Duo. I'm on the Atlas mailing list -- I can ask there. In any event, there is enough assembly code in Atlas that I'd expect it to be competitive with both GOTO and the vendor libraries on AMD 64-bit and Intel 64-bit chips. And I think 3.7.32 cleaned out some bottlenecks in the 64-bit SPARC code as well, so it's undoubtedly worthwhile for Debian to put it in the repositories for SPARC at 3.7.32 and probably not for older versions. Two or three months, when I last compiled the latest version of the big quantum chemistry code (NWChem) I use (which spends a lot of time doing floating point linear algebra). The computer on which I tested is a relatively old Athlon 64 3500+, your mileage may vary on other machines. Oddly enough, an old version of GOTO was the fastest, followed closely by the optimised acml, then head to head the internal implementation provided by the quantum chemistry package and the (then) current GOTO, then atlas. Differences among all but atlas were measurable (i.e. reproducible) but very small, within 2%, atlas was ~10% slower. The Intel compilers produced much faster code than the gcc suite (both 3.4 and 4.1), despite running on AMD processors. This is a VERY specific test, of course, so I do not claim my conclusions should apply to anyone but me. On the other hand, they do apply rather well to my scenario by definition :) I will obviously evaluate again atlas and new versions of the gcc suite if/when it's worth the effort. I look forward seeing an up-to-date version of atlas being included in debian. I would actually be very glad to be able to switch to a completely clean environment using gcc, since I currently have to keep around hosts of libraries compiled with different compilers and it's somewhat messy to maintain. Bye Giacomo -- _ Giacomo Mulas [EMAIL PROTECTED] _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IA-32 libraries
Irene Laiz [EMAIL PROTECTED] writes: Dear all, I'm new to Linux. I've just installed Debian 4.0 on a server based on EA64T architecture. When trying to install the Intel Fortran Compiler, the installation fails because the IA-32 version of the following libraries cannot be found: libstdc++ libgcc glibc Can anyone tell me where to find them? This is what I've done so far (logged in as root): apt-get install ia32-libs The answer I get is that ia32-libs is already installed in its latest version apt-get ia32-libs-dev The answer I get is that this package is not available but it can be replaced with lib32z1-dev, lib32bz2-dev and ia32-libs. When trying to install them I get a message saying that they're already installed in their latest version. Thank you very much for your help Irene Try compiling a hello world with gcc -m32 -o hello hello.c. If that works then you have to dig into icc to find why it fails. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IA-32 libraries
On Fri, 2007-06-15 at 11:01 +0200, Goswin von Brederlow wrote: Irene Laiz [EMAIL PROTECTED] writes: Dear all, I'm new to Linux. I've just installed Debian 4.0 on a server based on EA64T architecture. When trying to install the Intel Fortran Compiler, the installation fails because the IA-32 version of the following libraries cannot be found: libstdc++ libgcc glibc Can anyone tell me where to find them? This is what I've done so far (logged in as root): apt-get install ia32-libs The answer I get is that ia32-libs is already installed in its latest version apt-get ia32-libs-dev The answer I get is that this package is not available but it can be replaced with lib32z1-dev, lib32bz2-dev and ia32-libs. When trying to install them I get a message saying that they're already installed in their latest version. Thank you very much for your help Irene Try compiling a hello world with gcc -m32 -o hello hello.c. If that works then you have to dig into icc to find why it fails. Installation doesn't fail. The Intel installer is terribly written, and queries your system's RPM database to ensure key packages are installed. Obviously, if your system isn't RPM-based, then you're out of luck. Ignore the messages if you can, bet to work on repackaging the installer RPMs if you can't -- __ / Jo Shields [EMAIL PROTECTED] \ | Systems Manager, | \ Oxford Supercomputing Centre / --- \ ,__, \ (oo)___ (__))\ ||--|| * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IA-32 libraries
Hej, you can find a well written description on how to install the Intel compilers on Debian here: http://www.theochem.uwa.edu.au/fortran/intel_on_debian The scripts given there fail to correct all stages of the .deb post-installation procedure, but as far as I can see, the only problem is that INSTALLDIR is not replaced with the correct installation directory, e.g. /opt/intel/cce/9.1.042/ for Intel C compiler 9.1.042. This is needed for some scripts in the bin directories, e.g. /opt/intel/cce/9.1.042/bin/iccvars.sh. You can fix this either manually after the package installation, or by replacing $DESTINATION with tmp/$DESTINATION in the make_deb_xxx.sh scripts. sed -e 's/$DESTINATION/tmp\/$DESTINATION/' make_deb_9e.sh should do this. /Simone Jo Shields wrote: On Fri, 2007-06-15 at 11:01 +0200, Goswin von Brederlow wrote: Irene Laiz [EMAIL PROTECTED] writes: Dear all, I'm new to Linux. I've just installed Debian 4.0 on a server based on EA64T architecture. When trying to install the Intel Fortran Compiler, the installation fails because the IA-32 version of the following libraries cannot be found: libstdc++ libgcc glibc Can anyone tell me where to find them? This is what I've done so far (logged in as root): apt-get install ia32-libs The answer I get is that ia32-libs is already installed in its latest version apt-get ia32-libs-dev The answer I get is that this package is not available but it can be replaced with lib32z1-dev, lib32bz2-dev and ia32-libs. When trying to install them I get a message saying that they're already installed in their latest version. Thank you very much for your help Irene Try compiling a hello world with gcc -m32 -o hello hello.c. If that works then you have to dig into icc to find why it fails. Installation doesn't fail. The Intel installer is terribly written, and queries your system's RPM database to ensure key packages are installed. Obviously, if your system isn't RPM-based, then you're out of luck. Ignore the messages if you can, bet to work on repackaging the installer RPMs if you can't -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confused about performance
Giacomo Mulas wrote: Two or three months, when I last compiled the latest version of the big quantum chemistry code (NWChem) I use (which spends a lot of time doing floating point linear algebra). The computer on which I tested is a relatively old Athlon 64 3500+, your mileage may vary on other machines. Oddly enough, an old version of GOTO was the fastest, followed closely by the optimised acml, then head to head the internal implementation provided by the quantum chemistry package and the (then) current GOTO, then atlas. Differences among all but atlas were measurable (i.e. reproducible) but very small, within 2%, atlas was ~10% slower. The Intel compilers produced much faster code than the gcc suite (both 3.4 and 4.1), despite running on AMD processors. This is a VERY specific test, of course, so I do not claim my conclusions should apply to anyone but me. On the other hand, they do apply rather well to my scenario by definition :) I used to do this stuff (tune quantum chemistry codes) for a living. Nostalgia ain't what it used to be. :) The only one I spent any great length of time on was Gaussian (80 way back then) and it proved extremely difficult to vectorize and parallelize, despite the efforts of the developers to make it work well on such beasts as the CDC 205, which had very deep pipelines. If NWChem is anything like that, I'm not surprised the Intel compilers do a better job than GCC -- I don't think GCC knows much about all the specifics of tweaking such things as keeping data in caches, re-use, chip-level parallelism, etc. If NWChem is open source, I'm sure someone will come along and profile/tweak it. I will obviously evaluate again atlas and new versions of the gcc suite if/when it's worth the effort. I look forward seeing an up-to-date version of atlas being included in debian. I would actually be very glad to be able to switch to a completely clean environment using gcc, since I currently have to keep around hosts of libraries compiled with different compilers and it's somewhat messy to maintain. I wouldn't throw away that Intel compiler just yet. For that matter, I'd give serious consideration to switching to a Core 2 Duo and a copy of Intel's tuning tools ... they are quite good. Life's too short to wait for calculations. :) Bye Giacomo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confused about performance
On Fri, 15 Jun 2007, M. Edward (Ed) Borasky wrote: had very deep pipelines. If NWChem is anything like that, I'm not surprised the Intel compilers do a better job than GCC -- I don't think GCC knows much about all the specifics of tweaking such things as keeping data in caches, re-use, chip-level parallelism, etc. If NWChem is open source, I'm sure someone will come along and profile/tweak it. Actually, gcc does not do a bad job at all for the x86, it's the performance of x86_64 code that sucks (so far). NWChem is not properly open source: the developers, at the NorthWest university, make it available (for free) on request, including sources, after filling in a form in which you agree not to redistribute it. Essentially they are glad if people use it, but want to retain control due to US export regulations (for some reasons some people think it is sort of strategic weapon? I don't know). It's good stuff anyway. I wouldn't throw away that Intel compiler just yet. For that matter, I'd give serious consideration to switching to a Core 2 Duo and a copy of Intel's tuning tools ... they are quite good. Life's too short to wait for calculations. :) Yes, sure. But also compiling, testing etc. kills heaps of time which I have better ways of using, e.g. publishing some good results of my calculations... :) bye Giacomo -- _ Giacomo Mulas [EMAIL PROTECTED] _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confused about performance
M. Edward (Ed) Borasky wrote: On Wed, Jun 13, 2007 at 04:40:52PM -0600, Sebastian Kuzminsky wrote: Hi folks, I just bought a pair of AMD64 systems for a work project, and I'm confused about the performance I'm getting from them. Both are identically configured Dell Dimension C521 systems, with Athlon 64 X2 3800+ CPUs and 1 GB RAM. On one I installed using the Etch (4.0r0) i386 netinst CD, then upgraded to Lenny. This one's running linux-image-2.6.21-1-686. On the other I installed using the current (as of 2007-06-13) Lenny d-i amd64 snapshot netinst CD. This one's running linux-image-2.6.21-1-amd64. The one with the x86 userspace and 686 kernel is faster than the one with x86_64 userspace and amd64 kernel. The difference is consistently a few percent in favor of x86 over x86_64. My only benchmark is compiling our internal source tree (mostly running gcc, some g++, flex, bison, etc). We're using gcc-4.1 and g++-4.1. I've tried it with a cold disk cache and hot disk cache, in both cases x86 is faster than x86_64. I was expecting a win for 64 bit. What's going on here? You've tried compiling with the jobs flag? make -j[n] Look here for more: http://www.cmcrossroads.com/content/view/7483/268/ Or the code isn't optimized for x86-64 New docs are out a few days: http://developer.amd.com/ Well ... 1. 32-bit isn't going away. The new chips are all going to be 64-bit-capable (and virtualization-capable, multi-core, etc.) but the software is going to lag that. 2. There are two reasons you'd want a 64-bit machine: a. You have a production application that *needs* a 64-bit machine. For the moment, most but not all of those are high-performance scientific computing. b. You want to develop 64-bit applications and interested on the NX bit for security. (how the openBSD guys ;-) c. You want a stable dual-, quad- or more Socket machine and dedicated Memory to each Processor. NUMA (maybe each Socket with a dual-, quad- or more Core Processor) d. You love free software and want free hardware too. AMD ist working together with the community from the beginning of AMD64 development and all specs about the Opteron and 8000er chipsets are open. e. You are only mad about opteron :-) - because manufactured in your county. - AMD is helping the community with LinuxBIOS. (Nearly all Tyan K8 Thunder's with 8000er chips can running it) - Opteron's make more moo ... Ciao Marco! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confused about performance
On Fri, Jun 15, 2007 at 06:50:57AM -0700, M. Edward (Ed) Borasky wrote: I wouldn't throw away that Intel compiler just yet. For that matter, I'd give serious consideration to switching to a Core 2 Duo and a copy of Intel's tuning tools ... they are quite good. Life's too short to wait for calculations. :) I don't suppose, for fun, it would be possible to compile debian amd64 on one of the good commercial compilers? Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confused about performance
Douglas Allan Tutty wrote: On Fri, Jun 15, 2007 at 06:50:57AM -0700, M. Edward (Ed) Borasky wrote: I wouldn't throw away that Intel compiler just yet. For that matter, I'd give serious consideration to switching to a Core 2 Duo and a copy of Intel's tuning tools ... they are quite good. Life's too short to wait for calculations. :) I don't suppose, for fun, it would be possible to compile debian amd64 on one of the good commercial compilers? Doug. You mean the kernel, or all of the packages, or both? ;) I don't think it would be much fun, given Debian's free software roots. ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
