On 27 February 2013 11:14, Juan Vuletich (mail lists)
<juanlists at jvuletich.org> wrote:
> Hi Tim, Bert,
>
> I just couldn't resist (more below).
>
>
> Quoting "Juan Vuletich (mail lists)" <juanlists at jvuletich.org>:
>
>> Quoting tim Rowledge <tim at rowledge.org>:
>>
>>>
>>> On 23-02-2013, at 5:58 AM, "Juan Vuletich (mail lists)"
>>> <juanlists at 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 at 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-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