On 27 February 2013 11:35, Juan Vuletich (mail lists)
<juanlists at jvuletich.org> wrote:
> Quoting Frank Shearar <frank.shearar at gmail.com>:
>
>> 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
>
>
> The changes are at
> https://github.com/jvuletich/Cuis/blob/master/UpdatesSinceLastRelease/1618-FixRecentMorphicSlowDown-JuanVuletich-2013Feb26-22h41m-jmv.1.cs.st
>
> 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