[Glass] Weird slowdown with a comparison

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[Glass] Weird slowdown with a comparison

Mariano Martinez Peck
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
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Weird slowdown with a comparison

Mariano Martinez Peck



On Wed, Dec 11, 2013 at 11:42 PM, John McIntosh <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--
===========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
===========================================================================




--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Weird slowdown with a comparison

Mariano Martinez Peck



On Thu, Dec 12, 2013 at 12:04 AM, John McIntosh <[hidden email]> 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...

 

On Wed, Dec 11, 2013 at 9:57 PM, Mariano Martinez Peck <[hidden email]> wrote:



On Wed, Dec 11, 2013 at 11:42 PM, John McIntosh <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--
===========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
===========================================================================




--
Mariano
http://marianopeck.wordpress.com



--
===========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
===========================================================================




--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Weird slowdown with a comparison

Mariano Martinez Peck



On Thu, Dec 12, 2013 at 9:18 AM, Mariano Martinez Peck <[hidden email]> wrote:



On Thu, Dec 12, 2013 at 12:04 AM, John McIntosh <[hidden email]> 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 <[hidden email]> wrote:



On Wed, Dec 11, 2013 at 11:42 PM, John McIntosh <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--
===========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
===========================================================================




--
Mariano
http://marianopeck.wordpress.com



--
===========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
===========================================================================




--
Mariano
http://marianopeck.wordpress.com



--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Weird slowdown with a comparison

Dale Henrichs-3
Mariano,

I'll see what the vms guys have to say about this ...

Dale

From: "Mariano Martinez Peck" <[hidden email]>
To: "John McIntosh" <[hidden email]>, [hidden email]
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 <[hidden email]> wrote:



On Thu, Dec 12, 2013 at 12:04 AM, John McIntosh <[hidden email]> 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 <[hidden email]> wrote:



On Wed, Dec 11, 2013 at 11:42 PM, John McIntosh <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--
===========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
===========================================================================




--
Mariano
http://marianopeck.wordpress.com



--
===========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
===========================================================================




--
Mariano
http://marianopeck.wordpress.com



--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass


_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: [Glass] Weird slowdown with a comparison

Mariano Martinez Peck
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,

I'll see what the vms guys have to say about this ...

Dale

From: "Mariano Martinez Peck" <[hidden email]>
To: "John McIntosh" <[hidden email]>, [hidden email]
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 <[hidden email]> wrote:



On Thu, Dec 12, 2013 at 12:04 AM, John McIntosh <[hidden email]> 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 <[hidden email]> wrote:



On Wed, Dec 11, 2013 at 11:42 PM, John McIntosh <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--
===========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
===========================================================================




--
Mariano
http://marianopeck.wordpress.com



--
===========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd. Twitter: squeaker68882
===========================================================================




--
Mariano
http://marianopeck.wordpress.com



--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass




--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass