Is Scratch really viable on Raspberry Pi?

[Clifford]

My son has been using Scratch at school and has been asking me for help with his project (I am a professional software engineer). I decided to learn Scratch (didn't take long) in order to be able to help him. I wrote a simple Asteroids-like game in Scratch for Windows. It has 6 sprites - 4 identical asteroids, a ship, and a laser-cannon shot, each one has a moderately complex script including event handlers. It flies in Windows as you might expect, but still uses a substantial amount of CPU at times, but is entirely unusable on the RPi. It improved a little with the recent Debian Wheezy release with hard-floating point but not enough to make it usable.

It is not just the game execution that is slow, simply loading the project slows the IDE down such that it becomes unusable. For example if you try to drag a block it takes several seconds before it moves, and so is difficult to place accurately and no real fun at all.

The CPU load all the time Scratch is running is 100%, and if I try to maximise the window, the whole thing just hangs - or at least does nothing for longer than I care to wait!

Having used it on Windows I think it is great (apart from having to create independent duplicates of sprites rather than true multiple instances), but on RPi I can't see it being usable for all but the simplest projects that won't really teach much about programming.

Scratch is quite slick visually and from a usability point of view, but I suspect that under the hood there is some pretty inefficient programming made viable by fast CPU/GPU hardware, but just too much for the RPi - perhaps it is not making good use of the hardware available, I would expect the ARM11 at 600MHz with floating point and a GPU to cope with this.

[Clifford]

OK, I did a little research, and it seems that Scratch is written in Squeak Smalltalk which uses a virtual machine architecture. Great for cross-platform portability perhaps, but not so great for performance.

So I think that Scratch performance is seriously compromised by its implementation, and highly dependent on the performance of Squeak. It seems that there is a JIT VM for Squeak called Cog that boosts performance 2 to 10 times (http://forum.world.st/Teleplace-Cog-VMs ... l#a2261896). Unfortunately Cog generates x86 code at present, so that is not a solution.

Native code compilation would almost certainly solve the problem, the Exupery project is one such compiler, but again only fro x86 and a work-in-progress.

Smalltalk to C conversion would allow the code to be compiled with GCC, but I doubt it is as simple as that may seem. This approach is used for the Squeak VM itself (http://www.fit.vutbr.cz/study/courses/O ... k00067.htm) which written is in itself, but compilation rather running on the predecessor VM makes the VM 450 times faster (and therefore usable). It follows therefore perhaps that Squeak code running on the VM might be 450 times slower than equivalent C code. That's quite a hit and would make Scratch perform like C code on a 2MHz machine, and the programs you write in Scratch even slower!

My conclusion at present (and I admit my analysis is somewhat simplistic), is that Scratch is not realistically viable on RPi. A shame.

If anyone wants to try this project (on any platform), it is available at http://scratch.mit.edu/projects/cliffor ... be/2697920 Maybe I've done something really dumb and it is not as bad as I think!?

[antiloquax]

Interesting comments. I use the Arch distro and Scratch runs pretty well (although a bit slower obviously compared to my dual-core PC).
I am going to download your game and have a go!
Scratch is quite central to the Foundation's Aims, I'd say, since it's the program that will be most helpful in getting younger children into programming.
mark

[antiloquax]

Hi Clifford,
I really enjoyed playing your game. I haven't tried it on my Pi yet ...

[Clifford]

Hi Clifford,
I really enjoyed playing your game. I haven't tried it on my Pi yet ...

Thanks; I found a few other asteroids-type implementations on the Scratch site, I tried one that appeared to be most complete and it too ran very slowly.

I noticed that the MagPi issue 4 is featuring a Frogger type game - I may take a look; perhaps I am using some feature of Scratch best avoided?

It would be really nice too if sound worked in the standard distro out of the box.

[antiloquax]

Hi Clifford,
Sorry I haven't replied - I forgot to "watch" this topic.
I took the liberty of having a play with your code.
I changed a couple of things (mainly just reducing the "wait" times and making some of the sprites take a bit more "responsibility" for what happens).
I am not a very experienced Scratcher yet, but see what you think!
mark
Asteroids Edit

[Clifford]

I'll take a look at it as soon as possible.

Apart from the execution performance, I had trouble even editing the code on the RPi. Even modifying the delays (which were essential to playability in Windows) was near impossible due to the lag between an action with the mouse and anything actually happening,

[simplesi]

Well your not wrong - its unusable on an RPi

Now to be fair, its prob not what 7-11 year old pupils would be knocking up in my schools so I'm not too worried

But no - there is something seriously wrong somewhere - lets find out whats causing the CPU load even when not running - i'm suspecting its using too much RAM and might be continously swapping maybe

Si

[simplesi]

Well - its the displaying of the scores variables that's eating the CPU even with the scripts stopped.

Stop displaying them and the CPU load drops to normal Scratch idle levels -so at least you can edit it now.

It plays slowly but at least it plays - we need to check Scratch out on other platforms (PC/MAC/other linux) and see if its common issue or just something to Linux implementations or just RPi implementation.

We need to find who did the porting and get them on-board

Simon

[asb]

Well - its the displaying of the scores variables that's eating the CPU even with the scripts stopped.

Stop displaying them and the CPU load drops to normal Scratch idle levels -so at least you can edit it now.

It plays slowly but at least it plays - we need to check Scratch out on other platforms (PC/MAC/other linux) and see if its common issue or just something to Linux implementations or just RPi implementation.

We need to find who did the porting and get them on-board

Simon

Basically no work has been done to optimise Scratch on the Raspberry Pi specifically. We just run squeak-vm and squeak-plugin-scratch compiled for ARM, and the same Scratch image that you would use on any other architecture. What would be interesting is to look at profiling performance issues - both with the SqueakVM profiling infrastructure and oprofile/perf or whatever.

[jackokring]

It seems like you have a set of graphical templates and some syntax rules to lexx/yacc. Total re-engineering from duplicate but faster action, especially as the window tool set can be normalized too, is best in the long run. A learn smalltalk, translate to java, and compile to C, with C++ window toolkit adaption? It's really coding by tetris. If only the arcade scrolling of blocks was not so addictive, maybe keyboards would rattle with the sound of C.

cheers Jacko

[antiloquax]

Very interesting comments. I'll try running without displaying the scores.
I hope something can be done to improve Scratch on the Pi!
mark

[simplesi]

Just a small addition to the situation - even just decalring variables in Scratch "seems" to increase CPU load (even when prog not running!) on the RPi but the same thing didn't "seem" to happen on a "proper" laptop running Ubuntu12 (This was just some quick testing at @MrcRaspJam yesterday and I don't have figures to back it up)

I'm talking about this on the Scratch forums as well but if anyone has direct contacts with Scratch MIT bods then give them call please

Also, its not actually a show stopper for me as when I work with primary kids in schools, we don't normally use variables in our projects and if you don't have any - its seems to work fine - so you can get on with doing some things

Simon

[simplesi]

BTW here is Scratch being viable on a RaspberryPI

http://cymplecy.wordpress.com/2012/08/1 ... ic-lights/

Si

[simplesi]

Well, there is something very strange going on - I just tried out AsteroidBlaster again - I loaded it - unticked showing the variables and pressed Green Flag and it ran fine.

When I say fine, I mean it ran at a reasonable speed (slow) for a game of this complexity running on a 700Mhz machine

And its editable (slow but editable)

I do run BTW with a Class 10 SD card but no-overclocking yet.

We are going to really need someone with Advanced Linux skills to find out what is happening

Simon

[Clifford]

It certainly ran faster without the variable display, which I have used here for score and lives display but the feature to display them is presumably intended as a debug aid. It is a shame that it appears to cripple teh tool.

There was still a significant lag and first scratch hung then the entire RPi.

I can see this getting very frustrating for teachers and students.

[simplesi]

There was still a significant lag and first scratch hung then the entire RPi.

Well - My Rpi has been ultra stable and so has Scratch and I've been hammering it with my GPIO stuff for 2 weeks

http://cymplecy.wordpress.com/2012/08/1 ... ic-lights/

Maybe your Rpi has other issues as well as this main Scratch one

I can see this getting very frustrating for teachers and students.

Thats why us geeky types are getting them first to hopefully sort out issues.
Here is a short video of it running on mine -compare it with yours and see if the Class10 SD card makes things noticeably faster
http://youtu.be/nxuuTKo7INs

Simon

[mintsource]

although it is not directly dealing with your issue. the next version of scratch 2.0, is apparently due sometime this year and it will be Flash based rather than the current architecture.

http://wiki.scratch.mit.edu/wiki/Scratch_2.0

this may help the performance but the architecture is so different that i think it would be wise to test the beta first rather than spending huge amounts of time optimising the legacy java stack imo. hope there is a public accessible beta soon so we can test it as i too would like to see it as a viable platform for scratch.

I would personally question whether Flash is a good choice for a new application nowadays rather than a HTML5/Javascript solution as it basically limits the possibilities of tablet usage but I think overall its a better solution that the java client.

[simplesi]

The 2.0 is something for the future - its been "coming" for years

Flash instead of java for the online version is just a tech decision they took - hopefully it shouldn't affect a locally runnable version

The present 1.4 is a Squeak image and that's where we need to look at the moment

And it doesn't matter if Scratch 2.0 comes along that will only run on a 8GHz Win9 machine - we still want/need a good version for the RaspberryPi.

If Clifford and his son (and people like Clifford and his son) give up on the RaspberryPi on 1st attempt then we need to try a bit harder to keep them on-board

Simon

[Clifford]

the next version of scratch 2.0, is apparently due sometime this year and it will be Flash based

Flash is not supported on RPi AFAIK.

rather than spending huge amounts of time optimising the legacy java stack imo.

I thought it was implemented in Squeak (a Smalltalk implementation with a virtual machine runtime)?

[edit]I believe that scratch programs executed on-line on the Scratch website use Java. The Scratch development environment itself is Smalltalk.

I would personally question whether Flash is a good choice for a new application nowadays rather than a HTML5/Javascript solution as it basically limits the possibilities of tablet usage but I think overall its a better solution that the java client.

Scratch looks like an exercise in "look what Smalltalk can do?". I would rather it were implement in C++, any VM based or interpreted language will always add a significant overhead that the RPi could well do without.

[Clifford]

If Clifford and his son (and people like Clifford and his son) give up on the RaspberryPi on 1st attempt then we need to try a bit harder to keep them on-board

I'm not giving up on anything. My concern was to have this assessed since Scratch seems to have been chosen and a major feature of the educational distribution. While you might think that its fine for educational use, some of your students may fly with it and exceed your expectations; if the tool does not allow them the potential to do that it will be a shame.

Scratch is certainly more fun to use on RPi than Python and the abysmal IDLE IDE and debugger. Perhaps I just miss my curly braces

[jamesh]

Don't worry - performance improvements on the Raspi are top of the list (se work on USB driver, Raspbian etc), and Scratch is important. We will try to get all this stuff working as fast as possible.

[simplesi]

Scratch looks like an exercise in "look what Smalltalk can do?". I would rather it were implement in C++, any VM based or interpreted language will always add a significant overhead that the RPi could well do without.

I believe it was a development of etoys (another squeak based thing) and when they coded it up (a bunch of v clever type people at MIT) I'm sure they didn't know it would take over as THE introduction to computing world and they probably didn't envisage a 700Mhz ARM computer popping along

It works fine on a PC/MAC/Decent Linux machine as they can cope fine with any VM overheads.

Of course since they invented it, they have made Java and Flash programs to run the source code and maybe the downloadable 2.0 might be done in a straight C type language

But back to reality - we just need to see if we can fix what we've got
Simon

[Clifford]

I am glad this discussion seems to have raised some interest in the community - it was a bit of a slow starter and I was not sure whether anyone was taking Scratch seriously. I enjoyed using it and think it covers a lot of important programming concepts in the kind to "instant gratification" way that is probably critical to getting some kids interested.

The thing I like most about Scratch is that despite its drag-and-drop Lego-like construction approach the result is sequential logic that looks and reads like a traditional text based language. This is in contrast to tools such as the LabView based Lego Mindstorms for example which work more like a hardware wiring diagram, and IMO are far less easy to follow for anything moderately complex. I have the same dim view BTW of full-blown LabView.

I shall watch its progress with interest. The RPi hardware is certainly powerful enough, but the implementation is presumably tailored to modern desktop performance and resources. My concern is that the lack of performance might intrinsic to the whole VM/Smalltalk software stack and evenly distributed throughout and therefore hard to optimise, rather than one or two specific bottlenecks in the Scratch code itself that could be more easily targeted.

[BlackJack]

@Clifford: In addition to what simplesi wrote about Smalltalk: On x86 based architectures the Cog-VM behind Scratch uses a JIT compiler, so it is not just faster because the CPUs are usually clocked at more than 700 Mhz.

The developers of the Cog-VM are aware of ARM targets and working on that front too. Smartphones and tablets are a market they would like to target.

To me it sounds more like a problem with Scratch and no graphic acceleration on the Raspi.