[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Re: Still cryptic OOP syntax
- From: David Olofson <david@...>
- Date: Mon, 31 Jan 2005 10:06:34 +0100
On Monday 31 January 2005 08.50, skaller wrote:
> On Mon, 2005-01-31 at 17:02, David Olofson wrote:
> > However, my point is that even with inline special cases like
> > Lua, and those I used to have in EEL, still involve some
> > - and those waste large numbers of cycles very frequently.
> I do not disagree -- I just don't know. What I do know is
> that both users and language developers tend to be conservative,
> and rightly so. Thus a proposal needs to be fairly convincing
> that losses are small and those are worthwhile.
In the case of EEL, there isn't much to be conservative about, as it's
all pretty much brand new code that hasn't been optimized or tested
At this point, I'm just trying to implement the features I want
without creating too much of a mess, though I try to keep performance
in mind and allow for future optimization when it doesn't complicate
things too much. The idea is to get the features and mechanisms down
so they can stabilize before too much stuff depends on them.
> > It should also be noted that VM instruction decoding burns a major
> > part of the cycles when doing simple operations like this, so
> > on the actual operation isn't going to impact overall performance
> > that much.
> This may not matter: the number of CPU cycles hardly counts
> compared with cache spills.
Right, but I was thinking "wall clock" cycles, rather than the rather
irrelevant theoretical instruction cycle counts. Either way, one can
only conclude that for one reason or another, any form of VM
instruction decoding is rather expensive, compared to normal number
crunching code - and that it cannot be avoided.
One way to lessen the impact of instruction decoding is to go "extreme
CISC", reducing VM overhead by allowing more work to be done with
fewer instructions. SIMD isone way to go, but that tends to make life
hard on the compiler. Creating "combo" instructions for commonly used
macro operations is probably the first step.
In the case of EEL, there's even some plain refactoring of the
instruction set left to do. For example, a call is always a LIST
instruction to gather the argument list, followed by a CALL or CCALL
instruction. Might as well have the *CALL instructions create their
LISTs themselves, as they cannot be used without them, and even an
empty LIST needs to be created somehow.
Anyway, back to hacking...
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---