[Glass] Weird slowdown with a comparison
Mariano Martinez Peck
marianopeck at gmail.com
Tue Dec 17 07:28:00 PST 2013
Thanks Dale. So..I can confirm that enabling the JIT in the seaside gems
increases performance quite a lot in my report. They decreased to half :)
Now... John pasted this:
# This is set to allow breakpoints to be used ....
# For production usage, set GEM_NATIVE_CODE_ENABLED
# in the conf file for the appropriate gem
# (see
# $GEMSTONE/seaside/etc/maintenance30.conf
# $GEMSTONE/seaside/etc/seaside30.conf)
#
GEM_NATIVE_CODE_ENABLED = FALSE;
Notice the *"This is set to allow breakpoints to be used".*
The admin guide says:* "If any breakpoints are set in any methods, native
code is disabled. Native code is re-enabled when all breakpoints have been
removed"*
For me, I have 2 scenarios:
1) if someone press "remote debug" in a seaside walkback I really want to
be able to debug that with GemTools from the ObjectLog
2) if I put a halt somewhere in the code and I want to debug that later
I tested both enabling the JIT. 1) seems to work even with the JOT. 2) does
not work in the sense that the code is NOT interrupted by the halt, it
seems to simply continue executing and ignore it. So I cannot see how this
is exactly related to the above sentences. I think I do see the *"This is
set to allow breakpoints to be used". *But I cannot understand the "* "If
any breakpoints are set in any methods, native code is disabled. Native
code is re-enabled when all breakpoints have been removed"*"
If I understand this, it means that native code would be disabled
automatically, the VM would start to interpret, and hence I would expect
the halt to interrupt. But that doesn't happen in my case...the halt is
ignored.
Any clarification of the real implications of enabling the JIT would be
appreciated.
Thanks!
On Sat, Dec 14, 2013 at 9:40 PM, Dale K. Henrichs <
dale.henrichs at gemtalksystems.com> wrote:
> Mariano,
>
> I'll see what the vms guys have to say about this ...
>
> Dale
> ------------------------------
>
> *From: *"Mariano Martinez Peck" <marianopeck at gmail.com>
> *To: *"John McIntosh" <johnmci at smalltalkconsulting.com>,
> glass at lists.gemtalksystems.com
> *Sent: *Thursday, December 12, 2013 10:58:23 AM
> *Subject: *Re: [Glass] Weird slowdown with a comparison
>
>
>
>
>
> On Thu, Dec 12, 2013 at 9:18 AM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
>
>>
>>
>>
>> On Thu, Dec 12, 2013 at 12:04 AM, John McIntosh <
>> johnmci at smalltalkconsulting.com> wrote:
>>
>>> You restart the stone?
>>>
>>>
>> Yes.
>>
>>
>>> Also
>>>
>>> To determine if native code is in use by the currently executing
>>> session, execute:
>>>
>>> GsProcess usingNativeCode
>>>
>>>
>>>
>> Weird...that gives false!!! yet, GEM_NATIVE_CODE_ENABLED is true...
>>
>> mmmm maybe GemTools gem and Topaz gems are started with a false?
>>
>> Strange...
>>
>>
> OK.....I found out something. I was running this in my local gemstone
> (OSX). In the server I have a Linux box and there, GEM_NATIVE_CODE_ENABLED
> was also true,
> but GsProcess usingNativeCode also answered true, and indeed, the time
> to execute that is around 20ms (as I get in Pharo). So that is the
> explanation of the difference.
>
> The admin guide says: "Under some configurations on x86, in particular
> with Darwin, the 32-bit offset limit my be exceeded in some cases with a
> very large temporary object cache. If this occurs, native code is disabled."
> Maybe I am under this situation, I don't know. But my machine is 64
> bits.
>
>
>
>
>
>>
>>
>>>
>>> On Wed, Dec 11, 2013 at 9:57 PM, Mariano Martinez Peck <
>>> marianopeck at gmail.com> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Dec 11, 2013 at 11:42 PM, John McIntosh <
>>>> johnmci at smalltalkconsulting.com> wrote:
>>>>
>>>>> You know I've not played in this area but in data/system.conf
>>>>>
>>>>>
>>>>> # This is set to allow breakpoints to be used ....
>>>>>
>>>>> # For production usage, set GEM_NATIVE_CODE_ENABLED
>>>>>
>>>>> # in the conf file for the appropriate gem
>>>>>
>>>>> # (see
>>>>>
>>>>> # $GEMSTONE/seaside/etc/maintenance30.conf
>>>>>
>>>>> # $GEMSTONE/seaside/etc/seaside30.conf)
>>>>>
>>>>> #
>>>>>
>>>>> GEM_NATIVE_CODE_ENABLED = FALSE;
>>>>>
>>>>>
>>>>>
>>>> Wow...i didn't know the JIT could be enable/disabled. Nice! Thanks for
>>>> letting me know.
>>>>
>>>> I have just check using the Admin -> DoITs -> Gem Configuration Report
>>>> from GemTools and it was already in TRUE.
>>>> Just in case, I
>>>> edited /opt/gemstone/GemStone64Bit3.1.0.4-i386.Darwin/seaside/data/system.conf
>>>> and add it to TRUE.
>>>>
>>>> Still, I am having the same results :(
>>>>
>>>> What is weird is that I can use breakpoint in GemStone...so maybe the
>>>> JIT is not being run even if the boolean appears to be set..
>>>> But the default says it is TRUE.
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>> Admin manual states:
>>>>>
>>>>> "By default, generation of native code for Smalltalk methods is
>>>>> enabled. This is configured using the configuration parameter
>>>>> GEM_NATIVE_CODE_ENABLED. When native code is disabled, execution is
>>>>> interpreted; behavior will be identical but somewhat slower. "
>>>>>
>>>>> See
>>>>> http://downloads.gemtalksystems.com/docs/GemStone64/3.1.x/GS64-SysAdminGuide-3.1.pdf page 84
>>>>>
>>>>> You could fiddle, restart your stone and run your tests again to see
>>>>> what happens.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Dec 11, 2013 at 9:32 PM, Mariano Martinez Peck <
>>>>> marianopeck at gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am profiling some reports that take some time in GemStone and I
>>>>>> come to a place that I find weird. So I want to check with you to see if
>>>>>> this is expected.
>>>>>>
>>>>>> | char newline carriageReturn |
>>>>>> char := $a.
>>>>>> newline := Character lf.
>>>>>> carriageReturn := Character cr.
>>>>>> [1 to: 1000000 do: [ :i |
>>>>>> char == carriageReturn or: [ char == newline ] .
>>>>>> ]
>>>>>> ] timeToRun
>>>>>>
>>>>>> The following code, takes approx 5 ms in Pharo (Cog). While in
>>>>>> GemStone it takes me around 60ms. That is 12 times slower...
>>>>>> Am I doing something wrong? I used #to:do but #timesRepeat got
>>>>>> similar results. I try to not affect GC by putting the stuff before the
>>>>>> loop. I tried to run it several times just in case...
>>>>>>
>>>>>> So....is that expected or I am missing something?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> --
>>>>>> Mariano
>>>>>> http://marianopeck.wordpress.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> Glass mailing list
>>>>>> Glass at lists.gemtalksystems.com
>>>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> ===========================================================================
>>>>> John M. McIntosh <johnmci at smalltalkconsulting.com>
>>>>> Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
>>>>>
>>>>> ===========================================================================
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Mariano
>>>> http://marianopeck.wordpress.com
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> ===========================================================================
>>> John M. McIntosh <johnmci at smalltalkconsulting.com>
>>> Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
>>>
>>> ===========================================================================
>>>
>>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
--
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20131217/b156e6df/attachment-0001.html>
More information about the Glass
mailing list