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