| View previous topic :: View next topic |
| Author |
Message |
teapot
Tux's lil' helper
Joined: 09 Nov 2006
Posts: 85
Location: Stockholm , Sweden
|
 Posted: Fri Feb 02, 2007 12:49 pm Post subject: Memory alignment |
 |
|
Hello.
My Computer Science textbook : Computer Systems , Bryant , O'Hallaron - says that the -malign-double gcc flag could potentially increase memory performance , possibly breaking compatibility with code compiled assuming 4-byte alignment.
According to the book - Microsoft uses 8-bit alignment in their operating systems. It is a better choice when you have lots of memory in your computer.
Does anyone have a track record with this flag? Is it worth a try to compile an experimental system on a separate partition? |
|
| Back to top |
|
 |
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Fri Feb 02, 2007 7:19 pm Post subject: Re: Memory alignment |
|
|
| teapot wrote: | | Does anyone have a track record with this flag? Is it worth a try to compile an experimental system on a separate partition? |
Not really. If you use any of the -m switches (with the exception of a few comparatively harmless ones like -momit-leaf-frame-pointer and the like) you will have to recompile the entire system, starting with glibc, since almost every non-trivial program uses FP math and passes FP values to and from its libc. The gains you will see (or rather not) will fall inside the acceptable margin of error for performance measurements. You can of course try it just for the heck of it, but don't expect any performance gain that would actually matter.
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
teapot
Tux's lil' helper
Joined: 09 Nov 2006
Posts: 85
Location: Stockholm , Sweden
|
| Posted: Fri Feb 02, 2007 10:26 pm Post subject: |
|
|
Ok , the book says:
"With modern processors , Microsoft's alignment is a better design decision. The command line flag -malign-double causes GCC on Linux to use 8-byte alignment for data of type double. This will lead to improved memory performance , but it can cause incompatibilities when linking with library code that has been compiled assuming 4-byte alignment."
So I thought that there was like a 1-2% performance increase in float-heavy code.
Not worth mentioning the exact compiler flag if it is totally useless ...  [/b] |
|
| Back to top |
|
|
moocha
Watchman
Joined: 21 Oct 2003
Posts: 5722
|
| Posted: Fri Feb 02, 2007 11:30 pm Post subject: |
|
|
| teapot wrote: | Ok , the book says:
"With modern processors , Microsoft's alignment is a better design decision. The command line flag -malign-double causes GCC on Linux to use 8-byte alignment for data of type double. This will lead to improved memory performance , but it can cause incompatibilities when linking with library code that has been compiled assuming 4-byte alignment." |
Some of the problems I'm having with that quote:- Vague terminology. Exactly what is "increased memory performance"? Read, write, latency, throughput, system-to-cache, cache-to-core, misaligned read cost, some-other-of-the-hundred-odd-metrics-I-could-come-up-with? I'm not even going to bother hoping that the author of that quote actually ran some measurements.
- Improving one specific aspect of the system doesn't necessarily mean the system performs better. Extreme example: Unroll all loops. From the point of view of the execution units, that will mean a performance increase. However, from the point of view of the prefetcher, decoder and branch prediction units, this is a disaster because such code will happily trash the L1 and L2 caches, leading to an overall performance decrease that will eat up any increase in execution speed for that particular code path, and then some.
- "1-2%" is basically synonymous with "exactly the same" on anything but specialized systems running specialized applications a la CGI rendering, physics and medical simulations, etc. I also don't buy into the "yes, but it will speed up video processing" school of thought. Yes, it may speed up some video encoder application, but unless that encoder happens to run its own operating system it may kick more of the actual operating system code out of the caches.
- It should read "will cause incompatibilities" instead of "can cause incompatibilities". Based on the same assumption as that quote itself ("modern processors"), a one in a million chance of hitting a particular incompatibility means it will happen next week, not next millenium.
In short, I have yet to see a "real world" application where optimizations like this would matter even one iota. You'll get better results, by orders of magnitude, if you spend the time on optimizing the algorithms used by your software than you will by chasing 1-2% differences from compiler optimizations. From the end-user (i.e. runtime) point of view, the single most important compiler flag is -march, followed by -O. The rest is collateral.
Besides, think of the testing requirements. If you deviate from mainstream, your testing effort will inevitably go up (fact of life - stuff used by more people is better tested by definition). What's more important - having a program give correct results, or having it give results faster? I personally think that if results are incorrect, it's pretty much immaterial how fast I get them... 
_________________
Military Commissions Act of 2006: http://tinyurl.com/jrcto
"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety."
-- attributed to Benjamin Franklin |
|
| Back to top |
|
|
teapot
Tux's lil' helper
Joined: 09 Nov 2006
Posts: 85
Location: Stockholm , Sweden
|
| Posted: Sat Feb 03, 2007 12:13 am Post subject: |
|
|
Ok. I was suspicious like you , but I can't hide from the fact that the authors knows a lot more low-level computing than me.
I wonder if Matlab , for example , will run. Every binary only application is in the risk zone. And the probability of failure is likely more than one in a million
It was just a thought... |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
