Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| [6 earlier articles] |
| Re: Dynamic Typing Efficiency eliotm@pacbell.net (Eliot Miranda) (2005-05-09) |
| Re: Dynamic Typing Efficiency jeffrey.kenton@comcast.net (Jeff Kenton) (2005-05-09) |
| Re: Dynamic Typing Efficiency clearm@comcast.net (2005-05-13) |
| Re: Dynamic Typing Efficiency alexc@TheWorld.com (Alex Colvin) (2005-05-13) |
| Re: Dynamic Typing Efficiency calumg@onetel.com (Calum Grant) (2005-05-13) |
| Re: Dynamic Typing Efficiency angray@beeb.net (Aaron Gray) (2005-05-16) |
| Re: Dynamic Typing Efficiency DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2005-05-18) |
| Re: Dynamic Typing Efficiency jeffrey.kenton@comcast.net (Jeff Kenton) (2005-05-22) |
| From: | Hans-Peter Diettrich <DrDiettrich@compuserve.de> |
| Newsgroups: | comp.compilers |
| Date: | 18 May 2005 00:49:03 -0400 |
| Organization: | Compilers Central |
| References: | 05-05-04105-05-054 05-05-056 05-05-139 |
| Keywords: | interpreter, performance |
| Posted-Date: | 18 May 2005 00:49:03 EDT |
Aaron Gray wrote:
> That's probably the right approach. switch and case probably wins out
> over arrays of pointers to functions for modern cpu and
> caches. Although if you look at the assembly code you will probably
> find a chained list of comparisons and jumps ! So I would put your
> most common cases first !
Comparisons IMO will occur only with sparse arrays, or just in the
case of an dumb compiler and an unorderer (reordered) list of
conditions. I wouldn't try to be cleverer than the compiler, with the
need to prove that cleverness with every change to my tables. Or would
you really provide manually optimized source code, different for all
machines and compilers, existing or yet to come?
DoDi
Return to the
comp.compilers page.
Search the
comp.compilers archives again.