Re: Re[2]: Still cryptic OOP syntax

[David Olofson <david@...>]

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 
those in 
> > Lua, and those I used to have in EEL, still involve some 
conditionals 
> > - 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 
thoroughly. :-)

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 
+/-50% 
> > on the actual operation isn't going to impact overall performance 
all 
> > 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 ---