Intel core i5 machine: install 32-bit linux and intel fortran or 64-bit?
News user
I recently ordered a new computer based on Intel Core i5-750 processor
which I think
is a 64-bit machine.
The question I have is what is more efficient in computations:
(a) to install a 64-bit linux with 64-intel fortran and mkl, or
(b) to install a 32-bit linux and 32-intel fortran and mkl
The machine is going to be used only for computations: thus my main
concert is
to run my fortran programs accurately and fast.
Specifically, my code is written in fortran 77 (plus the "common
extensions"),
parallelized with OpenMP commands and I use MKL for BLAS and LAPACK
routines.
So, is there any difference in the computation speed between the 32-
bit or 64-bit?
If not, for me it is easier to use the 32-bit software (linux/intel
fortran) since I also have
older 32-bit machines.
Thank you in advance,
/PB
jwm
I'd love for someone to stop the "64-bit is faster" hoax already.
If your computer has more than 3 GB of RAM or if you need some cross-
compilation, then the 64-bit option is better; otherwise, stick with
32-bit.
Tim Prince
> So, is there any difference in the computation speed between the 32-
> bit or 64-bit?
> If not, for me it is easier to use the 32-bit software (linux/intel
> fortran) since I also have
> older 32-bit machines.
Assuming you don't write anything big enough to take advantage of the
larger 64-bit addressing space, the answer is application dependent.
Sometimes, compilers will perform more optimizations for 64-bit mode, on
account of less tight space requirements, as well as the large number of
registers available. There are a few performance bugs in ifort, where
either of 32- or 64-bit mode is unnecessarily slow. 64-bit mode is
prevalent enough that more goes into optimizing compilers and libraries
for it.
There is no way you will be satisfied with the performance of a 9 year
old 32-bit CPU in comparison with the new one.
Tim Prince
> So, is there any difference in the computation speed between the 32-
> bit or 64-bit?
> If not, for me it is easier to use the 32-bit software (linux/intel
> fortran) since I also have
> older 32-bit machines.
Assuming you don't write anything big enough to take advantage of the
Carlie Coats
> On 2/7/2010 4:38 PM, News user wrote:
>
>> So, is there any difference in the computation speed between the 32-
>> bit or 64-bit?
>> If not, for me it is easier to use the 32-bit software (linux/intel
>> fortran) since I also have
>> older 32-bit machines.
>
> Assuming you don't write anything big enough to take advantage of the
> larger 64-bit addressing space, the answer is application dependent.
> Sometimes, compilers will perform more optimizations for 64-bit mode, on
> account of less tight space requirements, as well as the large number of
Our experience is that the extra registers/opcodes etc have a
significant (>10%) effect on the kind of scientific (environmental-
modeling) codes run by my group.
Additionally, extra RAM for I/O buffering may speed up processes
significantly: some benchmarks we've run show a 20% speedup going
from 8GB RAM to 32GB on an 8-core machine -- and that for a
meteorology model with a working set of only 1.6 GB, *far* under
either RAM size.
-- Carlie Coats
James Van Buskirk
news:88f9012a-3d99-4c5f...@w27g2000pre.googlegroups.com...
> I'd love for someone to stop the "64-bit is faster" hoax already.
> If your computer has more than 3 GB of RAM or if you need some cross-
> compilation, then the 64-bit option is better; otherwise, stick with
> 32-bit.
My perception is that it's the Fortran community that has been
quickest to upgrade to 64-bit once the capabilities became
available. If you have 64-bit code up and running it's much less
painful to increase the size of your model if you don't end up
near or over the limits of virtual address space.
Assuming Intel/AMD processors, you are giving up 1/2 of your
SSE (floating point) register file, 3/4 of your integer register
file, and more than 99% of your virtual address space if you use
a 32-bit environment when you could have been in 64 bits. This
really can make a difference in performance although quality of
code generated by the compiler on one platform vs. the other
usually has a much more significant effect.
As I see it, there is a more pressing issue for Fortran
programmers here: array indices can plausibly extend beyond
2**31-1, and when they do they must be represented by 64-bit
integers because 32-bit integers would overflow. For Fortran
there is a tricky point that a given compiler can usually be
induced to consider more or less all integers to be 64 bits
via a compie-time switch, but the use of these switches is
fraught with danger in that there is so much that could be
affected by such a change that I think the behavior of such
switches is probably not identical from compiler to compiler.
Also if the switch doesn't modify the default REAL kind it
throws storage association and thus one style of standard-
conforming code out the window.
For Fortran, if you don't want to lock yourself into
dangerous compiler switches as described in the previous
paragraph, the indices that can get big have to be retyped
as 64-bit integers and the inquiry functions that you get
your indices from have to be given the optional KIND=
argument. And did you want to test that it worked when
the indices really did get big? Good luck in a 32-bit
environment. I think that this is what is making Fortran
programmers earlier adopters of 64-bitness.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Richard Maine
> As I see it, there is a more pressing issue for Fortran
> programmers here: array indices can plausibly extend beyond
> 2**31-1, and when they do they must be represented by 64-bit
> integers because 32-bit integers would overflow...
[mentions some of the many messes that result]
> Good luck in a 32-bit
> environment. I think that this is what is making Fortran
> programmers earlier adopters of 64-bitness.
Note that a so-called 64-bit environment does not necessarily imply that
default integer size is 64 bits. There was a time when I thought that
would normally be so. I thus argued against adding the complications of
allowing non-default integers in several places in the language where
they hadn't been allowed before. I figured that the problems would be
addressed by making 64 bit sizes the default, at least on machines big
enough to run those kinds of apps, and so adding the new features was
needless complication. I appear to have been incorrect (and I lost that
argument).
Several vendors pointed out that there is way too much existing code
that would break badly if the default sizes were anything other than 32
bits. No, people shouldn't code like that, but yes, lots of them do. The
vendors have lots of reason to continue to keep such codes working, even
in "64-bit" environments.
The term "64-bit environment" is so much abused that one can't really
count on exactly what it does mean in all cases. You actually have to
ask about the specific features in question instead of counting on the
general term to cover it. In particular, if you want to know what the
default integer and real sizes are for a Fortran compiler, you have to
ask exactly that question. Asking whether the compiler is a "64-bit" one
(whatever that means) won't necessarily get you the right answer.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
glen herrmannsfeldt
> James Van Buskirk <not_...@comcast.net> wrote:
>> As I see it, there is a more pressing issue for Fortran
>> programmers here: array indices can plausibly extend beyond
>> 2**31-1, and when they do they must be represented by 64-bit
>> integers because 32-bit integers would overflow...
> [mentions some of the many messes that result]
>> Good luck in a 32-bit
>> environment. I think that this is what is making Fortran
>> programmers earlier adopters of 64-bitness.
It should be rare for programs to use array subscript values
larger then 2**31-1 when the array is small enough to fit in
the space available on a 32 bit OS. (2GB on many systems.)
> Note that a so-called 64-bit environment does not necessarily imply that
> default integer size is 64 bits. There was a time when I thought that
> would normally be so. I thus argued against adding the complications of
> allowing non-default integers in several places in the language where
> they hadn't been allowed before. I figured that the problems would be
> addressed by making 64 bit sizes the default, at least on machines big
> enough to run those kinds of apps, and so adding the new features was
> needless complication. I appear to have been incorrect (and I lost that
> argument).
> Several vendors pointed out that there is way too much existing code
> that would break badly if the default sizes were anything other than 32
> bits. No, people shouldn't code like that, but yes, lots of them do. The
> vendors have lots of reason to continue to keep such codes working, even
> in "64-bit" environments.
Then the DEC Alpha first came out, the C compilers that came with
it used (long) for the 64 bit type. That made sense (there wasn't
another type available) but again broke too much existing code.
In popular C implementations, (int) was either 16 or 32 bits,
(short) was fairly reliably 16 bits and (long) reliably 32 bits.
This was especially true in networking code where data structures
based on 16 and 32 bit integers are common. Later, a (long long)
type was added as the 64 bit type, and, I believe, the DEC compilers
were changed.
> The term "64-bit environment" is so much abused that one can't really
> count on exactly what it does mean in all cases. You actually have to
> ask about the specific features in question instead of counting on the
> general term to cover it. In particular, if you want to know what the
> default integer and real sizes are for a Fortran compiler, you have to
> ask exactly that question. Asking whether the compiler is a "64-bit" one
> (whatever that means) won't necessarily get you the right answer.
Well it comes up first in installing many operating systems,
including Linux and Windows 7. It is usually harder to reinstall
the OS than it is to (re)install a new compiler. Though the 32
bit versions of compilers and application programs should run just
fine on the 64 bit OS.
-- glen
JB
> Richard Maine <nos...@see.signature> wrote:
>> Several vendors pointed out that there is way too much existing code
>> that would break badly if the default sizes were anything other than 32
>> bits. No, people shouldn't code like that, but yes, lots of them do. The
>> vendors have lots of reason to continue to keep such codes working, even
>> in "64-bit" environments.
>
> Then the DEC Alpha first came out, the C compilers that came with
> it used (long) for the 64 bit type. That made sense (there wasn't
> another type available) but again broke too much existing code.
>
> In popular C implementations, (int) was either 16 or 32 bits,
> (short) was fairly reliably 16 bits and (long) reliably 32 bits.
> This was especially true in networking code where data structures
> based on 16 and 32 bit integers are common. Later, a (long long)
> type was added as the 64 bit type, and, I believe, the DEC compilers
> were changed.
I don't know which OS you're referring to, but all 64-bit Unix-like
systems I have used, including Digital Unix on Alpha, have been
LP64. Microsoft is AFAIK the odd man out, having chosen LLP64.
http://www.unix.org/version2/whatsnew/lp64_wp.html
--
JB
JB
> I'd love for someone to stop the "64-bit is faster" hoax already.
>
> If your computer has more than 3 GB of RAM or if you need some cross-
> compilation, then the 64-bit option is better; otherwise, stick with
> 32-bit.
The above is good advice, say, when working on many RISC architectures
where the difference between 64-bit and 32-bit environments is, well,
that addresses are 64 bits, nothing more really. Hence 64-bit programs
use more disk space, memory and, crucially, cache, and as a result are
typically slower than the equivalent 32-bit program.
However, for the nowadays rather common case of x86 vs. x86-64 the
situation is different. As already mentioned, the big change in 64-bit
mode is that the number of general purpose as well as SSE registers
are doubled. Also consider that some of the GP registers must be used
for the instruction pointer, stack pointer, base addresses,
accumulators etc. leaving only a few left for general variables out of
the 8 original ones, so in this sense the number of freely available
GP registers in 64-bit mode are closer to triple the amount in 32-bit
mode. More registers means more efficient software pipelining
optimizations such as loop unrolling, and reduces the need for
register spilling.
Also, x86-64 gives native 64-bit integers, something not available in
32-bit mode. So for (the few?) programs that need large integers, this
can provide a major improvement. And, even if your program doesn't
need more than 2 GB of memory, a 64-bit kernel can see all the memory
without remapping tricks like HIGHMEM in Linux. Finally, RIP
addressing reduces the overhead from PIC code (frequently used in
dynamic libraries).
Another set of improvements that x86-64 brought is related to a more
modern ABI. While this is not strictly speaking a feature of the
64-bit mode, as it would be possible to define a new and improved
32-bit ABI as well, in practice the improvements individually aren't
big enough to be worth breaking the ABI. E.g.
- Alignments better suited to modern processors vs. the 386 that most
32-bit ABI's are designed for.
- Use of SSE for floating point, getting rid of double rounding and
other issues related to the old x87 registers having different
precision and range than the variables in memory. Also, SSE code is
often slighlty faster than x87 code, even without vectorization
(perhaps because registers can be accessed directly without the
stack shuffling x87 needs?).
- Register-based calling convention, reducing procedure call overhead.
All things considered, the above improvements compensate for the
performance loss due to higher memory usage of 64-bit programs, often
so that 64-bit programs are slightly faster than the equivalent 32-bit
one. So IMHO the advice for x86 vs. x86-64 should nowadays be the
opposite of what jwm suggests above; that is, use x86-64 unless you
have some specific reason not to.
--
JB