JESS: [EXTERNAL] Jess in a multithreaded environment

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

JESS: [EXTERNAL] Jess in a multithreaded environment

Nguyen, Son
Jess in a multithreaded environment

Hi Jess experts,

We use Jess in a multi-threaded environment and have experienced some performance degradation when going from a single thread to multiple threads.

Our implementation uses the Slot Specific feature.

Using a Java profiler, HashCodeComputer.isValueObject() stood out as one of the main contributing factors, if not the most likely,  to the degradation.

This method is synchronized using the static List m_nonValueClasses member. The averege time of this method execution is

0,2022 microsec for one thread and 1,2192 microsec for two threads. Basically, 0.2 microsec for one threads and 1 microsec for 2 and 4 threads.

There are hundreds of thousands of these calls for a single Rete.run.

Is it possible that HashCodeComputer.isValueObject() has such an effect on scalability and performance?
If so, what can be done about it?

I am looking forward to hearing any feedback.

Son Nguyen

Reply | Threaded
Open this post in threaded view
|

Re: JESS: [EXTERNAL] Jess in a multithreaded environment

Friedman-Hill, Ernest
Are you adding non-value classes to the list yourself, or is this just with the small number of default listings?

This method will get called when you evaluate the hash code of a Java object in the Rete memory; this will happen often during pattern matching. There's actually enough room to cache the hash code in the members of the Value class that are unused for Java object values, so we could try that as a performance improvement.  Do you have a source license, so I could send you a patch to try?

From: <Nguyen>, Son Nguyen <[hidden email]<mailto:[hidden email]>>
Reply-To: jess-users <[hidden email]<mailto:[hidden email]>>
Date: Thursday, December 13, 2012 11:04 AM
To: jess-users <[hidden email]<mailto:[hidden email]>>
Subject: JESS: [EXTERNAL] Jess in a multithreaded environment



Hi Jess experts,

We use Jess in a multi-threaded environment and have experienced some performance degradation when going from a single thread to multiple threads.

Our implementation uses the Slot Specific feature.

Using a Java profiler, HashCodeComputer.isValueObject() stood out as one of the main contributing factors, if not the most likely,  to the degradation
Reply | Threaded
Open this post in threaded view
|

WG: JESS: [EXTERNAL] Jess in a multithreaded environment

Henschel, Joerg
Yes, we (Software AG) have a source license, so it'd be great if you could provide a patch for this.

Thanks!

Jörg Henschel
Director Research & Development

Email: [hidden email]
Phone: +49 341 49287-700 | Fax: +49 341 49287-01

itCampus Software- und Systemhaus GmbH | a Software AG Company
Nonnenstrasse 37 | 04229 Leipzig | Germany | http://www.itcampus.de
Amtsgericht Leipzig HRB 15872 | Managing Director: Guido Laures



-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Friedman-Hill, Ernest
Gesendet: Dienstag, 18. Dezember 2012 19:50
An: jess-users
Betreff: Re: JESS: [EXTERNAL] Jess in a multithreaded environment

Are you adding non-value classes to the list yourself, or is this just with the small number of default listings?

This method will get called when you evaluate the hash code of a Java object in the Rete memory; this will happen often during pattern matching. There's actually enough room to cache the hash code in the members of the Value class that are unused for Java object values, so we could try that as a performance improvement.  Do you have a source license, so I could send you a patch to try?

From: <Nguyen>, Son Nguyen <[hidden email]<mailto:[hidden email]>>
Reply-To: jess-users <[hidden email]<mailto:[hidden email]>>
Date: Thursday, December 13, 2012 11:04 AM
To: jess-users <[hidden email]<mailto:[hidden email]>>
Subject: JESS: [EXTERNAL] Jess in a multithreaded environment



Hi Jess experts,

We use Jess in a multi-threaded environment and have experienced some performance degradation when going from a single thread to multiple threads.

Our implementation uses the Slot Specific feature.

Using a Java profiler, HashCodeComputer.isValueObject() stood out as one of the main contributing factors, if not the most likely,  to the degradation



--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [hidden email]'
in the BODY of a message to [hidden email], NOT to the list
(use your own address!) List problems? Notify [hidden email].
--------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: JESS: [EXTERNAL] Jess in a multithreaded environment

Wolfgang Laun-2
Warning: I may have misunderstood the issue completely.

If there is a list (or any other collection) maintaining the set of
value classes, it stands to reason that it is synchronized for use in
a multithreaded environment, and the contention for its lock may very
well cause a performance hit.  If a lookup using this list is
necessary for distinguishing between constant and non-constant hash
codes, I don't see how caching a constant hash code may improve the
situation.

-W


On 03/01/2013, Henschel, Joerg <[hidden email]> wrote:

> Yes, we (Software AG) have a source license, so it'd be great if you could
> provide a patch for this.
>
> Thanks!
>
> Jörg Henschel
> Director Research & Development
>
> Email: [hidden email]
> Phone: +49 341 49287-700 | Fax: +49 341 49287-01
>
> itCampus Software- und Systemhaus GmbH | a Software AG Company
> Nonnenstrasse 37 | 04229 Leipzig | Germany | http://www.itcampus.de
> Amtsgericht Leipzig HRB 15872 | Managing Director: Guido Laures
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: [hidden email] [mailto:[hidden email]] Im
> Auftrag von Friedman-Hill, Ernest
> Gesendet: Dienstag, 18. Dezember 2012 19:50
> An: jess-users
> Betreff: Re: JESS: [EXTERNAL] Jess in a multithreaded environment
>
> Are you adding non-value classes to the list yourself, or is this just with
> the small number of default listings?
>
> This method will get called when you evaluate the hash code of a Java object
> in the Rete memory; this will happen often during pattern matching. There's
> actually enough room to cache the hash code in the members of the Value
> class that are unused for Java object values, so we could try that as a
> performance improvement.  Do you have a source license, so I could send you
> a patch to try?
>
> From: <Nguyen>, Son Nguyen
> <[hidden email]<mailto:[hidden email]>>
> Reply-To: jess-users
> <[hidden email]<mailto:[hidden email]>>
> Date: Thursday, December 13, 2012 11:04 AM
> To: jess-users
> <[hidden email]<mailto:[hidden email]>>
> Subject: JESS: [EXTERNAL] Jess in a multithreaded environment
>
>
>
> Hi Jess experts,
>
> We use Jess in a multi-threaded environment and have experienced some
> performance degradation when going from a single thread to multiple
> threads.
>
> Our implementation uses the Slot Specific feature.
>
> Using a Java profiler, HashCodeComputer.isValueObject() stood out as one of
> the main contributing factors, if not the most likely,  to the degradation
>
>
>
> --------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [hidden email]'
> in the BODY of a message to [hidden email], NOT to the list
> (use your own address!) List problems? Notify [hidden email].
> --------------------------------------------------------------------
>
>



--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [hidden email]'
in the BODY of a message to [hidden email], NOT to the list
(use your own address!) List problems? Notify [hidden email].
--------------------------------------------------------------------

Reply | Threaded
Open this post in threaded view
|

Re: JESS: [EXTERNAL] Jess in a multithreaded environment

Friedman-Hill, Ernest
Hi Wolfgang,

Jess needs a constant hashcode for any given object, so this mechanism
distinguishes between objects that provide their own constant hashcode and
objects that can't be trusted to do so. The caching I was talking about
would be actually sorting objects into these categories right when the
jess.Value object is created, and storing the (constant) hashcode that was
determined. The only weak point in this is that it would force the user to
establish that a class is a value class before any objects of that type
are referred to.

Another approach would be to use a lock-free container for that list of
classes (i.e., ConcurrentLinkedQueue) which retains that flexibility;
that's what we're actually trying first.


On 1/3/13 12:28 PM, "Wolfgang Laun" <[hidden email]> wrote:

>Warning: I may have misunderstood the issue completely.
>
>If there is a list (or any other collection) maintaining the set of
>value classes, it stands to reason that it is synchronized for use in
>a multithreaded environment, and the contention for its lock may very
>well cause a performance hit.  If a lookup using this list is
>necessary for distinguishing between constant and non-constant hash
>codes, I don't see how caching a constant hash code may improve the
>situation.
>
>-W
>
>
>On 03/01/2013, Henschel, Joerg <[hidden email]> wrote:
>> Yes, we (Software AG) have a source license, so it'd be great if you
>>could
>> provide a patch for this.
>>
>> Thanks!
>>
>> Jörg Henschel
>> Director Research & Development
>>
>> Email: [hidden email]
>> Phone: +49 341 49287-700 | Fax: +49 341 49287-01
>>
>> itCampus Software- und Systemhaus GmbH | a Software AG Company
>> Nonnenstrasse 37 | 04229 Leipzig | Germany | http://www.itcampus.de
>> Amtsgericht Leipzig HRB 15872 | Managing Director: Guido Laures
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: [hidden email] [mailto:[hidden email]] Im
>> Auftrag von Friedman-Hill, Ernest
>> Gesendet: Dienstag, 18. Dezember 2012 19:50
>> An: jess-users
>> Betreff: Re: JESS: [EXTERNAL] Jess in a multithreaded environment
>>
>> Are you adding non-value classes to the list yourself, or is this just
>>with
>> the small number of default listings?
>>
>> This method will get called when you evaluate the hash code of a Java
>>object
>> in the Rete memory; this will happen often during pattern matching.
>>There's
>> actually enough room to cache the hash code in the members of the Value
>> class that are unused for Java object values, so we could try that as a
>> performance improvement.  Do you have a source license, so I could send
>>you
>> a patch to try?
>>
>> From: <Nguyen>, Son Nguyen
>> <[hidden email]<mailto:[hidden email]>>
>> Reply-To: jess-users
>> <[hidden email]<mailto:[hidden email]>>
>> Date: Thursday, December 13, 2012 11:04 AM
>> To: jess-users
>> <[hidden email]<mailto:[hidden email]>>
>> Subject: JESS: [EXTERNAL] Jess in a multithreaded environment
>>
>>
>>
>> Hi Jess experts,
>>
>> We use Jess in a multi-threaded environment and have experienced some
>> performance degradation when going from a single thread to multiple
>> threads.
>>
>> Our implementation uses the Slot Specific feature.
>>
>> Using a Java profiler, HashCodeComputer.isValueObject() stood out as
>>one of
>> the main contributing factors, if not the most likely,  to the
>>degradation
>>
>>
>>
>> --------------------------------------------------------------------
>> To unsubscribe, send the words 'unsubscribe jess-users [hidden email]'
>> in the BODY of a message to [hidden email], NOT to the list
>> (use your own address!) List problems? Notify
>>[hidden email].
>> --------------------------------------------------------------------
>>
>>
>
>
>
>--------------------------------------------------------------------
>To unsubscribe, send the words 'unsubscribe jess-users [hidden email]'
>in the BODY of a message to [hidden email], NOT to the list
>(use your own address!) List problems? Notify [hidden email].
>--------------------------------------------------------------------



--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [hidden email]'
in the BODY of a message to [hidden email], NOT to the list
(use your own address!) List problems? Notify [hidden email].
--------------------------------------------------------------------