Cleaned up the previous change, removing commented line and all reference to opts.
[packages/random.git] / DEVLOG.md
1
2
3 DEVLOG: A collection of notes accumulated during development.
4 =============================================================
5
6
7 [2011.06.24] (transient) Regression in stdGen performance.
8 ----------------------------------------------------------
9
10 I just added a simple benchmark to make sure that whatever fix I
11 introduce for trac ticket #5133 does not regress performance.  Yet in
12 doing so I discovered that I'm getting much worse performance out of
13 rev 130e421e912d than I'm seeing in my installed random-1.0.0.3 package.
14
15 Current version:
16     How many random numbers can we generate in a second on one thread?
17       Cost of rdtsc (ffi call):    100
18       Approx getCPUTime calls per second: 234,553
19       Approx clock frequency:  3,335,220,196
20       First, timing with System.Random interface:
21          68,550,189 random ints generated [constant zero gen]         ~ 48.65 cycles/int
22             900,889 random ints generated [System.Random stdGen]      ~ 3,702 cycles/int
23
24 random-1.0.0.3 version:
25     How many random numbers can we generate in a second on one thread?
26       Cost of rdtsc (ffi call):    75
27       Approx getCPUTime calls per second: 215,332
28       Approx clock frequency:  3,334,964,738
29       First, timing with System.Random interface:
30          71,683,748 random ints generated [constant zero gen]         ~ 46.52 cycles/int
31          13,609,559 random ints generated [System.Random stdGen]      ~ 245 cycles/int
32
33 A >13X difference!! 
34 Both are compiled with the same options.  The only difference is which
35 System.Random is used.
36
37 When did the regression occur?  
38
39  * e059ed15172585310f9c -- 10/13/2010 perf still good
40  * 6c43f80f48178ac617   -- SplittableGen introduced, still good perf
41  * 130e421e912d394653a4 -- most recent, bad performance
42
43 Ok... this is very odd.  It was a heisenbug becuase it's disappeared
44 now!  I'll leave this note here to help remember to look for it in the
45 future.
46   -Ryan
47
48
49 [2011.06.24] Timing non-int types
50 ---------------------------------
51
52 The results are highly uneven:
53
54     Cost of rdtsc (ffi call):    84
55     Approx getCPUTime calls per second: 220,674
56     Approx clock frequency:  3,336,127,273
57     First, timing with System.Random interface:
58       112,976,933 randoms generated [constant zero gen]         ~ 29.53 cycles/int
59        14,415,176 randoms generated [System.Random stdGen]      ~ 231 cycles/int
60            70,751 randoms generated [System.Random Floats]      ~ 47,153 cycles/int
61            70,685 randoms generated [System.Random CFloats]     ~ 47,197 cycles/int
62         2,511,635 randoms generated [System.Random Doubles]     ~ 1,328 cycles/int
63            70,494 randoms generated [System.Random CDoubles]    ~ 47,325 cycles/int
64           858,012 randoms generated [System.Random Integers]    ~ 3,888 cycles/int
65         4,756,213 randoms generated [System.Random Bools]       ~ 701 cycles/int
66
67 As you can see, all the types that use the generic randomIvalFrac /
68 randomFrac definitions perform badly.  What's more, the above results
69 INCLUDE an attempt to inline:
70
71     {-# INLINE randomIvalFrac #-}
72     {-# INLINE randomFrac #-}
73     {-# INLINE randomIvalDouble #-}
74
75 After reimplementing random/Float these are the new results:
76
77   Cost of rdtsc (ffi call):    100
78   Approx getCPUTime calls per second: 200,582
79   Approx clock frequency:  3,334,891,942
80   First, timing with System.Random interface:
81     105,266,949 randoms generated [constant zero gen]         ~ 31.68 cycles/int
82      13,593,392 randoms generated [System.Random stdGen]      ~ 245 cycles/int
83      10,962,597 randoms generated [System.Random Floats]      ~ 304 cycles/int
84      11,926,573 randoms generated [System.Random CFloats]     ~ 280 cycles/int
85       2,421,520 randoms generated [System.Random Doubles]     ~ 1,377 cycles/int
86       2,535,087 randoms generated [System.Random CDoubles]    ~ 1,315 cycles/int
87         856,276 randoms generated [System.Random Integers]    ~ 3,895 cycles/int
88       4,976,373 randoms generated [System.Random Bools]       ~ 670 cycles/int
89
90 (But I still need to propagate these changes throughout all types / API calls.)
91
92
93
94 [2011.06.28] Integer Generation via random and randomR
95 -------------------------------------------------------
96
97 Back on the master branch I notice that while randomIvalInteger does
98 well for small ranges, it's advantage doesn't scale to larger ranges:
99
100   range (-100,100):
101       5,105,290 randoms generated [System.Random Integers]    ~ 653 cycles/int
102
103   range (0,2^5000):
104           8,969 randoms generated [System.Random BIG Integers] ~ 371,848 cycles/int
105