Why Squeak is so sloooow?
Locked
12
12
Re: RE: Why Squeak is so sloooow?
 
|
On 2006 September 21 18:33, David Shaffer wrote:
> ] timeToRun. > > 15000 > > At this point the UI is so slow that moving a window or morph results in > a noticable lag (nearly a second between releasing the mouse button > after a drag until the object that was dragged is drawn in its new > location). > David, Thanks for running it - your observation is interesting, here it does not seem noticeably slower after I have run the benchmark ... I am starting to think (if I read your configuration correctly) - you do have a different image (I have newer than 7055) and slightly different VM - at least compiled using different GCC version... The older GCC the faster :) - If you have time to experiment, you may want to try Ian's VM that I use? Davids setup: ======================== shaffer@localhost ~/Squeak/Squeak3.9g-7055 $ squeak -version 3.9-7 #1 Mon Sep 4 17:01:02 EDT 2006 gcc 3.4.6 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux localhost 2.6.17-gentoo-r4 #1 PREEMPT Thu Aug 24 18:31:06 EDT 2006 i686 Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz GNU/Linux default plugin location: /usr/local/lib/squeak/3.9-7/*.so ======================== Milans setup: ======================== Squeak3.9g-7058.image mzimmermann@home-server:~> squeak -version 3.9-7 #5 Mon Apr 24 20:07:28 PDT 2006 gcc 3.3.5 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux vps.piumarta.com 2.4.20-021stab028.18.777-enterprise #1 SMP Wed Sep 14 19:34:46 MSD 2005 i686 GNU/Linux default plugin location: /usr/local/lib/squeak/3.9-7/*.so ======================== Milan > > You would have to install the above package from Squeakmap to run the > > "graphics test" I mentioned, but please note it's alpha, so install to a > > 3.9 image without important stuff. > > > > I am not sure this is a good "graphical test", it does create graphs, so > > it should have some value, it is non-interactive graphics though. Apart > > from that, 3.9 feels as good as 3.7 here, but as you said .. it's my > > feelin' only > > Agreed...it is subjective. > > David > > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
|
|
In reply to this post by Brad Fuller
hi-
Brad Fuller also wrote: > Brad Fuller wrote: >> Yoshiki Ohshima wrote: >> >>> Antonio, >>> >>> If you evaluate the following (and print-it): >>> >>> | a b | >>> a := FloatArray new: (16 * 1024*1024). >>> b := FloatArray new: (16 * 1024*1024). >>> [a += b] timeToRun. >>> >>> you probably get a number around 100 or 200. This means that Squeak >>> can add two 32-bit float arrays with 16M entries in 100 milliseconds >>> or such. This is basicaly comparable Java-performance. >>> >> Ouch! I just did this (twice, just to make sure) in the 7058 imagine and >> squeak bombed with the output below. >> This was with the latest Linux 3.9 VM. I tried with the 3.7-7 VM and it >> bombed too. >> kernel: 2.6.16-1.2080.16.rrt.rhfc5.ccrma (realtime kernel from Stanford >> - for audio) >> > just a note to say that I tried it on kernel: > 2.6.17-1.2174_FC5 > with no difference.... same problem. > Anyone have an idea for this? > no ideas, but same thing happens here, with debian unstable: % grep squeak /etc/apt/sources.list deb http://ftp.squeak.org/debian/ unstable main contrib non-free % cat /proc/version Linux version 2.6.15.2 (jpc@krazykat) (gcc version 4.0.3 20060128 (prerelease) (Debian 4.0.2-8)) #1 PREEMPT Fri Feb 3 16:48:19 EST 2006 % squeak -version 3.9-7 #1 Sat Aug 5 23:08:06 CEST 2006 gcc 3.3.5 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux shire 2.6.8-3-686 #1 Sat Jul 15 10:32:25 UTC 2006 i686 GNU/Linux default plugin location: /usr/lib/squeak/3.9-7/*.so % ls -l /usr/share/squeak/squeak3.9.image.gz -rw-r--r-- 1 root root 7616104 Sep 11 02:47 /usr/share/squeak/squeak3.9.image.gz john _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: RE: Why Squeak is so sloooow?
|
|
In reply to this post by stephane ducasse-2
stephane ducasse wrote:
> Hi david > this is really strange because 3.9 is much snappier than 3.8 on our > machines. This is strange. > Do you use a special settings (such as some strange smallland setup?) > > Stef > Nope, fresh 3.9g-7055 image. I develop in 3.7 which is fairly snappy. 3.9 seems a tad slower. Most notable is the pause when I select a method in the browser. This might have to do with the syntax highlighting. Anyway it took me a while to get used to 3.7...3.9 might be the same way. I plan to play with it more now that Milan got me interested in MathMorphs. So much cool stuff lurking around in Squeak! David _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: RE: Why Squeak is so sloooow?
|
|
In reply to this post by stephane ducasse-2
stephane ducasse wrote:
> can you report that on squeak-dev? > > No...I'm sure the folks there would just convince me that I'm imagining things and that 3.9 really is more responsive than my X desktop apps ;-) I tried that when I first came to Squeak. Anyway now I'm busy with MathMorphs ;-) David _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: Why Squeak is so sloooow?
|
|
In reply to this post by Brad Fuller
On 2006 September 21 17:06, Brad Fuller wrote:
> > Ouch! I just did this (twice, just to make sure) in the 7058 imagine and > > squeak bombed with the output below. > > This was with the latest Linux 3.9 VM. I tried with the 3.7-7 VM and it > > bombed too. > > kernel: 2.6.16-1.2080.16.rrt.rhfc5.ccrma (realtime kernel from Stanford > > - for audio) > > just a note to say that I tried it on kernel: > 2.6.17-1.2174_FC5 > with no difference.... same problem. > Anyone have an idea for this? not really .. just FWIW it is ok with: ======================== Squeak3.9g-7058.image mzimmermann@home-server:~> squeak -version 3.9-7 #5 Mon Apr 24 20:07:28 PDT 2006 gcc 3.3.5 Squeak3.9alpha of 4 July 2005 [latest update: #7021] Linux vps.piumarta.com 2.4.20-021stab028.18.777-enterprise #1 SMP Wed Sep 14 19:34:46 MSD 2005 i686 GNU/Linux default plugin location: /usr/local/lib/squeak/3.9-7/*.so ======================== (SuSE 9.3) Milan > > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: RE: Why Squeak is so sloooow?
|
|
In reply to this post by Milan Zimmermann-2
Milan Zimmermann wrote:
> [snip] > I am starting to think (if I read your configuration correctly) - you do have > a different image (I have newer than 7055) and slightly different VM - at > least compiled using different GCC version... The older GCC the faster :) - > If you have time to experiment, you may want to try Ian's VM that I use? > > Thanks for the tip. That definitely made a difference. The benchmark number didn't change by much (dropped to about 13000ms) but responsiveness after the test improved noticeably. David _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Re: RE: Why Squeak is so sloooow?
|
|
On 2006 September 21 22:20, David Shaffer wrote:
> Milan Zimmermann wrote: > > [snip] > > I am starting to think (if I read your configuration correctly) - you do > > have a different image (I have newer than 7055) and slightly different VM > > - at least compiled using different GCC version... The older GCC the > > faster :) - If you have time to experiment, you may want to try Ian's VM > > that I use? > > Thanks for the tip. That definitely made a difference. The benchmark > number didn't change by much (dropped to about 13000ms) but > responsiveness after the test improved noticeably. That sounds good, glad it's better. Sort of makes me wonder whether various distributions make people suffer with slower VMs if they build them themselves ... but I have little idea how to make distros aware of those performance items. Milan > > David > > _______________________________________________ > Beginners mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/beginners _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
|
|
In reply to this post by Brad Fuller
Brad Fuller wrote:
> Brad Fuller wrote: > >> Yoshiki Ohshima wrote: >> >> >>> Antonio, >>> >>> If you evaluate the following (and print-it): >>> >>> | a b | >>> a := FloatArray new: (16 * 1024*1024). >>> b := FloatArray new: (16 * 1024*1024). >>> [a += b] timeToRun. >>> >>> you probably get a number around 100 or 200. This means that Squeak >>> can add two 32-bit float arrays with 16M entries in 100 milliseconds >>> or such. This is basicaly comparable Java-performance. >>> >>> >> Ouch! I just did this (twice, just to make sure) in the 7058 imagine and >> squeak bombed with the output below. >> This was with the latest Linux 3.9 VM. I tried with the 3.7-7 VM and it >> bombed too. >> kernel: 2.6.16-1.2080.16.rrt.rhfc5.ccrma (realtime kernel from Stanford >> - for audio) >> >> > just a note to say that I tried it on kernel: > 2.6.17-1.2174_FC5 > with no difference.... same problem. > Anyone have an idea for this? > | a b | a := FloatArray new: (16 * 1024*500). b := FloatArray new: (16 * 1024*500). [a += b] timeToRun. works fine. the only thing I can think of is that I'm running out of total memory (physical+swap). With my total physical memory of 512MB and swap of 1GB, I would run out of memory with the original test case. If this is the case, is there not a safe guard in Squeak to prevent this crash? -- brad fuller _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
Squeak VM crashes (was: Re: Why Squeak is so sloooow?)
|
|
Brad Fuller wrote:
> Reducing the array size to something like: > > | a b | > a := FloatArray new: (16 * 1024*500). > b := FloatArray new: (16 * 1024*500). > [a += b] timeToRun. > > works fine. > > the only thing I can think of is that I'm running out of total memory > (physical+swap). With my total physical memory of 512MB and swap of 1GB, > I would run out of memory with the original test case. If this is the > case, is there not a safe guard in Squeak to prevent this crash? I think it's got nothing to do with it (and you guys should really change the subject line if you're discussing crashes and want people to notice your discussion). Looking at the thread, there is a dead giveaway of the problem in the stack trace right here: -2128068296 HandMorph>sendMouseEvent: -2128068388 HandMorph>handleEvent: -2128068768 MouseOverHandler>processMouseOver: 2032428416 HandMorph>handleEvent: 2032428116 HandMorph>processEvents 2032428208 [] in WorldState>doOneCycleNowFor: 2032428024 SequenceableCollection>do: Your memory was allocated partially in the lower and partially in the upper half of the 32bit address range. Looks like by allocating "just enough" you're tipping it over to the other half of memory and my guess would be that this is what's killing it, e.g., some signed/unsigned/pointer arithmetic problem. And some plugin might cause that as well, possibly even the FloatArrayPlugin itself (I don't think anyone has ever reviewed it for those kinds of issues). Sigh. We should have a debug option in the VM that allows allocating the object memory at a specific address for testing this kind of behavior. Any takers? Cheers, - Andreas _______________________________________________ Beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/beginners |
«
Return to Squeak - Beginners
|
1 view|%1 views
| Free forum by Nabble | Edit this page |