Re: [Newbies] Why Squeak is so sloooow?

Yoshiki Ohshima 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)

what's the problem?

(Note Andreas said to Avi in a Sep12 msg regarding similar error:
"I think you're seeing the old problem of signed vs. unsigned ints when
accessing memory locations (the negative numbers seem to indicate that
much). Try a later VM (3.9-7 is the latest according to SqueakVM.org) -
IIRC, then this problem got fixed in later versions. )

Just to show I'm using the 3.9 version:

[bfuller@ives images]$ which squeak
/usr/local/bin/squeak

[bfuller@ives images]$ ls -lsa /usr/local/bin/squeak
0 lrwxrwxrwx 1 bfuller sonaural 26 Sep 14 16:56 /usr/local/bin/squeak ->
  ../lib/squeak/3.9-7/squeak

[bfuller@ives images]$ ls /usr/local/lib/squeak/3.9-7
AioPlugin             Squeak3D             vm-display-X11
B3DAcceleratorPlugin  UnixOSProcessPlugin  vm-sound-null
npsqueak.so           UUIDPlugin           vm-sound-OSS
PseudoTTYPlugin       vm-display-fbdev     XDisplayControlPlugin
squeak                vm-display-null


------------------------------------------------------
sweep failed to find exact end of memory

-2128024296 Point>+
-2128024388 Rectangle>center
-2128026592 Morph>layoutInBounds:
-2128027312 Morph>layoutProportionallyIn:
-2128046872 [] in ProportionalLayout>layout:in:
-2128046964 SequenceableCollection>do:
-2128047056 Morph>submorphsDo:
-2128047148 ProportionalLayout>layout:in:
-2128054100 Morph>doLayoutIn:
-2128055204 [] in Morph>fullBounds
-2128055020 BlockContext>on:do:
-2128055388 Morph>fullBounds
-2128055296 [] in Morph>submorphBounds
-2128055480 SequenceableCollection>do:
-2128055572 Morph>submorphBounds
-2128057332 Morph>privateFullBounds
-2128065988 Morph>doLayoutIn:
-2128067000 [] in Morph>fullBounds
-2128066816 BlockContext>on:do:
-2128067092 Morph>fullBounds
-2128067184 MorphicEventDispatcher>dispatchDefault:with:
-2128067276 MorphicEventDispatcher>dispatchEvent:with:
-2128067384 Morph>processEvent:using:
-2128067812 PasteUpMorph>processEvent:using:
-2128067960 Morph>processEvent:
-2128068052 HandMorph>sendEvent:focus:clear:
-2128068296 HandMorph>sendMouseEvent:
-2128068388 HandMorph>handleEvent:
-2128068768 MouseOverHandler>processMouseOver:
2032428416 HandMorph>handleEvent:
2032428116 HandMorph>processEvents
2032428208 [] in WorldState>doOneCycleNowFor:
2032428024 SequenceableCollection>do:
2032427932 WorldState>handsDo:
2032427840 WorldState>doOneCycleNowFor:
2032427748 WorldState>doOneCycleFor:
2032427656 WorldState>doOneSubCycleFor:
2032427564 PasteUpMorph>doOneSubCycle
2032409876 MenuMorph>invokeModalAt:in:allowKeyboard:
2032409784 MenuMorph>invokeModal:
2032409416 MenuMorph>invokeModal
2032402804 PluggableTextMorph>yellowButtonActivity:
2032402712 TextMorphForEditView>mouseDown:
2032402620 Morph>handleMouseDown:
2032402528 MouseButtonEvent>sentTo:
2032402436 Morph>handleEvent:
2032402332 MorphicEventDispatcher>dispatchMouseDown:with:
2032402200 MorphicEventDispatcher>dispatchEvent:with:
2032402108 Morph>processEvent:using:
2032401976 MorphicEventDispatcher>dispatchMouseDown:with:
2032401844 MorphicEventDispatcher>dispatchEvent:with:
2032401752 Morph>processEvent:using:
2032401660 MorphicEventDispatcher>dispatchMouseDown:with:
2032401568 MorphicEventDispatcher>dispatchEvent:with:
2032401476 Morph>processEvent:using:
2032401344 MorphicEventDispatcher>dispatchMouseDown:with:
2032401252 MorphicEventDispatcher>dispatchEvent:with:
2032401160 Morph>processEvent:using:
2032401068 MorphicEventDispatcher>dispatchMouseDown:with:
2032400976 MorphicEventDispatcher>dispatchEvent:with:
2032400868 Morph>processEvent:using:
2032400776 PasteUpMorph>processEvent:using:
2032400592 Morph>processEvent:
2032400500 HandMorph>sendEvent:focus:clear:
2032400408 HandMorph>sendMouseEvent:
2032400264 HandMorph>handleEvent:
2032400044 HandMorph>processEvents
2032400136 [] in WorldState>doOneCycleNowFor:
2032399952 SequenceableCollection>do:
2032399860 WorldState>handsDo:
2032399768 WorldState>doOneCycleNowFor:
2032399676 WorldState>doOneCycleFor:
2032399584 PasteUpMorph>doOneCycle
2025718576 [] in >spawnNewProcess
2025718760 [] in BlockContext>newProcess

Brad Fuller wrote: 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?

hi-

Brad Fuller also wrote:
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

On 2006 September 21 17:06, Brad Fuller wrote:

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

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?

--
brad fuller

Brad Fuller wrote:
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

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.

Is this really a good idea? After all it's implemented in C
(FloatPlugin). To me this is like pointing out how fast Dictionaries
and OrderedCollections in Python or Ruby are which are as well
implemented in C.

Philippe