Bibi, a Scratch port to recent Squeak

>
> 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 19:24, tim Rowledge <[hidden email]> wrote:
>
>>
>> On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)" <[hidden email]> 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.

>> 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...

>
> On 23.02.2013, at 19:24, tim Rowledge <[hidden email]> wrote:
>
>>
>> On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)"  
>> <[hidden email]> 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 <[hidden email]> wrote:
>
>>
>> On 23.02.2013, at 19:24, tim Rowledge <[hidden email]> wrote:
>>
>>>
>>> On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)"  
>>> <[hidden email]> 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.

>
> On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)" <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: ARG: Agree to Run Garbage
>
>
>

>
> 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...

> Quoting tim Rowledge <[hidden email]>:
>
>>
>> On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)"  
>> <[hidden email]> 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; [hidden email]; 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)" <[hidden email]>:
>
>> Quoting tim Rowledge <[hidden email]>:
>>
>>>
>>> On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)"
>>> <[hidden email]> 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; [hidden email]; 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-1619.zip?raw=true
> 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)
> <[hidden email]> wrote:
>> Hi Tim, Bert,
>>
>> I just couldn't resist (more below).
>>
>>
>> Quoting "Juan Vuletich (mail lists)" <[hidden email]>:
>>
>>> Quoting tim Rowledge <[hidden email]>:
>>>
>>>>
>>>> On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)"
>>>> <[hidden email]> 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; [hidden email]; 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-1619.zip?raw=true
>> 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/abaa6b75aa3cfd4880824b4d9065e6d25f8f491a
> - just shows that you added a new binary. It would be very, very cool
> to see the actual code changes.
>
> frank

> Quoting Frank Shearar <[hidden email]>:
>
>> On 27 February 2013 11:14, Juan Vuletich (mail lists)
>> <[hidden email]> wrote:
>>>
>>> Hi Tim, Bert,
>>>
>>> I just couldn't resist (more below).
>>>
>>>
>>> Quoting "Juan Vuletich (mail lists)" <[hidden email]>:
>>>
>>>> Quoting tim Rowledge <[hidden email]>:
>>>>
>>>>>
>>>>> On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)"
>>>>> <[hidden email]> 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; [hidden email]; 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-1619.zip?raw=true
>>> 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/abaa6b75aa3cfd4880824b4d9065e6d25f8f491a
>> - 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-FixRecentMorphicSlowDown-JuanVuletich-2013Feb26-22h41m-jmv.1.cs.st
>
> Cheers,
> Juan Vuletich