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 [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Wed, Dec 11, 2013 at 11:42 PM, John McIntosh <[hidden email]> wrote:
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,
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Thu, Dec 12, 2013 at 12:04 AM, John McIntosh <[hidden email]> wrote:
Yes.
Weird...that gives false!!! yet, GEM_NATIVE_CODE_ENABLED is true...
mmmm maybe GemTools gem and Topaz gems are started with a false? Strange...
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Thu, Dec 12, 2013 at 9:18 AM, Mariano Martinez Peck <[hidden email]> wrote:
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.
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Mariano, I'll see what the vms guys have to say about this ... Dale From: "Mariano Martinez Peck" <[hidden email]> _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
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 <[hidden email]> wrote:
Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |