This is not about saving RAM, but improving cache utilization. It's not that hard to simply roughly double the existing cache by reducing the size of pointers. As caching is THE most performance improving optimization available on CPUs, this has profound improvements on run times. x32 can still support systems with many, many GBs, but each individual process space is limited to 4 GB.

No, you don't. The libraries will be paged in on-demand. If you never use more than 4 GB address space within a single program, the amd64 libraries will never be paged in. Typically, I-cache lines will be driven by LRU, so you'll have them filled also on a on-demand basis.

That's a pretty ignorant stance. Your PPro didn't have the expressive abilities of the newer registers, instructions, and enhanced SIMD systems, let alone the performance improvements.

You should learn how virtual memory and cache works before spouting this bullshit.

Most users will never need 64-bit pointers. Only applications which require more than 4 GB of addressable memory within that single program will ever use this. Examples of such applications include in-core scientific computing and very large media file editing.

Nope. I'm only tangentially aware of this issue because this second analysis came out this last week and has been making the rounds.

I wouldn't be so sure that programming wasn't the source of the problem. There's been a lot of work to understand the ECU on the Camry and it is beginning to look like some severe bugs lurk within: http://www.viva64.com/en/a/0083/

If you're only looking at some data, you're probably not very good at turning data into information.

comment to undo mod

Is this the fault of the technology, as the premise of this article claims?

And I learned all that on an old Intel 80386 long before touching my first microcontroller. Beyond that, 80386 architecture supports virtual memory, something the developer should be keenly aware of and isn't available on microcontrollers.

You mean like the backup generators that failed during the tsunami, and subsequent meltdown that was caused by the failure?

Then you're likely a waste of time and detriment to your team.

I have had conversations with some of my friends who work on the peta-scale clusters and thought much the same as you. But, it turns out, when you're working with that level of system, you're probably addressing some small part of a much, much larger problem that has been largely solved. The existing code that performs 99.9% of your task is written in Fortran and actively developed by a very successful team of researchers. Attempting to rewrite the working, debugged, code so you can work in your favorite language today is not only impossible, but would likely get you removed from the team.

Compilers often cannot make optimizations in C/C++ and similar languages because of how flexible the languages are to the user's needs. Fortran, on the other hand, is more restrictive and the compiler can make guarantees about aliasing and alignment that permit things like autovectorization. This really is a part of the core language, not just the result of monumental resources put at the issue.

I'm not 100% sure on that. Languages like Go have brought in a lot of the same things, like language-level concurrency. However, Fortran has really been designed to address the problems that are solved on supercomputers first and general language second. This makes it far easier to focus on the task at hand instead of working around limitations in the language.