Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Operation Latencies kernel_learner@yahoo.com (2004-02-08) |
| Re: Operation Latencies touati-nospamplease@nospam-prism.uvsq.fr (TOUATI Sid) (2004-02-12) |
| Re: Operation Latencies tmk@netvision.net.il (2004-02-12) |
| Re: Operation Latencies tommy.hoffner@ericsson.com (Tommy Hoffner) (2004-02-13) |
| From: | TOUATI Sid <touati-nospamplease@nospam-prism.uvsq.fr> |
| Newsgroups: | comp.compilers |
| Date: | 12 Feb 2004 11:02:16 -0500 |
| Organization: | Universite de Versailles Saint-Quentin-en-Yvelines |
| References: | 04-02-090 |
| Keywords: | optimize, architecture |
| Posted-Date: | 12 Feb 2004 11:02:16 EST |
Memory access latencies are unknown at compile time. Compilers have two
choices\,:
1- being optimistic : assume the data in cache. So the latency is a
cache access. This is the most usual action that compilers do;
2- being pessemistic : assume data in memory. Huge static latencies
would suffer the register allocator and ILP scheduler.
There is some research papers that try to classify memory accesses
depending if they would be assumed as cache hits or misses. Meanwhile,
you can never assert at compile time if this data would be in the cache
or not (many dynamic phenomenas arise, interactions with OS, etc). All
what you can do is to hope that what you guessed at compile time would
happen at execution time
S
Return to the
comp.compilers page.
Search the
comp.compilers archives again.