Christian Seiler-3 wrote: > > On Fri, Dec 19, 2008 at 6:26 AM, Charles Oliver Nutter < > charles.nut...@sun.com> wrote: > >> avishek.dasgupta wrote: >> >>> >>> Charles Oliver Nutter-2 wrote: >>> >>>> Interesting numbers...I think we need more information, however, like >>>> what version of JRuby you ran and a short description of how the >>>> application >>>> works. There have been threading-related bottlenecks reported over >>>> time, but >>>> we've solved many of those issues. >>>> >>>> Also 1.1.6 is coming out today, which includes a number of these fixes. >>>> >>>> - Charlie >>>> >>>> >>> The JRuby version I used was 1.1.5 with Java 6 >>> Additional VM arguments used were: >>> -Xmx768M -Xms768M -Djruby.objectspace.enabled=false >>> -Djruby.thread.pooling=true >>> >>> I got JRuby 1.1.6 and ran the application again and got these numbers: >>> Threads JRuby Java >>> ======================= >>> 5 41.62 31.20 >>> 10 77.04 31.45 >>> 15 103.14 31.45 >>> 20 126.24 31.41 >>> 25 173.93 32.17 >>> >> >> Ok, so there's improvement, but it still degrades pretty severely. If >> possible, can you also try running with -Djruby.compile.fastest=true? It >> may >> not work, but it does remove some overhead (highly experimental). >> >> If I were to venture a guess, it's possible there's lock contention >> slowing >> things down (lost of concurrent lookups to synchronized resources >> somewhere? >> probably relating to the Java objects antering the system?) or we've got >> a >> single piece of data being mutated rapidly across threads (we found a >> similar issue where a single static int was being incremented rapidly by >> different threads, causing cache flushes to kill performance). We need to >> put the clamps on your app and see what we can find... >> >> - Charlie >> > > Just another guess: Maybe GC slows things down? Have you tried parallel > GC? > > The numbers with -Djruby.compile.fastest=true are as follows: The numbers in braces are after setting -Djruby.compile.fastest=true AND enabling parallel GC (-XX:+UseParallelGC -Xmx768M -Xms768M -Xmn512M)
Threads JRuby Java ======================= 5 38.44(34.08) 31.30(31.90) 10 63.58(60.78) 31.52(31.20) 15 101.45(92.00) 31.57(31.44) 20 118.27(115.24) 31.52(31.56) 25 168.24(132.74) 32.36(32.22) Surely there is improvement after enabling compile.fastest and enabling parallel GC. On an average there seems to be an improvement of about 16% if we compare with the previous data I checked the code again and there seems to be no shared resource which needs to be synchronized. No shared data is being mutated by the threads. Each thread gets a string (the same string) and uses it to get the numbers and adds them. The string itself is never changed. To rule out the possibility, that a single TaskFactory instance being used by all the threads, is becoming the bottleneck, I ran it again with the code modified so that each thread gets a separate TaskFactory (all TaskFactories created earlier and not included in the timings). There was no observable difference in the numbers after this change. The TaskFactory just creates (instantiates) a new task. So, there should be no need of synchronization. I would like to mention here, (if you have not seen the code) that the ruby code is run through Java using the JRubyScriptEngine. I am trying to modify the app and run it through JRuby command line. Will post the results when that's done. However, even if JRuby command line is comparable to Java, it will not really help me as I want it to run under Tomcat using the JRubyScriptEngine -- View this message in context: http://www.nabble.com/Major-performance-slowdown-while-multithreading-%28Java-Vs-JRuby%29-tp21053077p21091568.html Sent from the JRuby - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
