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

2013-01-03 Thread 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: j.hensc...@itcampus.de
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: owner-jess-us...@sandia.gov [mailto:owner-jess-us...@sandia.gov] 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 
son.ngu...@softwareag.commailto:son.ngu...@softwareag.com
Reply-To: jess-users 
jess-us...@mailgate.sandia.govmailto:jess-us...@mailgate.sandia.gov
Date: Thursday, December 13, 2012 11:04 AM
To: jess-users 
jess-us...@mailgate.sandia.govmailto:jess-us...@mailgate.sandia.gov
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 y...@address.com'
in the BODY of a message to majord...@sandia.gov, NOT to the list
(use your own address!) List problems? Notify owner-jess-us...@sandia.gov.




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

2013-01-03 Thread Wolfgang Laun
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 j.hensc...@itcampus.de 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: j.hensc...@itcampus.de
 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: owner-jess-us...@sandia.gov [mailto:owner-jess-us...@sandia.gov] 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
 son.ngu...@softwareag.commailto:son.ngu...@softwareag.com
 Reply-To: jess-users
 jess-us...@mailgate.sandia.govmailto:jess-us...@mailgate.sandia.gov
 Date: Thursday, December 13, 2012 11:04 AM
 To: jess-users
 jess-us...@mailgate.sandia.govmailto:jess-us...@mailgate.sandia.gov
 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 y...@address.com'
 in the BODY of a message to majord...@sandia.gov, NOT to the list
 (use your own address!) List problems? Notify owner-jess-us...@sandia.gov.
 






To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
in the BODY of a message to majord...@sandia.gov, NOT to the list
(use your own address!) List problems? Notify owner-jess-us...@sandia.gov.




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

2013-01-03 Thread 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 wolfgang.l...@gmail.com 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 j.hensc...@itcampus.de 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: j.hensc...@itcampus.de
 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: owner-jess-us...@sandia.gov [mailto:owner-jess-us...@sandia.gov] 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
 son.ngu...@softwareag.commailto:son.ngu...@softwareag.com
 Reply-To: jess-users
 jess-us...@mailgate.sandia.govmailto:jess-us...@mailgate.sandia.gov
 Date: Thursday, December 13, 2012 11:04 AM
 To: jess-users
 jess-us...@mailgate.sandia.govmailto:jess-us...@mailgate.sandia.gov
 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 y...@address.com'
 in the BODY of a message to majord...@sandia.gov, NOT to the list
 (use your own address!) List problems? Notify
owner-jess-us...@sandia.gov.
 






To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
in the BODY of a message to majord...@sandia.gov, NOT to the list
(use your own address!) List problems? Notify owner-jess-us...@sandia.gov.





To unsubscribe, send the words 'unsubscribe jess-users y...@address.com'
in the BODY of a message to majord...@sandia.gov, NOT to the list
(use your own address!) List problems? Notify owner-jess-us...@sandia.gov.




JESS: [EXTERNAL] Jess in a multithreaded environment

2012-12-18 Thread Nguyen, Son

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


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

2012-12-18 Thread 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 
son.ngu...@softwareag.commailto:son.ngu...@softwareag.com
Reply-To: jess-users 
jess-us...@mailgate.sandia.govmailto:jess-us...@mailgate.sandia.gov
Date: Thursday, December 13, 2012 11:04 AM
To: jess-users 
jess-us...@mailgate.sandia.govmailto:jess-us...@mailgate.sandia.gov
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