Fwd: Squeak 5 on Raspberry Pi
Locked
12
12
Fwd: Squeak 5 on Raspberry Pi
 
Administrator
|
Cheers,
Sean |
Re: Fwd: Squeak 5 on Raspberry Pi
|
|
Yeah this is very well-known. Note that here we are talking about the pi B with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A to open Nautilus on the stack vm while the Squeak UI was usable. The Pharo UI has been focusing on IDE features at the cost of performance, such as auto-completion, better RB integration, Nautilus, new debugging tools... None of the current tools (Nautilus, GTInspector, GTPlayground, ...) are fast enough for slower devices, some of them are barely fast enough for a laptop (for example at some point there was no auto-refresh on GTInspector because of performance). It's not clear if it's due to the new tools themselves as Morphic is drastically slower too on Pharo. The Squeak UI has been focusing on performance and stability. It is very convenient for slow devices but also for slow VM like for example the debug VM. The official answer to this problem is that Block/Brick will be faster so it will solve all this problems. We will see. 2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <[hidden email]>:
|
|
|
yes, this is the “semi-official” answer and that’s an error. Yes ideally it will solve some problems (the ones related to Morphic), but current lack of performance on Pharo tools is not because of Morphic but because of some non optimised choices. For example, months ago I got pissed because our current list implementation was not fast enough for our tools and that’s why I made FastTable: because it was evident we needed a better design for it. It speeded the startup of Nautilus by an order of magnitude. This is a widget developed with Morphic, but with a not-naive approach, so is fast. As lists, some others widgets (notably tree) could be optimised… But this will not be the solution of the problem either: we need to spend time on optimisation. Nautilus is not a good tool (we all know it has design problems all around) but with the time had improve and not using it is almost enjoyable… but for example, the new debugger (which I’m not criticising as a tool, I like it a lot) makes me hurt… is slower than eclipse debugger and that’s a lot to say. Also new inspector: is good, but can’t we optimise it? maybe we need to make some concession, but is the moment of doing it. Recently I’m noticing a slowdown in Spotter: I believe is because one of his categories is refreshing to the network but I’m not sure: this slowdown is not production acceptable, for me is a Show Stopper because it kills the usability of the tool (of a tool who is great, but it HAS to be fast, otherwise is useless). Mea culpa: more than once I have not protested even knowing than solution X was “10% slower than the older one, but that’s ok, we can live with it”… guess what? once you accumulate enough of those 10% penalties, you have a barely usable system. Can I ask you guys to spend some time optimising tools, before we release Pharo 5? Remember, “First impressions counts”! (we even have a category for it in FogBugz). Esteban
|
|
|
I meant “.. had improve and NOW using it is almost enjoyable”… Freud could say a lot of things about that lapsus :P |
|
|
You made my day. It is true the Pharo feels slow, even of a powerful machine [Core i7 @ 4.4Ghz] (e.g. vs Visual Studio, PhpStorm, ... which aren't little beasts). It is particularly frustrating when having to work with BIG FONTS like I do and inside a Linux VM. Squeak is indeed super zippy by comparison. That's frustrating. Phil On Fri, Mar 25, 2016 at 10:04 AM, Esteban Lorenzano <[hidden email]> wrote:
|
Re: Fwd: Squeak 5 on Raspberry Pi
|
|
In reply to this post by Clément Béra
2016-03-25 7:43 GMT+01:00 Clément Bera <[hidden email]>:
Morphic drasticallly slower ? I would expect morphic code is mostly the same in pharo and squeak. If pharo is slower, this is a good starting point for optimising. Can you gives some hints?
|
Re: Squeak 5 on Raspberry Pi
|
|
In reply to this post by EstebanLM
2016-03-25 9:45 GMT+01:00 Esteban Lorenzano <[hidden email]>:
But isn't the old list implementation (mostly) the same that is used in squeak (and feels faster there?) ?
|
|
|
yes, but we use it very differently :) we add tons and tons of functionality on top of it, so we made, Nautilus for example, slower. Is not a problem of the list: is that we are/were using it differently, and in a very different way of his first intention (take a pluggable list, add 1k strings: works… add 1k icons… works worst, but works… add 1k buttons instead those icons… and suffer… :P). Esteban
|
Re: Fwd: Squeak 5 on Raspberry Pi
|
|
In reply to this post by Nicolai Hess-3-2
On 25-03-16 11:49, Nicolai Hess wrote:
> Morphic drasticallly slower ? I would expect morphic code is mostly the > same in pharo and squeak. If pharo is slower, this is a good starting > point for optimising. Can you gives some hints? I do not have the impression that morphic is so much slower. We had/have a problem of too many announcements being send and too many redraws happening. Stephan |
|
|
In reply to this post by EstebanLM
Hi,
> On Mar 25, 2016, at 9:45 AM, Esteban Lorenzano <[hidden email]> wrote: > >> >> On 25 Mar 2016, at 07:43, Clément Bera <[hidden email]> wrote: >> >> Yeah this is very well-known. Note that here we are talking about the pi B with Spur + the JIT, 2 years ago I remember needing 35 second on the pie A to open Nautilus on the stack vm while the Squeak UI was usable. >> >> The Pharo UI has been focusing on IDE features at the cost of performance, such as auto-completion, better RB integration, Nautilus, new debugging tools... None of the current tools (Nautilus, GTInspector, GTPlayground, ...) are fast enough for slower devices, some of them are barely fast enough for a laptop (for example at some point there was no auto-refresh on GTInspector because of performance). It's not clear if it's due to the new tools themselves as Morphic is drastically slower too on Pharo. >> >> The Squeak UI has been focusing on performance and stability. It is very convenient for slow devices but also for slow VM like for example the debug VM. >> >> The official answer to this problem is that Block/Brick will be faster so it will solve all this problems. We will see. > > yes, this is the “semi-official” answer and that’s an error. Yes ideally it will solve some problems (the ones related to Morphic), but current lack of performance on Pharo tools is not because of Morphic but because of some non optimised choices. > For example, months ago I got pissed because our current list implementation was not fast enough for our tools and that’s why I made FastTable: because it was evident we needed a better design for it. It speeded the startup of Nautilus by an order of magnitude. This is a widget developed with Morphic, but with a not-naive approach, so is fast. > As lists, some others widgets (notably tree) could be optimised… > But this will not be the solution of the problem either: we need to spend time on optimisation. Nautilus is not a good tool (we all know it has design problems all around) but with the time had improve and not using it is almost enjoyable… but for example, the new debugger (which I’m not criticising as a tool, I like it a lot) makes me hurt… is slower than eclipse debugger and that’s a lot to say. That is a good one :). There is an open issue with the blinking problem when you accept code which makes it appear slower than it actually is, but we are stuck with it and we could benefit from help. > Also new inspector: is good, but can’t we optimise it? maybe we need to make some concession, but is the moment of doing it. The optimization we should do now is to replace the appearances of MorphTreeMorph with FastTable. This would imply that the Raw presentation would not longer have a tree (because it is not supported in FastTable). I would be very happy if we could do that. Do we agree on this? > Recently I’m noticing a slowdown in Spotter: I believe is because one of his categories is refreshing to the network but I’m not sure: this slowdown is not production acceptable, for me is a Show Stopper because it kills the usability of the tool (of a tool who is great, but it HAS to be fast, otherwise is useless). Could you be more specific about the Spotter problem that you see? Also, in the last couple of days Alex Syrel improved the speed of Spotter significantly. It is not yet integrated. It would be useful to get feedback on this because maybe we missed something. > Mea culpa: more than once I have not protested even knowing than solution X was “10% slower than the older one, but that’s ok, we can live with it”… guess what? once you accumulate enough of those 10% penalties, you have a barely usable system. > > We need to concentrate efforts on performance. There will not be magical solution: if we do not spend time on enhance tools for performance, they will be not good enough. > > Can I ask you guys to spend some time optimising tools, before we release Pharo 5? Remember, “First impressions counts”! (we even have a category for it in FogBugz). It would indeed be useful to get more eyes spent on this. Cheers, Doru > > Esteban > > > >> >> >> 2016-03-25 1:15 GMT+01:00 Sean P. DeNigris <[hidden email]>: >> >> > [Squeak 5 is] so *fast* (I have it running next to >> > Pharo, which is unusable slow as a GUI. Whereas Squeak 5 is zipping >> > along at Windows desktop speeds on the Pi (Model B). >> >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Fwd-Squeak-5-on-Raspberry-Pi-tp4886416.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. -- www.tudorgirba.com www.feenk.com "Not knowing how to do something is not an argument for how it cannot be done." |
Re: Squeak 5 on Raspberry Pi
|
|
2016-03-25 12:52 GMT+01:00 Tudor Girba <[hidden email]>: Hi, "appear slower than it actually is" Really? Aliaksei comment was: "Each code accept triggers a lot of glamour inner stuff and in the end refreshes the almost whole debugger interface. (Panes, Tabulator, LazyTable and so on)" So, is it slow, or does it just look slow?
|
|
|
In reply to this post by Tudor Girba-2
Hi,
actually there is a tree implementation based on fast table, but I’m not sure is production ready (Cyril can say something about). But anyway since I never understood why we have a tree there (since we will “open” attribute in next panel), I do agree, strongly :)
not sure, I open and it takes some seconds to actually show anything. I thought it was caused because of the catalog refresh to populate projects, but I’m not sure. In any case, load catalog projects in spotter is cool, but we need to find a better implementation. One that does not freezes spotter until it refresh (remember, Pharo is also used in places with crapy connection or not connection at all).
yes! if you want to suffer, do this experiment: 1. open a Pharo2 and open debugger on anything 2. then Pharo3, 4 and 5… feel the incremental slowdown 3. cry :’( Esteban
|
|
well so far for me at least pharo 5 works ok perfomance wise on my quad core imac and my dual core macbook air. The only serious slow down I have is when loading images but I suspect this code is forked from Squeak anyway. System Browser was indeed a big issue with large classes but after FastTable it works fine. On Fri, Mar 25, 2016 at 2:33 PM Esteban Lorenzano <[hidden email]> wrote:
|
Re: Fwd: Squeak 5 on Raspberry Pi
|
In reply to this post by Stephan Eggermont-3
Not exactly related to Announcement, but I remember when I first port
DrGeo to Squeak (at that time Pharo did not exist) I used a lot of change/update when objects in the canvas changed. It was terribly slow, and later opted for a top-down update in the list of object. So some sometime what look like a cool stuff (decoupled objects) is just a drag. Regarding optimizing, I share my opinion here months ago, I think Pharo need consolidation releases: no new features, only bugs fix and speed improvement. There are enough new features in Pharo for a couple of years, but the product need to *be* solid and *feel* solid. Hilaire Le 25/03/2016 12:33, Stephan Eggermont a écrit : > On 25-03-16 11:49, Nicolai Hess wrote: >> Morphic drasticallly slower ? I would expect morphic code is mostly >> the same in pharo and squeak. If pharo is slower, this is a good >> starting point for optimising. Can you gives some hints? > I do not have the impression that morphic is so much slower. > We had/have a problem of too many announcements being send and > too many redraws happening. > > Stephan > > -- Dr. Geo http://drgeo.eu |
Re: Fwd: Squeak 5 on Raspberry Pi
|
|
2016-03-25 18:18 GMT+01:00 Hilaire <[hidden email]>: Not exactly related to Announcement, but I remember when I first port +1
|
Re: Fwd: Squeak 5 on Raspberry Pi
|
|
2016-03-25 18:30 GMT+01:00 Nicolai Hess <[hidden email]>:
Agreed.
|
Re: Fwd: Squeak 5 on Raspberry Pi
|
|
In reply to this post by HilaireFernandes
yes! Maybe a solid core with a layer of fast evolving things. That's the model for Hortonworks now. A stable Hadoop core for stability and fast updates for things like Spark. Phil On Mar 25, 2016 6:19 PM, "Hilaire" <[hidden email]> wrote:
Not exactly related to Announcement, but I remember when I first port |
|
|
In reply to this post by Nicolai Hess-3-2
So guys, you do not want Xtreams (and prefer to use Streams that
have been "designed" decades ago) ;D ?
no bootstrapped core (clement you do not want to have a mini image :) ? and a new UI frameworks? I personnally want to have new widgets, a real UI builder and massively cleaning Spec. Now I would like to have multiple tool sets - I understand that people like the new debugger (I do not like it) - I want the possibility to have a mini tools tool set. If you want to clean Pharo you can start cleaning Komitter stupid use of state pattern generating a lot of garbage instead of having a single animated morph. We should clean Versionner- I have the impression that half of the classes are not mandatory. Stef
|
|
|
In reply to this post by philippe.back@highoctane.be
But pharo is solid.
When is the last time we changed FFI and GC and new object representations? You see FFI is really really important not having one = no Pharo. So yes Pharo is doing too much stuff and we should have sprint to clean and optimise but FFI and Spur are important. Stef Le 25/3/16 20:37,
[hidden email] a écrit :
|
Re: Fwd: Squeak 5 on Raspberry Pi
|
|
In reply to this post by stepharo
2016-03-25 22:27 GMT+01:00 stepharo <[hidden email]>:
I want a clean and stable core. The way Rubric and GT-Tools were pushed into the core was a mess. Rubric is a big bad bunch of badly documented code with lots of copy-paste garbage - we should do better. And since it was included I hear it was abandoned by alain and TxText is the next. I see up to no development for TxText. The same for Athens, bugs or requests for conclusins I entered in FogBugz are, or will be closed (timout) because no one cares. Instead Athens is used as it is or change by others just for its own projects (roassal, Bloc, Brick).
me too, but what is the purpose of spec, if we replace all tools based on spec (debugger/inspector/...) with GT-Tools?
I fix bugs, there are many bugs.
Our tools are in a much more worse state than in Pharo 4, not clean, not stable. We are in code freeze since 6 weeks, and there are still many new changes instead of only bug fixes.
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |