OSNews

Title should read "What Every GNU/Linux Programmer Should Know About Memory, Part 1"

I suggest the title "Details that no programmer needs to know about memory" instead. Hopefully the later parts will cover useful topics.

... I try to play memory games, to increase my memory and do not have memory leaks or overflows.

I can't wait for the rest of the paper to be published. This was a very interesting read. Memory management is essential to any good programmer, it's what seperates the hard-core coder from the weekend enthusiasts who slap stuff together in .NET and call themselves a "programmer".

already send it to the Firefox team...

Extremely opinionated, biased pro-Intel anti-AMD, mostly correct but in some cases deceptively wrong.

Wrong: read a few paragraphs and start seeing comments like "this setup will introduce a NUMA architecture and its negative effects". He also likes talking about FSB speeds to memory - a FSB is CPU-NB, a memory bus is NB-RAM, and modern NUMA systems independently clocks the two buses. (It is useful to use different speeds - "spread spectrum" - because memory and I/O devices have different clocking requirements.)

Biases: for NUMA, many people consider it a good thing because NUMA scales much better than shared-FSB designs. He touts FB-DIMMs as superior to DDR3 without mentioning that the buffering in FB-DIMMs increases latency - in reality, FB-DIMMs do better than DDR on Intel chips with fat caches, and *cheaper* DDR chips do better than FB-DIMMs on AMD chips with more sensitivity to latency.

There are a lot of real engineering tradeoffs here; Ulrich isn't describing the tradeoff, he's just saying "A is better" without justification. Frankly, this piece is so biased towards Intel's choices that it looks like it was commissioned by Intel PR.

Although I felt some of his statements were opinion pieces rather than fact this was the most interesting article I've seen on here in a long time!

Thank you!

...memory is free. Use as much of it as you want... and don't bother freeing it up. It will free up when your application stops.





I AM KIDDING!

haha, what an article "In the early days computers were much simpler." ... well, that article is basically not relavent as the systems I mainly program on (when not at work) are what they are talking about "In the early days".

I was thinking, If addressing is such a huge cost, why not avoid it entirely.

What if the memory modules just cycled through it's rows as fast as it could letting any interested device do it's reading or writing at the right time.

Waiting for the memory to cycle through would be murder on latency though. But in an era of multicores and parallel execution maybe the right blend of multitasking and ingenious algorithms for memory allocation in the OS could make it viable.

What do you think?

Memory remains a huge bottleneck in systems, yet coders have been moving toward larger and larger routines to do the same thing - in the name of speeding things up.

About a year ago a coworker had some code that he couldn't figure out why in Borland C it ran almost instantly, but in GCC was taking about a second per iteration (which over a few hundred iterations dragged a realtime program down to unusable). GCC makes notoriously slow code (the price of multiple targets), but this was above and beyond the norm.

Even stranger after some playing he found turning compiler optimizations OFF it ran even faster... that's when he got hold of me and I dragged out the dissassembler.

Optimizations on, GCC was taking what should have been a simple LOOP with three memory references that could have been stored in registers, to use a single MMX opcode.

The problem was, the overhead to set up for that MMX opcode involved allocating 128 bytes of memory for two matrixes... If he was performing the same general operation back to back the MMX version would have been faster because it unrolled the loop, but the overhead of setting up for it not only made the code not fit in the L1 cache, but it didn't even trip cache because each iteration was too different. Basically it allocated 128 bytes of memory each pass (and released it each pass) and used about 512 bytes of machine language for what we were able to quickly rewrite as maybe ten lines of ASM (therin 15-20 bytes of code), entirely using registers inside the loop and only passing three dword values on the stack.

Programmers, especially those writing compilers seem to have forgotten one of the most basic rules of writing code - the less code you use, the faster the program and the less code there is to BREAK. You'll hear the arguement repeatedly that many of these new techniques are faster and the older smaller code is slower - and it's utter and total bull MOST (but not all) of the time. You see this attitude in most all forms of programming these days where one way of doing things is completely thrown out in favor of another, the new method amounting to trying to shove that square peg into the round hole.

When it's the difference between small tight code and multiplying memory access by a factor of ten, increasing memory access inside the loop, getting cache misses and not even fitting the code and values inside the L1 cache, I know which way I lean on this.

Minimalist code can often remove the memory bus concerns inside loops from the equation - especially if you arrange your code to make use of the piping capabilities of newer processors... because while it's off grabbing memory you can keep it executing other stuff.

Edited 2007-10-07 16:31