[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: confused about performance



Leopold Palomo-Avellaneda wrote:
> A Dijous 14 Juny 2007 16:40, M. Edward (Ed) Borasky va escriure:
> [...]
>>    b. You want to develop 64-bit applications
> 
> why? you want to develop applications, that they run in a 32 or 64 system it's 
> another thing. Maybe they run "better" or worst, but the final architecture 
> cannot be a target, I think.
Well in my case the "fun" is developing 64-bit multicore applications
and maxing out the machine. I'm not doing this with a profit motive as
yet, so I don't have a problem with limiting myself to things that will
only run in a 64-bit machine and which are tuned for multicore.
> 
> [...]
> 
>> As far as the applications in the Debian pool, or open source in
>> general, are concerned, I would first look at large-scale scientific
>> computing. And I would start with making sure that you have the Atlas
>> (automatically tuned linear algebra subroutines) libraries and their
>> BLAS and LAPACK interfaces all tuned up and ready to install on all the
>> architectures. The ATLAS team is just about ready to release 3.8 -- they
>> are at 3.7.32 at the moment and I think what's in Debian is still 3.6.0.
> 
> ok, but I think that this apps are developed in fortran, and the gfortran is 
> it sufficient developed to make a good difference? Maybe GSL or MTL ..

I don't do much FORTRAN and even less C. When I want raw speed I program
in Forth, and when I want convenience I use R for number crunching, Perl
for quick scripting and Ruby for longer-lived scripting projects.

> 
>> The last test I ran on my Athlon64 X2 4200+ (2.2 GHz) got me about 10
>> gigaflops in 32-bit arithmetic and about half of that in 64-bit arithmetic.
> 
> I don't understand that. Are you saying that the 64-bits was really worst than 
> 32? 

It's natural that 64-bit operations would take longer than 32-bit ones.
You're moving and adding/multiplying half the number of bits. That's
kind of a cheat, though, because only some signal and image processing
operations and some iterative particle-based/simulation models work
really well in 32-bit arithmetic. Big matrix jobs require 64-bit
arithmetic and sometimes more. But you can do a *lot* of physics, signal
processing and image processing with a fast 32-bit floating point unit,
so it's a useful thing for at least one class of user.



Reply to: