Pi performance fun

> 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; [hidden email]; http://www.rowledge.org/tim
> If a train station is where the train stops, what is a work station?
>
>
>

> 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; [hidden email]; http://www.rowledge.org/tim
> If a train station is where the train stops, what is a work station?
>
>
>
>

> 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; [hidden email]; http://www.rowledge.org/tim
> If a train station is where the train stops, what is a work station?
>
>
>