As promised earlier...here's the benchmark run on a 4-core machine:

mac-pro:/tmp # java -server test/RandomTest
Testing with 1 threads for 5 seconds
Generated 24,444,033 random ints using seed-many method
Generated 76,199,951 random ints using seed-once method
====================
Testing with 5 threads for 5 seconds
Generated 20,954,069 random ints using seed-many method
Generated 10,676,258 random ints using seed-once method
====================
Testing with 10 threads for 5 seconds
Generated 21,374,108 random ints using seed-many method
Generated 12,335,188 random ints using seed-once method
====================
Testing with 25 threads for 5 seconds
Generated 21,260,296 random ints using seed-many method
Generated 13,003,979 random ints using seed-once method
====================
Testing with 50 threads for 5 seconds
Generated 19,892,929 random ints using seed-many method
Generated 13,041,522 random ints using seed-once method
====================

-t

On Apr 4, 2007, at 7:28 AM, Tim Fennell wrote:

> Wheeee.  I'm gonna regret ever asking that question about sync'ing on
> the Random in the first place ;)
>
> I'm not sure why the number jump around for the seed-many method.
> The best I could explain is that perhaps the hotspot compiler is
> jumping in at some unpredictable point and compiling the insides of
> various loops in the micro-benchmark.  That would certainly explain
> why things speed up between the 1 and 5 thread runs.  With the Sun
> JVM, it doesn't get slower again - but with JRockit it does.  I'm not
> familiar with JRockit enough to even begin to rationalize that ;)
>
> Dmitri: Your Sun JVM numbers make sense to me.  The sync (seed once)
> method is fastest when run single-threaded because all the
> syncronization is uncontended.  At some point when you add more
> threads the contention due to syncrhonization outweighs the benefit
> of not having to seed each time.  So it makes sense to me that the
> seed-many (no sync) method gains relative to the seed-once (sync) as
> you add more threads.
>
> The takeaway for me here is that the sync method is fine, and in any
> Stripes installation will probably outperform the seed-many method.
> Given that this is done once-per-request at a maximum, the chances of
> this synchronization being heavily contended over time are minute.
> In fact, if it ever gets there, it'd indicate such an awesome amount
> of traffic that I'm sure there'd be bigger issues first ;)
>
> At any rate, and just for completeness/fun, I'll run the benchmark
> code on my work machine which is a dual-cpu, dual-core (so four total
> cores) and see what happens :)
>
> -t
>
>
> On Apr 4, 2007, at 2:57 AM, Dmitri Colebatch wrote:
>
>> 2MB cache size (full cpuinfo at end of email).  I don't really
>> understand why the numbers are as they are.... I've just run it again
>> with fairly different results:
>>
>> JRockit:
>> Testing with 1 threads for 5 seconds
>> Generated 6,507,020 random ints using seed-many method
>> Generated 71,425,284 random ints using seed-once method
>> ====================
>> Testing with 5 threads for 5 seconds
>> Generated 16,455,525 random ints using seed-many method
>> Generated 36,601,389 random ints using seed-once method
>> ====================
>> Testing with 10 threads for 5 seconds
>> Generated 10,832,130 random ints using seed-many method
>> Generated 33,238,768 random ints using seed-once method
>> ====================
>> Testing with 25 threads for 5 seconds
>> Generated 12,250,530 random ints using seed-many method
>> Generated 15,675,836 random ints using seed-once method
>> ====================
>> Testing with 50 threads for 5 seconds
>> Generated 15,759,831 random ints using seed-many method
>> Generated 15,496,179 random ints using seed-once method
>> ====================
>>
>> Sun:
>>
>> Testing with 1 threads for 5 seconds
>> Generated 5,983,931 random ints using seed-many method
>> Generated 52,035,107 random ints using seed-once method
>> ====================
>> Testing with 5 threads for 5 seconds
>> Generated 16,943,464 random ints using seed-many method
>> Generated 10,462,359 random ints using seed-once method
>> ====================
>> Testing with 10 threads for 5 seconds
>> Generated 17,020,737 random ints using seed-many method
>> Generated 10,650,710 random ints using seed-once method
>> ====================
>> Testing with 25 threads for 5 seconds
>> Generated 17,172,693 random ints using seed-many method
>> Generated 10,710,387 random ints using seed-once method
>> ====================
>> Testing with 50 threads for 5 seconds
>> Generated 17,081,978 random ints using seed-many method
>> Generated 10,803,786 random ints using seed-once method
>> ====================
>>
>> I'm not so convinced that there's not something else running on this
>> box affecting this as we seem to get unexplainable numbers...
>>
>> cheesr,
>> dim
>>
>> ps - I don't actually mind which way you go, do you guys use Random
>> much?
>>
>> [EMAIL PROTECTED] dim]$ cat /proc/cpuinfo
>> processor       : 0
>> vendor_id       : GenuineIntel
>> cpu family      : 15
>> model           : 4
>> model name      :                   Intel(R) Xeon(TM) CPU 3.60GHz
>> stepping        : 3
>> cpu MHz         : 3591.368
>> cache size      : 2048 KB
>> physical id     : 0
>> siblings        : 2
>> core id         : 0
>> cpu cores       : 1
>> fpu             : yes
>> fpu_exception   : yes
>> cpuid level     : 5
>> wp              : yes
>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr  
>> pge
>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm  
>> syscall
>> nx lm pni monitor ds_cpl est tm2 cid cx16 xtpr
>> bogomips        : 7187.20
>> clflush size    : 64
>> cache_alignment : 128
>> address sizes   : 36 bits physical, 48 bits virtual
>> power management:
>>
>> processor       : 1
>> vendor_id       : GenuineIntel
>> cpu family      : 15
>> model           : 4
>> model name      :                   Intel(R) Xeon(TM) CPU 3.60GHz
>> stepping        : 3
>> cpu MHz         : 3591.368
>> cache size      : 2048 KB
>> physical id     : 3
>> siblings        : 2
>> core id         : 3
>> cpu cores       : 1
>> fpu             : yes
>> fpu_exception   : yes
>> cpuid level     : 5
>> wp              : yes
>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr  
>> pge
>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm  
>> syscall
>> nx lm pni monitor ds_cpl est tm2 cid cx16 xtpr
>> bogomips        : 7182.51
>> clflush size    : 64
>> cache_alignment : 128
>> address sizes   : 36 bits physical, 48 bits virtual
>> power management:
>>
>> processor       : 2
>> vendor_id       : GenuineIntel
>> cpu family      : 15
>> model           : 4
>> model name      :                   Intel(R) Xeon(TM) CPU 3.60GHz
>> stepping        : 3
>> cpu MHz         : 3591.368
>> cache size      : 2048 KB
>> physical id     : 0
>> siblings        : 2
>> core id         : 0
>> cpu cores       : 1
>> fpu             : yes
>> fpu_exception   : yes
>> cpuid level     : 5
>> wp              : yes
>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr  
>> pge
>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm  
>> syscall
>> nx lm pni monitor ds_cpl est tm2 cid cx16 xtpr
>> bogomips        : 7182.46
>> clflush size    : 64
>> cache_alignment : 128
>> address sizes   : 36 bits physical, 48 bits virtual
>> power management:
>>
>> processor       : 3
>> vendor_id       : GenuineIntel
>> cpu family      : 15
>> model           : 4
>> model name      :                   Intel(R) Xeon(TM) CPU 3.60GHz
>> stepping        : 3
>> cpu MHz         : 3591.368
>> cache size      : 2048 KB
>> physical id     : 3
>> siblings        : 2
>> core id         : 3
>> cpu cores       : 1
>> fpu             : yes
>> fpu_exception   : yes
>> cpuid level     : 5
>> wp              : yes
>> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr  
>> pge
>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm  
>> syscall
>> nx lm pni monitor ds_cpl est tm2 cid cx16 xtpr
>> bogomips        : 7182.54
>> clflush size    : 64
>> cache_alignment : 128
>> address sizes   : 36 bits physical, 48 bits virtual
>> power management:
>>
>>
>>
>> On 4/4/07, Ben Gunter <[EMAIL PROTECTED]> wrote:
>>> That's odd. I also ran it on a dual Xeon (2.4GHz). For the Windows
>>> test I
>>> ran it on a Core 2 Duo. One difference is I ran it on Java 6 and
>>> you ran it
>>> on Java 5. I can't explain the results. Look how seed-many jumped
>>> from ~6
>>> million to ~17 million from the first run to the second even
>>> though it
>>> should have been doing exactly the same thing both times.
>>>
>>> I just ran it on the same server under Java 5 and got similar
>>> results. Not
>>> sure what's going on. What size is your CPU cache? Mine is 512Kb.
>>> I wonder
>>> if that would have an effect.
>>>
>>>
>>> Dmitri Colebatch wrote:
>>> What hardware are you running that on? Dual CPU might change things.
>> Here's
>>> your code run on our test server (dual xeon Dell 1850).
>>
>> [EMAIL PROTECTED] dim]$
>>> java -version
>> java version "1.5.0_06"
>> Java(TM) 2 Runtime Environment,
>>> Standard Edition (build 1.5.0_06-b05)
>> Java HotSpot(TM) Server VM (build
>>> 1.5.0_06-b05, mixed mode)
>>
>> [EMAIL PROTECTED] dim]$ java RandomTest
>> Testing with 1
>>> threads for 5 seconds
>> Generated 5,963,439 random ints using seed-many
>>> method
>> Generated 51,890,734 random ints using seed-once
>>> method
>> ====================
>> Testing with 5 threads for 5 seconds
>> Generated
>>> 17,021,507 random ints using seed-many method
>> Generated 11,540,379 random
>>> ints using seed-once method
>> ====================
>> Testing with 10 threads for
>>> 5 seconds
>> Generated 17,067,507 random ints using seed-many method
>> Generated
>>> 12,153,002 random ints using seed-once method
>> ====================
>> Testing
>>> with 25 threads for 5 seconds
>> Generated 17,068,201 random ints using
>>> seed-many method
>> Generated 12,252,194 random ints using seed-once
>>> method
>> ====================
>> Testing with 50 threads for 5 seconds
>> Generated
>>> 17,388,417 random ints using seed-many method
>> Generated 11,822,572 random
>>> ints using seed-once method
>> ====================
>>
>> Mind you this changes a
>>> fair bit with JRockit:
>>
>> [EMAIL PROTECTED] dim]$ java -version
>> java version
>>> "1.5.0_06"
>> Java(TM) 2 Runtime Environment, Standard Edition (build
>>> 1.5.0_06-b05)
>> BEA JRockit(R)
>>> (build
>> R26.4.0-63_CR302700-72606-1.5.0_06-20061127-1104-linux-ia32,
>>> )
>>
>> [EMAIL PROTECTED] dim]$ java RandomTest
>> Testing with 1 threads for 5
>>> seconds
>> Generated 6,521,686 random ints using seed-many method
>> Generated
>>> 66,236,407 random ints using seed-once method
>> ====================
>> Testing
>>> with 5 threads for 5 seconds
>> Generated 7,964,427 random ints using seed-many
>>> method
>> Generated 42,309,927 random ints using seed-once
>>> method
>> ====================
>> Testing with 10 threads for 5 seconds
>> Generated
>>> 7,966,630 random ints using seed-many method
>> Generated 17,019,631 random
>>> ints using seed-once method
>> ====================
>> Testing with 25 threads for
>>> 5 seconds
>> Generated 6,153,009 random ints using seed-many method
>> Generated
>>> 20,791,154 random ints using seed-once method
>> ====================
>> Testing
>>> with 50 threads for 5 seconds
>> Generated 15,619,450 random ints using
>>> seed-many method
>> Generated 13,096,026 random ints using seed-once
>>> method
>> ====================
>>
>> I'm not sure if I'm prepared to draw any
>>> conclusions from this - my
>> logic would suggest that more CPUs would mean
>>> less synchronization
>> overhead, and hence better relative performance for
>>> seed-once, however
>> the above shows better performance for seed-many.... what
>>> am I
>> missing?
>>
>> cheers
>> dim
>>
>> On 4/4/07, Ben Gunter <[EMAIL PROTECTED]> wrote:
>>> As a follow-up to the lengthy conversation we had about
>>> java.util.Random
>> and
>>> whether it is best to reuse a single one and synchronize on it or
>> just
>>> create a new one each time, I wrote a program to compare the
>> performance of
>>> the two. Here are the results (CentOS 4.4, JDK 6):
>>
>> Testing with 1 threads
>>> for 5 seconds
>> Generated 1,191,083 random ints using seed-many
>>> method
>> Generated 24,562,853 random ints using seed-once
>>> method
>> ====================
>> Testing with 5 threads for 5 seconds
>> Generated
>>> 1,736,231 random ints using seed-many method
>> Generated 11,417,596 random
>>> ints using seed-once method
>> ====================
>> Testing with 10 threads for
>>> 5 seconds
>> Generated 1,749,759 random ints using seed-many method
>> Generated
>>> 10,706,179 random ints using seed-once method
>> ====================
>> Testing
>>> with 25 threads for 5 seconds
>> Generated 1,727,634 random ints using
>>> seed-many method
>> Generated 10,922,547 random ints using seed-once
>>> method
>> ====================
>> Testing with 50 threads for 5 seconds
>> Generated
>>> 1,732,329 random ints using seed-many method
>> Generated 10,734,163 random
>>> ints using seed-once method
>> ====================
>>
>> The difference was less
>>> pronounced under Windows XP (JDK 6), but
>> seed-once still won:
>>
>> Testing with
>>> 1 threads for 5 seconds
>> Generated 2,335,585 random ints using seed-many
>>> method
>> Generated 45,853,345 random ints using seed-once
>>> method
>> ====================
>> Testing with 5 threads for 5 seconds
>> Generated
>>> 3,290,170 random ints using seed-many method
>> Generated 6,214,038 random ints
>>> using seed-once method
>> ====================
>> Testing with 10 threads for 5
>>> seconds
>> Generated 3,283,141 random ints using seed-many method
>> Generated
>>> 6,706,248 random ints using seed-once method
>> ====================
>> Testing
>>> with 25 threads for 5 seconds
>> Generated 3,258,902 random ints using
>>> seed-many method
>> Generated 6,597,599 random ints using seed-once
>>> method
>> ====================
>> Testing with 50 threads for 5 seconds
>> Generated
>>> 3,244,338 random ints using seed-many method
>> Generated 6,650,498 random ints
>>> using seed-once method
>> ====================
>>
>> The source code is attached. If
>>> I messed up anywhere, please let me
>>> know.
>>
>> -Ben
>>
>>
>> --------------------------------------------------------------------- 
>> -
>> ---
>> Take
>>> Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's
>>> Techsay panel and you'll get the chance to share your
>> opinions on IT &
>>> business topics through brief surveys-and earn
>>> cash
>> http://www.techsay.com/default.php?
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Stripes-development
>>> mailing
>>> list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/stripes-development
>>
>>
>>
>>> -------------------------------------------------------------------- 
>>> -
>>> ----
>> Take
>>> Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's
>>> Techsay panel and you'll get the chance to share your
>> opinions on IT &
>>> business topics through brief surveys-and earn
>>> cash
>> http://www.techsay.com/default.php?
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Stripes-development
>>> mailing
>>> list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/stripes-development
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> ----
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to
>>> share your
>>> opinions on IT & business topics through brief surveys-and earn cash
>>> http://www.techsay.com/default.php?
>>> page=join.php&p=sourceforge&CID=DEVDEV
>>> _______________________________________________
>>> Stripes-development mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/stripes-development
>>>
>>>
>>
>> --------------------------------------------------------------------- 
>> -
>> ---
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Stripes-development mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/stripes-development
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Stripes-development mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-development


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development

Reply via email to