Why 64 bit? [LWN.net]

Why 64 bit?

Posted Sep 13, 2006 4:54 UTC (Wed) by bryanr (guest, #25324)
In reply to: Why 64 bit? by TwoTimeGrime
Parent article: What you should (and shouldn't) expect from 64-bit Linux (Linux.com)

- AMD64 has more registers than IA32 -- resulting in fewer spills to memory (load/store ops)

- The wider registers mean fewer cycles are used during memcpy and
related operations (the CPU can load/store 64 bits of data per ins
instead of 32)

- Modern CPU instructions are always enabled on AMD64. Many "i686"
distros have gcc schedule code for an i686 pipeline, yet only emit
instructions present since i486 (penalizing new hardware to ensure
compatability with old)

(Log in to post comments)

Why 64 bit?

Posted Sep 13, 2006 17:53 UTC (Wed) by raven667 (subscriber, #5198) [Link]

> Modern CPU instructions are always enabled on AMD64. Many "i686"
> distros have gcc schedule code for an i686 pipeline, yet only emit
> instructions present since i486 (penalizing new hardware to ensure
> compatability with old)

I don't believe that to be accurate. I'm pretty sure that the the acutal object code does runtime cpu
detection and has seperate optimized code paths for i386/486/586/686/etc. so there should be no
difference when using -march=i386 and -mcpu=i686.

Why 64 bit?

Posted Sep 13, 2006 20:41 UTC (Wed) by nix (subscriber, #2304) [Link]

Doesn't that depend on the software?

(Some builds of speed-critical stuff like OpenSSL use the CPU hwcaps and
the per-hwcap library feature of glibc to produce builds optimized for
appropriate processors: look for e.g. /usr/lib/i686 or /usr/lib/v9...)

Why 64 bit?

Posted Sep 14, 2006 2:42 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> Doesn't that depend on the software?

I don't believe so, what I understand is that if you use both -march and -mcpu gcc will put in
optimized code paths seperate for each. There will be a fallback for i386 but optimized code for
i686. The binary will obviously be larger as it may contain multiple implementations of the same
code.

At least that's how I understand how it works, but I can't find a find a reference quickly. Maybe
someone more knowledgable than I can comment?

Why 64 bit?

Posted Sep 14, 2006 6:47 UTC (Thu) by khim (subscriber, #9252) [Link]

When everything else fails, RTFM.

And here we go:
-mtune=cpu-type: Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions.
-march=cpu-type: Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type.
-mcpu=cpu-type: A deprecated synonym for -mtune.

Nothing like "separate code path", "fallback for i386" and other such nonsense. If you are specifying "-mcpu=i386 -mtune=i686" it just means: "try to optimize for i686, but don't use anything except i386 instructions". Quite sad, really: C++ code expirience can slowdown up to 30-40% with such options but usually just 5-10%.

Autoselection can be done (kernel does it in some configuration, OpenSSL does it, GLibC does it, some other programs are doing it - but that's up to application developer, compiler will not help you there... Where have you got ridiculous idea that it's task for the compiler - I do not know...

Why 64 bit?

Posted Sep 14, 2006 18:57 UTC (Thu) by nix (subscriber, #2304) [Link]

OpenSSL doesn't do it, as far as I know (it can't; many critical-path
things are macro-expanded). Instead, distributors use glibc's hwcap
mechanism to select appropriately-compiled OpenSSL libraries for the
hardware at dynamic link time. (This is especially useful on e.g. SPARC,
because of SPARCv7's lack of integer multiply instructions.)

Why 64 bit?

Posted Sep 13, 2006 21:16 UTC (Wed) by dberkholz (subscriber, #23346) [Link]

Only in code specifically written to do so, e.g. Mesa.