Hi Tim,

You used the Green Book benchmarks, right? Can you publish them?

Cool stuff!

Cheers,
Juan Vuletich

Quoting tim Rowledge <tim at rowledge.org>:

> A Raspberry Pi is not a terribly fast machine; after all, it's only  
> 700MHz with a fairly slow memory system. It's only $35 for ghu's sake.
>
> Still, it turns out that with some work you can make it do things  
> reasonably quickly. I've been working on getting the stack vm  
> running as a precursor to a full Cogit and the results are quite  
> pleasing so far; it's around 50% faster than the plain interpreter.  
> That's not a huge change but one must remember that the stack vm is  
> really just a way of introducing the new stack and object memory  
> underpinnings - the interpreter is barely changed.
>
> As part of the benchmarking for this work and some exciting changes  
> to BitBLT for ARMs I resurrected the ancient PARC benchmark code we  
> used to use in the days of striving for Dorado equivalent  
> performance. They're not really useful for much more than historical  
> (an romantic) comparison but the cool thing is that
> a) in a modern image that show that indeed the stack vm is 50%  
> faster, agreeing with much bigger benchmarks
> b) using a very old image that I used to benchmark changes to the  
> 2.8 era VMs, we see that the Pi running the plain interpreter scores  
> about the same as a 600MHz pentium 3 did in '00. It's about the same  
> as my old Iyonix ARM machin, too - that was a 600MHz  
> intel(!)StrongARM 80321 with a very fast (for the time) memory and a  
> fast (for the time) graphics card. Either machine cost around 100  
> times as much as the Pi does now; add inflation. This old image  
> cannot run on the stackvm due to the Great Image Shift.
>
> The BitBLT work is quite interesting since it involves usurping the  
> normal generated plugin to redirect to some very carefully written  
> assembler code. You can do quite amazing things with the latest ARM  
> graphics systems and knowledge of how to preload lines for the cache  
> and interleave processing with the load queue and all without  
> sacrificing too many virgins. Whether it will provide any useful  
> lessons for other platforms is an open question; after all, we  
> probably ought to be moving away from relying on bitblts and towards  
> more modern vector libraries etc.
>
> If any of you have Pi's and want to help with testing etc, let me know.
>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> If a train station is where the train stops, what is a work station?
>
>
>
>



Cheers,
Juan Vuletich