Hello,
For those interested, I have made available a first draft of Bibi (a port of BYOB 3.1, based on Scratch) loading and working on Squeak 4.4 at this address:
http://www.zogotounga.net/comp/squeak/bibi.zip
It still has some rough edges and performance issues but is mostly usable; you should be able to load any Scratch or BYOB project and save them back, although in an upgraded and thus incompatible format.
Bugs are to be expected...
Stef
On 19-02-2013, at 12:10 PM, Stéphane Rollandin lecteur@zogotounga.net wrote:
Hello,
For those interested, I have made available a first draft of Bibi (a port of BYOB 3.1, based on Scratch) loading and working on Squeak 4.4 at this address:
An excellent start at an interesting project. I'm pretty certain there is a *lot* of performance to squeeze out of Scratch generally. One thing I've been doing to get a grip of what effects my attempts on the Pi have been causing is to remove the interCycleDelay. For some project I see the frameratemorph claiming 300fps (yes, even on the Pi) and for some 1fps.
One thing you'll want to fix soon is the File menu being able to escape from fill-the-screen mode so you can easily get to the world menu to open things like the frameratemorph. I just caused a debugger to get to somewhere I could type. Interestingly on my 3GHz iMac running on the cog vm I could only get 38fps for a benchmark that simply swaps between two 480*360 backgrounds, so there's clearly something spending a lot of time buried in there. Plain old Scratch seems to be able to do about 70fps on the older interpreter VM. On my Pi, plain Scratch does 14fps but bibi is only doing 2. Not complaining - just hopefully useful comparison for you.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Good grief
Thanks for the feedback ! I'll have a look at all this...
Another possible cause of slowdown would be Fractions appearing where not expected, since in Squeak 2.8 Integer>>#/ never returns a Fraction; I have to check this out.
Stef
On 20-02-2013, at 12:26 PM, Stéphane Rollandin lecteur@zogotounga.net wrote:
Thanks for the feedback ! I'll have a look at all this...
Another possible cause of slowdown would be Fractions appearing where not expected, since in Squeak 2.8 Integer>>#/ never returns a Fraction; I have to check this out.
Hmm, interesting idea. It could waste some time, certainly.
FIrst suspect has to be stuff added to the step code that hasn't been carefully thought about for speed. Too many people just assume a faster machine will come along Real Soon Now and solve the problem for them. Ain't gonna happen any more. Single core performance has hardly changed for several years, multi-core performance is blocked by memory performance and cost per transistor is flat.
I propose that everybody buys as Raspberry Pi to run their code on and at least tries to improve it for performance once in a while. For $35 it's a really cheap software development tool.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Thesaurus: Ancient reptile with a truly extensive vocabulary
Hi Tim,
What tinyBenchmarks performance do you get?
I use Cuis all the time on an Atom netbook (Cog, 29Msends/sec, 180Mbytecodes/sec). Cuis is nice to use here.
From time to time, I run it on my XO (300MHz Geode, Cog, 6.2Msends/sec, 39Mbytecodes/sec). Cuis is pefectly usable here. Sometimes I also run it on a PIII with a CPUKiller app, that brings performance down to XO levels.
Using slower machines is really useful. It really helped me find code that really deserved some optimization. The result is that, even if it looks cool, Cuis is usable on slow hardware?
Have you tried Cuis on the Pi? Could you please do it and comment on the experience?
BTW, if needed, you can evaluate 'Preferences slowMachine' to trade looks for responsiveness.
Cheers, Juan Vuletich
Quoting tim Rowledge tim@rowledge.org:
...
FIrst suspect has to be stuff added to the step code that hasn't been carefully thought about for speed. Too many people just assume a faster machine will come along Real Soon Now and solve the problem for them. Ain't gonna happen any more. Single core performance has hardly changed for several years, multi-core performance is blocked by memory performance and cost per transistor is flat.
I propose that everybody buys as Raspberry Pi to run their code on and at least tries to improve it for performance once in a while. For $35 it's a really cheap software development tool.
tim
On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)" juanlists@jvuletich.org wrote:
What tinyBenchmarks performance do you get?
My Pi does about 42Mbc/s and 1.4Msn/s
I use Cuis all the time on an Atom netbook (Cog, 29Msends/sec, 180Mbytecodes/sec). Cuis is nice to use here.
From time to time, I run it on my XO (300MHz Geode, Cog, 6.2Msends/sec, 39Mbytecodes/sec). Cuis is pefectly usable here. Sometimes I also run it on a PIII with a CPUKiller app, that brings performance down to XO levels.
Using slower machines is really useful. It really helped me find code that really deserved some optimization. The result is that, even if it looks cool, Cuis is usable on slow hardware?
Try to get a Pi sometime. You'll adore the sheer cuteness of having a machine that small and raw to play with. Download RISC OS and enjoy a *really fun* operating system as well.
Have you tried Cuis on the Pi? Could you please do it and comment on the experience?
It is certainly a good approach; even on the Pi it is bearable. I'm doing some work on how to boost the bitBLT performance right now (which is not so hot) and that would make a big difference. Eventually I hope to get the Cog vm working on it as well. But the real key is always better written systems code. Morphic has always seemed to have horrible scaling issues - with one window open it can be ok, open a dozen and it gri nds to a h h aa l t. A long time ago Andreas made a benchmark that timed opening a couple of dozen browsers and it was possible even on a fast machine (of the day, so say 25% of the fast machines now) to see how the last few took so much longer. If anyone can fix that problem life would be a lot better. By contrast, open an MVC project and use a couple of dozen browsers. No performance problem there...
BTW, if needed, you can evaluate 'Preferences slowMachine' to trade looks for responsiveness.
That does help a little. It does still take a good 1sec+ top open the workspace text editing menu and at least 5 sec to open a browser.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ARG: Agree to Run Garbage
On 23.02.2013, at 19:24, tim Rowledge tim@rowledge.org wrote:
On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)" juanlists@jvuletich.org wrote:
What tinyBenchmarks performance do you get?
My Pi does about 42Mbc/s and 1.4Msn/s
Under Linux, using the pre-installed Squeak VM and the Cuis image, I get 35 Mbytecodes/s and 1.0 Msends/s.
Guess the Linux VM could use some of your ARM-Fu?
I use Cuis all the time on an Atom netbook (Cog, 29Msends/sec, 180Mbytecodes/sec). Cuis is nice to use here.
From time to time, I run it on my XO (300MHz Geode, Cog, 6.2Msends/sec, 39Mbytecodes/sec). Cuis is pefectly usable here. Sometimes I also run it on a PIII with a CPUKiller app, that brings performance down to XO levels.
Using slower machines is really useful. It really helped me find code that really deserved some optimization. The result is that, even if it looks cool, Cuis is usable on slow hardware?
Try to get a Pi sometime. You'll adore the sheer cuteness of having a machine that small and raw to play with. Download RISC OS and enjoy a *really fun* operating system as well.
I'll stick to Linux for the time being :)
Have you tried Cuis on the Pi? Could you please do it and comment on the experience?
It is certainly a good approach; even on the Pi it is bearable. I'm doing some work on how to boost the bitBLT performance right now (which is not so hot) and that would make a big difference. Eventually I hope to get the Cog vm working on it as well. But the real key is always better written systems code. Morphic has always seemed to have horrible scaling issues - with one window open it can be ok, open a dozen and it gri nds to a h h aa l t. A long time ago Andreas made a benchmark that timed opening a couple of dozen browsers and it was possible even on a fast machine (of the day, so say 25% of the fast machines now) to see how the last few took so much longer. If anyone can fix that problem life would be a lot better. By contrast, open an MVC project and use a couple of dozen browsers. No performance problem there...
Well, under MVC, all windows except the active one are dead. In Morphic they're live.
Which is not to say this couldn't be improved: in the Scratch image, opening a browser is almost instantaneous (Scratch: 0.x secs, Etoys: 3 secs, Squeak: 3 secs, Cuis: 6 secs).
BTW, if needed, you can evaluate 'Preferences slowMachine' to trade looks for responsiveness.
That does help a little. It does still take a good 1sec+ top open the workspace text editing menu and at least 5 sec to open a browser.
Makes no difference AFAICT.
- Bert -
On 23-02-2013, at 11:01 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 23.02.2013, at 19:24, tim Rowledge tim@rowledge.org wrote:
On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)" juanlists@jvuletich.org wrote:
What tinyBenchmarks performance do you get?
My Pi does about 42Mbc/s and 1.4Msn/s
Under Linux, using the pre-installed Squeak VM and the Cuis image, I get 35 Mbytecodes/s and 1.0 Msends/s.
Guess the Linux VM could use some of your ARM-Fu?
Ouch. That's quite a difference.
Try to get a Pi sometime. You'll adore the sheer cuteness of having a machine that small and raw to play with. Download RISC OS and enjoy a *really fun* operating system as well.
I'll stick to Linux for the time being :)
Ya big wuss. ;-) Virtual memory etc has made you soft.
Well, under MVC, all windows except the active one are dead. In Morphic they're live.
And maybe part of the problem is that not everything *needs* to be alive all the time. Perhaps simply making appropriate morphs 'go zombie' for a while would improve performance?
Which is not to say this couldn't be improved: in the Scratch image, opening a browser is almost instantaneous (Scratch: 0.x secs, Etoys: 3 secs, Squeak: 3 secs, Cuis: 6 secs).
True; on the Pi opening a browser in the Scratch image is near instant. Of course, they're absolutely hideously coloured. In fact, long-dead-zombie colour wouldn't be too inaccurate. Anyone interested in improving browser performance in Morphic should play with the Scratch 'source code release' image and try to bring the latest versions up to that same speed.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Almost exactly
Quoting tim Rowledge tim@rowledge.org:
On 23-02-2013, at 11:01 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 23.02.2013, at 19:24, tim Rowledge tim@rowledge.org wrote:
On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)" juanlists@jvuletich.org wrote:
What tinyBenchmarks performance do you get?
My Pi does about 42Mbc/s and 1.4Msn/s
Under Linux, using the pre-installed Squeak VM and the Cuis image, I get 35 Mbytecodes/s and 1.0 Msends/s.
Guess the Linux VM could use some of your ARM-Fu?
Ouch. That's quite a difference.
Try to get a Pi sometime. You'll adore the sheer cuteness of having a machine that small and raw to play with. Download RISC OS and enjoy a *really fun* operating system as well.
I'll stick to Linux for the time being :)
Ya big wuss. ;-) Virtual memory etc has made you soft.
Well, under MVC, all windows except the active one are dead. In Morphic they're live.
And maybe part of the problem is that not everything *needs* to be alive all the time. Perhaps simply making appropriate morphs 'go zombie' for a while would improve performance?
Which is not to say this couldn't be improved: in the Scratch image, opening a browser is almost instantaneous (Scratch: 0.x secs, Etoys: 3 secs, Squeak: 3 secs, Cuis: 6 secs).
True; on the Pi opening a browser in the Scratch image is near instant. Of course, they're absolutely hideously coloured. In fact, long-dead-zombie colour wouldn't be too inaccurate. Anyone interested in improving browser performance in Morphic should play with the Scratch 'source code release' image and try to bring the latest versions up to that same speed.
Or (as I said in other messages), check Cuis 4.0. It opens the browser 14 times faster than Cuis 4.1. At least, the looks are quite nicer.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Almost exactly
Cheers, Juan Vuletich
Quoting Bert Freudenberg bert@freudenbergs.de:
On 23.02.2013, at 19:24, tim Rowledge tim@rowledge.org wrote:
On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)" juanlists@jvuletich.org wrote:
What tinyBenchmarks performance do you get?
My Pi does about 42Mbc/s and 1.4Msn/s
Under Linux, using the pre-installed Squeak VM and the Cuis image, I get 35 Mbytecodes/s and 1.0 Msends/s.
Guess the Linux VM could use some of your ARM-Fu?
I use Cuis all the time on an Atom netbook (Cog, 29Msends/sec, 180Mbytecodes/sec). Cuis is nice to use here.
From time to time, I run it on my XO (300MHz Geode, Cog, 6.2Msends/sec, 39Mbytecodes/sec). Cuis is pefectly usable here. Sometimes I also run it on a PIII with a CPUKiller app, that brings performance down to XO levels.
Using slower machines is really useful. It really helped me find code that really deserved some optimization. The result is that, even if it looks cool, Cuis is usable on slow hardware?
Try to get a Pi sometime. You'll adore the sheer cuteness of having a machine that small and raw to play with. Download RISC OS and enjoy a *really fun* operating system as well.
I'll stick to Linux for the time being :)
Have you tried Cuis on the Pi? Could you please do it and comment on the experience?
It is certainly a good approach; even on the Pi it is bearable. I'm doing some work on how to boost the bitBLT performance right now (which is not so hot) and that would make a big difference. Eventually I hope to get the Cog vm working on it as well. But the real key is always better written systems code. Morphic has always seemed to have horrible scaling issues - with one window open it can be ok, open a dozen and it gri nds to a h h aa l t. A long time ago Andreas made a benchmark that timed opening a couple of dozen browsers and it was possible even on a fast machine (of the day, so say 25% of the fast machines now) to see how the last few took so much longer. If anyone can fix that problem life would be a lot better. By contrast, open an MVC project and use a couple of dozen browsers. No performance problem there...
Well, under MVC, all windows except the active one are dead. In Morphic they're live.
Which is not to say this couldn't be improved: in the Scratch image, opening a browser is almost instantaneous (Scratch: 0.x secs, Etoys: 3 secs, Squeak: 3 secs, Cuis: 6 secs).
Yes. In tests I just did on my slow setup (32mbytecodes/s, 1.3msends/sec), Cuis 4.1 is 14 times slower than Cuis 4.0. This is due to Float local coordinates in Morphic.
BTW, if needed, you can evaluate 'Preferences slowMachine' to trade looks for responsiveness.
That does help a little. It does still take a good 1sec+ top open the workspace text editing menu and at least 5 sec to open a browser.
Makes no difference AFAICT.
- Bert -
Checked it. There might be a slight difference, but not much. true.
Thanks for testing. Bottom line: Avoid Cuis 4.1 on slow hardware. Prefer Cuis 4.0.
Cheers, Juan Vuletich
Quoting tim Rowledge tim@rowledge.org:
On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)" juanlists@jvuletich.org wrote:
What tinyBenchmarks performance do you get?
My Pi does about 42Mbc/s and 1.4Msn/s
Thanks.
I use Cuis all the time on an Atom netbook (Cog, 29Msends/sec, 180Mbytecodes/sec). Cuis is nice to use here.
From time to time, I run it on my XO (300MHz Geode, Cog, 6.2Msends/sec, 39Mbytecodes/sec). Cuis is pefectly usable here. Sometimes I also run it on a PIII with a CPUKiller app, that brings performance down to XO levels.
Using slower machines is really useful. It really helped me find code that really deserved some optimization. The result is that, even if it looks cool, Cuis is usable on slow hardware?
Try to get a Pi sometime. You'll adore the sheer cuteness of having a machine that small and raw to play with. Download RISC OS and enjoy a *really fun* operating system as well.
Yes, I'd get one some day.
Have you tried Cuis on the Pi? Could you please do it and comment on the experience?
It is certainly a good approach; even on the Pi it is bearable. I'm doing some work on how to boost the bitBLT performance right now (which is not so hot) and that would make a big difference. Eventually I hope to get the Cog vm working on it as well. But the real key is always better written systems code. Morphic has always seemed to have horrible scaling issues - with one window open it can be ok, open a dozen and it gri nds to a h h aa l t. A long time ago Andreas made a benchmark that timed opening a couple of dozen browsers and it was possible even on a fast machine (of the day, so say 25% of the fast machines now) to see how the last few took so much longer. If anyone can fix that problem life would be a lot better. By contrast, open an MVC project and use a couple of dozen browsers. No performance problem there...
WRT this, I redid the rectangle merge & invalidate logic in Morphic. With this, resizing windows with more than 10 windows open became about ten times faster in my tests.
BTW, if needed, you can evaluate 'Preferences slowMachine' to trade looks for responsiveness.
That does help a little. It does still take a good 1sec+ top open the workspace text editing menu and at least 5 sec to open a browser.
Mhhh. This is to much. Just went to the P-III with Cpukiller 3 killing 70% cpu. This way, I get 32Mbytecodes/sec and 1.3Msends/sec, comparable with the raspi. This way, using a stack interpreter (not Cog), doing [ BrowserWindow openBrowser ] timeToRun takes 3.8 secs on Cuis 4.1 and 0.2 secs on Cuis 4.0.
This is because in Cuis 4.1 I converted Morphic to use Float coordinates that are local to the Morph, and using MatrixTransform2x3.
All I can say is, please use Cuis 4.0 and not 4.1 on slow hardware...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ARG: Agree to Run Garbage
Cheers, Juan Vuletich
Hi Tim, Bert,
I just couldn't resist (more below).
Quoting "Juan Vuletich (mail lists)" juanlists@jvuletich.org:
Quoting tim Rowledge tim@rowledge.org:
On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)" juanlists@jvuletich.org wrote:
What tinyBenchmarks performance do you get?
My Pi does about 42Mbc/s and 1.4Msn/s
Thanks.
I use Cuis all the time on an Atom netbook (Cog, 29Msends/sec, 180Mbytecodes/sec). Cuis is nice to use here.
From time to time, I run it on my XO (300MHz Geode, Cog, 6.2Msends/sec, 39Mbytecodes/sec). Cuis is pefectly usable here. Sometimes I also run it on a PIII with a CPUKiller app, that brings performance down to XO levels.
Using slower machines is really useful. It really helped me find code that really deserved some optimization. The result is that, even if it looks cool, Cuis is usable on slow hardware?
Try to get a Pi sometime. You'll adore the sheer cuteness of having a machine that small and raw to play with. Download RISC OS and enjoy a *really fun* operating system as well.
Yes, I'd get one some day.
Have you tried Cuis on the Pi? Could you please do it and comment on the experience?
It is certainly a good approach; even on the Pi it is bearable. I'm doing some work on how to boost the bitBLT performance right now (which is not so hot) and that would make a big difference. Eventually I hope to get the Cog vm working on it as well. But the real key is always better written systems code. Morphic has always seemed to have horrible scaling issues - with one window open it can be ok, open a dozen and it gri nds to a h h aa l t. A long time ago Andreas made a benchmark that timed opening a couple of dozen browsers and it was possible even on a fast machine (of the day, so say 25% of the fast machines now) to see how the last few took so much longer. If anyone can fix that problem life would be a lot better. By contrast, open an MVC project and use a couple of dozen browsers. No performance problem there...
WRT this, I redid the rectangle merge & invalidate logic in Morphic. With this, resizing windows with more than 10 windows open became about ten times faster in my tests.
BTW, if needed, you can evaluate 'Preferences slowMachine' to trade looks for responsiveness.
That does help a little. It does still take a good 1sec+ top open the workspace text editing menu and at least 5 sec to open a browser.
Mhhh. This is to much. Just went to the P-III with Cpukiller 3 killing 70% cpu. This way, I get 32Mbytecodes/sec and 1.3Msends/sec, comparable with the raspi. This way, using a stack interpreter (not Cog), doing [ BrowserWindow openBrowser ] timeToRun takes 3.8 secs on Cuis 4.1 and 0.2 secs on Cuis 4.0.
This is because in Cuis 4.1 I converted Morphic to use Float coordinates that are local to the Morph, and using MatrixTransform2x3.
All I can say is, please use Cuis 4.0 and not 4.1 on slow hardware...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ARG: Agree to Run Garbage
Cheers, Juan Vuletich
I couldn't help it. Spent some time on the 300MHz equivalent P-III and found it. The culprit wasn't Float coordinates, but a couple of bugs I introduced with those changes. Please grab https://github.com/jvuletich/Cuis/blob/master/Cuis4WithLatestUpdates/Cuis4.1... or the updates from same Git repo.
Cuis 4.1 now opens windows as quickly as Cuis 4.0, i.e. as quickly as Scratch, and at least 5 times faster than Etoys or Squeak.
Thanks for the feedback!
Cheers, Juan Vuletich
On 27 February 2013 11:14, Juan Vuletich (mail lists) juanlists@jvuletich.org wrote:
Hi Tim, Bert,
I just couldn't resist (more below).
Quoting "Juan Vuletich (mail lists)" juanlists@jvuletich.org:
Quoting tim Rowledge tim@rowledge.org:
On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)" juanlists@jvuletich.org wrote:
What tinyBenchmarks performance do you get?
My Pi does about 42Mbc/s and 1.4Msn/s
Thanks.
I use Cuis all the time on an Atom netbook (Cog, 29Msends/sec, 180Mbytecodes/sec). Cuis is nice to use here.
From time to time, I run it on my XO (300MHz Geode, Cog, 6.2Msends/sec, 39Mbytecodes/sec). Cuis is pefectly usable here. Sometimes I also run it on a PIII with a CPUKiller app, that brings performance down to XO levels.
Using slower machines is really useful. It really helped me find code that really deserved some optimization. The result is that, even if it looks cool, Cuis is usable on slow hardware?
Try to get a Pi sometime. You'll adore the sheer cuteness of having a machine that small and raw to play with. Download RISC OS and enjoy a *really fun* operating system as well.
Yes, I'd get one some day.
Have you tried Cuis on the Pi? Could you please do it and comment on the experience?
It is certainly a good approach; even on the Pi it is bearable. I'm doing some work on how to boost the bitBLT performance right now (which is not so hot) and that would make a big difference. Eventually I hope to get the Cog vm working on it as well. But the real key is always better written systems code. Morphic has always seemed to have horrible scaling issues - with one window open it can be ok, open a dozen and it gri nds to a h h aa l t. A long time ago Andreas made a benchmark that timed opening a couple of dozen browsers and it was possible even on a fast machine (of the day, so say 25% of the fast machines now) to see how the last few took so much longer. If anyone can fix that problem life would be a lot better. By contrast, open an MVC project and use a couple of dozen browsers. No performance problem there...
WRT this, I redid the rectangle merge & invalidate logic in Morphic. With this, resizing windows with more than 10 windows open became about ten times faster in my tests.
BTW, if needed, you can evaluate 'Preferences slowMachine' to trade looks for responsiveness.
That does help a little. It does still take a good 1sec+ top open the workspace text editing menu and at least 5 sec to open a browser.
Mhhh. This is to much. Just went to the P-III with Cpukiller 3 killing 70% cpu. This way, I get 32Mbytecodes/sec and 1.3Msends/sec, comparable with the raspi. This way, using a stack interpreter (not Cog), doing [ BrowserWindow openBrowser ] timeToRun takes 3.8 secs on Cuis 4.1 and 0.2 secs on Cuis 4.0.
This is because in Cuis 4.1 I converted Morphic to use Float coordinates that are local to the Morph, and using MatrixTransform2x3.
All I can say is, please use Cuis 4.0 and not 4.1 on slow hardware...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ARG: Agree to Run Garbage
Cheers, Juan Vuletich
I couldn't help it. Spent some time on the 300MHz equivalent P-III and found it. The culprit wasn't Float coordinates, but a couple of bugs I introduced with those changes. Please grab https://github.com/jvuletich/Cuis/blob/master/Cuis4WithLatestUpdates/Cuis4.1... or the updates from same Git repo.
Cuis 4.1 now opens windows as quickly as Cuis 4.0, i.e. as quickly as Scratch, and at least 5 times faster than Etoys or Squeak.
Thanks for the feedback!
Cheers, Juan Vuletich
Will you at some point store Cuis's source in github directly? For instance, the relevant commit for 1619 - https://github.com/jvuletich/Cuis/commit/abaa6b75aa3cfd4880824b4d9065e6d25f8... - just shows that you added a new binary. It would be very, very cool to see the actual code changes.
frank
Quoting Frank Shearar frank.shearar@gmail.com:
On 27 February 2013 11:14, Juan Vuletich (mail lists) juanlists@jvuletich.org wrote:
Hi Tim, Bert,
I just couldn't resist (more below).
Quoting "Juan Vuletich (mail lists)" juanlists@jvuletich.org:
Quoting tim Rowledge tim@rowledge.org:
On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)" juanlists@jvuletich.org wrote:
What tinyBenchmarks performance do you get?
My Pi does about 42Mbc/s and 1.4Msn/s
Thanks.
I use Cuis all the time on an Atom netbook (Cog, 29Msends/sec, 180Mbytecodes/sec). Cuis is nice to use here.
From time to time, I run it on my XO (300MHz Geode, Cog, 6.2Msends/sec, 39Mbytecodes/sec). Cuis is pefectly usable here. Sometimes I also run it on a PIII with a CPUKiller app, that brings performance down to XO levels.
Using slower machines is really useful. It really helped me find code that really deserved some optimization. The result is that, even if it looks cool, Cuis is usable on slow hardware?
Try to get a Pi sometime. You'll adore the sheer cuteness of having a machine that small and raw to play with. Download RISC OS and enjoy a *really fun* operating system as well.
Yes, I'd get one some day.
Have you tried Cuis on the Pi? Could you please do it and comment on the experience?
It is certainly a good approach; even on the Pi it is bearable. I'm doing some work on how to boost the bitBLT performance right now (which is not so hot) and that would make a big difference. Eventually I hope to get the Cog vm working on it as well. But the real key is always better written systems code. Morphic has always seemed to have horrible scaling issues - with one window open it can be ok, open a dozen and it gri nds to a h h aa l t. A long time ago Andreas made a benchmark that timed opening a couple of dozen browsers and it was possible even on a fast machine (of the day, so say 25% of the fast machines now) to see how the last few took so much longer. If anyone can fix that problem life would be a lot better. By contrast, open an MVC project and use a couple of dozen browsers. No performance problem there...
WRT this, I redid the rectangle merge & invalidate logic in Morphic. With this, resizing windows with more than 10 windows open became about ten times faster in my tests.
BTW, if needed, you can evaluate 'Preferences slowMachine' to trade looks for responsiveness.
That does help a little. It does still take a good 1sec+ top open the workspace text editing menu and at least 5 sec to open a browser.
Mhhh. This is to much. Just went to the P-III with Cpukiller 3 killing 70% cpu. This way, I get 32Mbytecodes/sec and 1.3Msends/sec, comparable with the raspi. This way, using a stack interpreter (not Cog), doing [ BrowserWindow openBrowser ] timeToRun takes 3.8 secs on Cuis 4.1 and 0.2 secs on Cuis 4.0.
This is because in Cuis 4.1 I converted Morphic to use Float coordinates that are local to the Morph, and using MatrixTransform2x3.
All I can say is, please use Cuis 4.0 and not 4.1 on slow hardware...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ARG: Agree to Run Garbage
Cheers, Juan Vuletich
I couldn't help it. Spent some time on the 300MHz equivalent P-III and found it. The culprit wasn't Float coordinates, but a couple of bugs I introduced with those changes. Please grab https://github.com/jvuletich/Cuis/blob/master/Cuis4WithLatestUpdates/Cuis4.1... or the updates from same Git repo.
Cuis 4.1 now opens windows as quickly as Cuis 4.0, i.e. as quickly as Scratch, and at least 5 times faster than Etoys or Squeak.
Thanks for the feedback!
Cheers, Juan Vuletich
Will you at some point store Cuis's source in github directly? For instance, the relevant commit for 1619 - https://github.com/jvuletich/Cuis/commit/abaa6b75aa3cfd4880824b4d9065e6d25f8...
- just shows that you added a new binary. It would be very, very cool
to see the actual code changes.
frank
The changes are at https://github.com/jvuletich/Cuis/blob/master/UpdatesSinceLastRelease/1618-F...
Cheers, Juan Vuletich
On 27 February 2013 11:35, Juan Vuletich (mail lists) juanlists@jvuletich.org wrote:
Quoting Frank Shearar frank.shearar@gmail.com:
On 27 February 2013 11:14, Juan Vuletich (mail lists) juanlists@jvuletich.org wrote:
Hi Tim, Bert,
I just couldn't resist (more below).
Quoting "Juan Vuletich (mail lists)" juanlists@jvuletich.org:
Quoting tim Rowledge tim@rowledge.org:
On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)" juanlists@jvuletich.org wrote:
What tinyBenchmarks performance do you get?
My Pi does about 42Mbc/s and 1.4Msn/s
Thanks.
I use Cuis all the time on an Atom netbook (Cog, 29Msends/sec, 180Mbytecodes/sec). Cuis is nice to use here.
From time to time, I run it on my XO (300MHz Geode, Cog, 6.2Msends/sec, 39Mbytecodes/sec). Cuis is pefectly usable here. Sometimes I also run it on a PIII with a CPUKiller app, that brings performance down to XO levels.
Using slower machines is really useful. It really helped me find code that really deserved some optimization. The result is that, even if it looks cool, Cuis is usable on slow hardware?
Try to get a Pi sometime. You'll adore the sheer cuteness of having a machine that small and raw to play with. Download RISC OS and enjoy a *really fun* operating system as well.
Yes, I'd get one some day.
Have you tried Cuis on the Pi? Could you please do it and comment on the experience?
It is certainly a good approach; even on the Pi it is bearable. I'm doing some work on how to boost the bitBLT performance right now (which is not so hot) and that would make a big difference. Eventually I hope to get the Cog vm working on it as well. But the real key is always better written systems code. Morphic has always seemed to have horrible scaling issues - with one window open it can be ok, open a dozen and it gri nds to a h h aa l t. A long time ago Andreas made a benchmark that timed opening a couple of dozen browsers and it was possible even on a fast machine (of the day, so say 25% of the fast machines now) to see how the last few took so much longer. If anyone can fix that problem life would be a lot better. By contrast, open an MVC project and use a couple of dozen browsers. No performance problem there...
WRT this, I redid the rectangle merge & invalidate logic in Morphic. With this, resizing windows with more than 10 windows open became about ten times faster in my tests.
BTW, if needed, you can evaluate 'Preferences slowMachine' to trade looks for responsiveness.
That does help a little. It does still take a good 1sec+ top open the workspace text editing menu and at least 5 sec to open a browser.
Mhhh. This is to much. Just went to the P-III with Cpukiller 3 killing 70% cpu. This way, I get 32Mbytecodes/sec and 1.3Msends/sec, comparable with the raspi. This way, using a stack interpreter (not Cog), doing [ BrowserWindow openBrowser ] timeToRun takes 3.8 secs on Cuis 4.1 and 0.2 secs on Cuis 4.0.
This is because in Cuis 4.1 I converted Morphic to use Float coordinates that are local to the Morph, and using MatrixTransform2x3.
All I can say is, please use Cuis 4.0 and not 4.1 on slow hardware...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ARG: Agree to Run Garbage
Cheers, Juan Vuletich
I couldn't help it. Spent some time on the 300MHz equivalent P-III and found it. The culprit wasn't Float coordinates, but a couple of bugs I introduced with those changes. Please grab
https://github.com/jvuletich/Cuis/blob/master/Cuis4WithLatestUpdates/Cuis4.1... or the updates from same Git repo.
Cuis 4.1 now opens windows as quickly as Cuis 4.0, i.e. as quickly as Scratch, and at least 5 times faster than Etoys or Squeak.
Thanks for the feedback!
Cheers, Juan Vuletich
Will you at some point store Cuis's source in github directly? For instance, the relevant commit for 1619 -
https://github.com/jvuletich/Cuis/commit/abaa6b75aa3cfd4880824b4d9065e6d25f8...
- just shows that you added a new binary. It would be very, very cool
to see the actual code changes.
frank
The changes are at https://github.com/jvuletich/Cuis/blob/master/UpdatesSinceLastRelease/1618-F...
Cheers, Juan Vuletich
Ah, I see. Thanks; I hadn't thought to look elsewhere in the repository.
Also, that confirms my suspicion that the way Squeak/Cuis updates work is analogous to a database migration: take some big chunk of state, and mutate it in these specific ways.
The problem being that to see what actually changed requires something in the state induced by #1618, applying the 1619 changeset, and comparing the #1618 state with the #1619 state.
I don't mean this as a criticism - I'm jut formalising my understanding of how we actually work.
frank
Quoting Frank Shearar frank.shearar@gmail.com:
?snip? The changes are at https://github.com/jvuletich/Cuis/blob/master/UpdatesSinceLastRelease/1618-F...
Cheers, Juan Vuletich
Ah, I see. Thanks; I hadn't thought to look elsewhere in the repository.
Also, that confirms my suspicion that the way Squeak/Cuis updates work is analogous to a database migration: take some big chunk of state, and mutate it in these specific ways.
Well, that´s the way the Cuis image is updated. It is the same as the "update stream" Squeak used to have.
The problem being that to see what actually changed requires something in the state induced by #1618, applying the 1619 changeset, and comparing the #1618 state with the #1619 state.
Yes. Not a problem in my view. To me, the best way to understand the behavior at levels #1618 and #1619 is to run the system updated to those levels, and use the Smalltalk tools to study it. I.e. I´m a classical smalltalker.
BTW, for external packages, we store the full code in a format GitHub can understand, version, diff, merge, etc. See, for example, https://github.com/bpieber/Cuis-StyledTextEditor/commit/e01cf430657739bfcca1... ..
I don't mean this as a criticism - I'm jut formalising my understanding of how we actually work.
frank
Criticism is welcome too. I´d really like to have something better for the base image, while keeping the nice properties of ChangeSets and the update stream. Maybe using DeltaStreams instead of ChangeSets would be an option. We´d need to see how to make GitHub ´understand´ them.
Another option would be to commit, in addition, a condensed Sources file each time, to let GitHub diff that?
Cheers, Juan Vuletich
On 27-02-2013, at 3:35 AM, Juan Vuletich (mail lists) juanlists@jvuletich.org wrote:
Cuis 4.1 now opens windows as quickly as Cuis 4.0, i.e. as quickly as Scratch, and at least 5 times faster than Etoys or Squeak.
It's certainly better on the Pi but browser opening is still not as fast as the Scratch image. On the Pi it is as near instant as makes no practical difference.
Not that 450mSec is disastrous by any stretch of the imagination. What does impress me right now is that it doesn't slow down as I open a dozen or so browsers. In fact [12 timesRepeat:[BrowserWindow openBrowser]] timeToRun reports 5200mSec or an average of 430mS.
Same VM, same machine, Squeak4.4-12327 [Browser openBrowser] takes 1900 mS [12 timesRepeat:[Browser openBrowser]] timeToRun reports 23200
So Cuis is ~4.5 times faster at this test. Good work!
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Eagles may soar, but weasels aren't sucked into jet engines.
Hmm, interesting - I thought the Cuis world menu opening seemed a bit slow on the Pi but it's also quite slow enough to be annoying on my iMac 3GHz/Cog combo. That implies something must need improving I'd say :-)
And I look into TheWorldMenu>buildWorldMenu and I weep for wasted cpu cycles that are thrown away carelessly like confetti into a firestorm.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim boutique - a startling hardwood
Hi Tim,
I'm especially interested in the performance profile that Cuis displays on the Pi; it has always outperformed the other dialects on the more modest hardware, and that's part of why I adore it so. Juan's changes to Morphic have removed a great deal of computational overhead, it becomes clear very quickly when running atop a lower end machine.
I'm excited about the Pi. Truth is, I actually don't have the $35, but as soon as I do, I'll be doing what I can. Might have to wait until my birthday in May. Things are tough all over and it's been a bit since I've worked. Either way though, right now the Pi is probably the closest thing we've got to an interim DynaBook, so we should pay close attention to it.
:/
Thanks for getting us up and running, Tim!
C
On Feb 23, 2013, at 10:24 AM, tim Rowledge tim@rowledge.org wrote:
On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)" juanlists@jvuletich.org wrote:
What tinyBenchmarks performance do you get?
My Pi does about 42Mbc/s and 1.4Msn/s
I use Cuis all the time on an Atom netbook (Cog, 29Msends/sec, 180Mbytecodes/sec). Cuis is nice to use here.
From time to time, I run it on my XO (300MHz Geode, Cog, 6.2Msends/sec, 39Mbytecodes/sec). Cuis is pefectly usable here. Sometimes I also run it on a PIII with a CPUKiller app, that brings performance down to XO levels.
Using slower machines is really useful. It really helped me find code that really deserved some optimization. The result is that, even if it looks cool, Cuis is usable on slow hardware?
Try to get a Pi sometime. You'll adore the sheer cuteness of having a machine that small and raw to play with. Download RISC OS and enjoy a *really fun* operating system as well.
Have you tried Cuis on the Pi? Could you please do it and comment on the experience?
It is certainly a good approach; even on the Pi it is bearable. I'm doing some work on how to boost the bitBLT performance right now (which is not so hot) and that would make a big difference. Eventually I hope to get the Cog vm working on it as well. But the real key is always better written systems code. Morphic has always seemed to have horrible scaling issues - with one window open it can be ok, open a dozen and it gri nds to a h h aa l t. A long time ago Andreas made a benchmark that timed opening a couple of dozen browsers and it was possible even on a fast machine (of the day, so say 25% of the fast machines now) to see how the last few took so much longer. If anyone can fix that problem life would be a lot better. By contrast, open an MVC project and use a couple of dozen browsers. No performance problem there...
BTW, if needed, you can evaluate 'Preferences slowMachine' to trade looks for responsiveness.
That does help a little. It does still take a good 1sec+ top open the workspace text editing menu and at least 5 sec to open a browser.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ARG: Agree to Run Garbage
Never? My 2.8 image has
/ aNumber "Refer to the comment in Number / " | quoRem | aNumber isInteger ifTrue: [quoRem _ self digitDiv: aNumber abs "*****I've added abs here*****" neg: self negative ~~ aNumber negative. (quoRem at: 2) = 0 ifTrue: [^ (quoRem at: 1) normalize] ifFalse: [^ (Fraction numerator: self denominator: aNumber) reduced]]. ^ aNumber adaptToInteger: self andSend: #/
which will return a fraction if needed.
Cheers, Bob
On 2/20/13 3:26 PM, Stéphane Rollandin wrote:
since in Squeak 2.8 Integer>>#/ never returns a Fraction;
Ah, ok, then it has just been changed in the Scratch image (more exactly the BYOB 1.3 image I'm working from, I don't know about Scratch per se), were the implementation is:
/ aNumber "Refer to the comment in Number / "
| quoRem | aNumber isInteger ifTrue: [quoRem _ self digitDiv: aNumber abs "*****I've added abs here*****" neg: self negative ~~ aNumber negative. (quoRem at: 2) = 0 ifTrue: [^ (quoRem at: 1) normalize] ifFalse: [^ self asFloat / aNumber]]. ^ aNumber adaptToInteger: self andSend: #/
Stef
Stéphane Rollandin <lecteur <at> zogotounga.net> writes:
Hello,
For those interested, I have made available a first draft of Bibi (a port of BYOB 3.1, based on Scratch) loading and working on Squeak 4.4 at this address:
http://www.zogotounga.net/comp/squeak/bibi.zip
It still has some rough edges and performance issues but is mostly usable; you should be able to load any Scratch or BYOB project and save them back, although in an upgraded and thus incompatible format.
Bugs are to be expected...
Nice work Stef !
There is also a port of Scratch to Pharo that has been done recently: https://code.google.com/p/scat/
Maybe we can join our effort ?
Regards,
There is also a port of Scratch to Pharo that has been done recently: https://code.google.com/p/scat/
Yes, I have been made aware of it and I actually borrowed a couple of methods from Scat. But the original code is not the same: Scat is a port of Scratch while Bibi is a port of BYOB.
I guess the best way to go would be to have a Pharo expert resume Scat development; I could help from Squeak side via Bibi. And eventually we would have both Scratch and BYOB working on modern systems.
Stef
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Bob Arning -
Casey Ransberger -
Frank Shearar -
Juan Vuletich (mail lists) -
Serge Stinckwich -
Stéphane Rollandin -
tim Rowledge