You really don't get it, do you. Even on a 32-bit processor like x86, there are programmer-visible (IN THE INSTRUCTION SET) 64-bit and 128-bit registers. The 64-bit registers are the double-precision floating-point registers (and in fact these are 80-bit extended-precision registers on x86), and the 128-bit registers are from SSE and the other Intel SIMD extensions. The terms 32-bit and 64-bit refer only to the size of addresses , not to all registers or anything else.

The rest of your post follows from your total ignorance, and I will ignore it.

64bit chunks of computations instead of 32bit chunks. So the data being 'computed' is in native 64bit chunks - and in theory could be twice as fast in an optimal pass.

Yes, you've managed to paraphrase the usual bullshit that you've been brainwashed with quite well. Here's a hint: the 32-bit x86 processors had 64-bit (and 128-bit) registers already.

2) 64bit CPU features - more registers, other AMD64/EMT64 features

Nothing to do with 64 bits, and certainly not a simple "factor of 2" in "data processing rates" or "instructions per clock cycle". As I said, newer architectures can certainly be faster for reasons that have nothing to do with 64 bit addressing, and which have nothing to do with hype about "factors of 2" gained by "going from 32 bits to 64 bits" (which is obviously twice as good, right?)

3) Combined memory read writes, for example in Vista x64 when a 32bit application is reading or writing to RAM the OS can often combine two 32bit read/writes into ONE 64bit read/write, thus speeding up RAM access.

See point (1): the 32-bit processors could do this already.

Bullshit.

You have a 64-bit data path even on old 32-bit processors: it's called double precision. And there are 128-bit data paths, too, on any 32- bit Intel x86 CPU for the past 10 years: MMX and SSE*. The width of the SSE registers (the single-precision SIMD extensions you are referring to) did not increase with x86_64/amd64/em64t.

The width of the widest data register has absolutely nothing to do with the size of the address space.

I was dismayed to see this old canard in Apple's MacOS Snow Leopard technology summary

64-bit computing [...] enables computers to process twice the number of instructions per clock cycle, which can dramatically speed up numeric calculations and other tasks.

Haven't people learned by now that this is total BS? 64-bit addressing is independent of instructions per cycle, bus width, or anything like that. (Of course, newer 64-bit systems may be happen to be faster for other, unrelated reasons.) The old "64-bit is twice as fast as 32-bit" is a line of hooey that has been sold to the public for years now (I recall it gaining prominence when Intel started promoting its Itanium plans), but I thought it was finally dying out.

It's quite hard to keep C++ libraries ABI compatible across releases, because of fragile base class problems as well as ABI changes with new releases of C++ compilers (grrr).

If your ABI changes, then your .so version number has to reflect this and software needs to be recompiled. My point was that, contrary to Tweenk's claims, if the ABI of a new library version is backwards compatible, the Unix/Linux .so versioning scheme can reflect this and software doesn't need to be recompiled.

With C libraries, it's usually possible to maintain ABI compatibility even when adding new features. Unfortunately, proper .so versioning cannot fix the many ways in which C++ sucks.

The .so name of a shared library under Linux encodes not only whether the library has been revised, but also indicates ABI compatibility.

If the library authors know what they are doing, when they release a new version of a library they will set the .so version number (different from the human-targeted source-code version number) to reflect which previous versions of the library the new release is compatible with. As a result, ABI-compatible software does not need to be recompiled.

See, for example, the shared-lib versioning documentation for GNU libtool.

LyX has built-in templates for RevTeX, so it works well with most physics journals. I occasionally run into a journal that uses a custom non-RevTeX stylesheet not supported by LyX, but it's always possible to get it to work with LyX. The easiest thing is to just format it for the journal at the very end, right before submission, by exporting LyX to LaTeX and then switching it over to the new style file (and any minor changes that requires). (It's also not too hard to write a new LyX template to use a new stylesheet if you want to do everything in LyX.)