Hi Neil! On Fri 26 Jun 2009 00:47, Neil Jerram <n...@ossau.uklinux.net> writes:
> Andy Wingo <wi...@pobox.com> writes: > >> I don't have Neil's mail open here, but my thought was this: getting a >> fast VM is a dark art of feeling and instinct, My feeling is that a VM >> is fast if it fits in the CPU's cache: the instruction cache and the >> data cache. The data cache means that smaller code is better, hence my >> resistance to word-sized instructions. The instruction cache means that >> the VM itself should be small -- but if the code for vector ops is all >> "at the end" of the VM, then only code that uses vector ops pays for the >> increased "cache footprint" of the VM. > > Thanks, I see now. But presumably even VM code will frequently call > out to primitives all over libguile, won't it? Over time, I'd say no. I see functions written in C migrating over to be written in Scheme, like PLT did recently with `map'. We should port srfi-1 back to Scheme I think :) Not to mention silly things like string-any being in boot-9... There's no reason for Scheme to be slow. Of course, this is the "over time" view, currently we're not there... And yet, disassemble the functions that you use regularly, and often you find they just use VM ops, and don't call out to primitives. That shows that the VM is, while virtual, still quite a good machine for computation. > I completely agree that small code size can be important for > performance, but I doubt that it is the size of the VM on its own that > matters. Depends on what percent of time is spent in the VM. On previous profiling runs, this was 30-60% of program run time -- well worth optimizing. Cheers, Andy -- http://wingolog.org/
