<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Thanks<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 26 avr. 2019 à 01:15, Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">70ns difference can easily come from cache misses. I think you'd get <br>
more consistent results if you compiled a method and ran that instead of <br>
compiling a new block for each execution.<br>
<br>
The first two numbers are larger because the jit kicks in. IIRC no jit for <br>
the first run, jitting during the second run. All futher executions use <br>
the jitted code.<br></blockquote><div><br></div><div>Yes, it makes sense <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also, the "hickups" probably happen because your OS is running other <br>
processes as well.<br>
<br>
IIRC the highResClock primitive uses TSC on Intel CPUs, so it may not be <br>
as reliable as you'd expect it to be[1], especially on older CPUs (clock <br>
rate depends on CPU frequency, cores' clocks are not synced).<br>
<br></blockquote><div>Yes, constant rate was the first question that came to my mind.</div><div>But it's not really a problem: having the number of ticks is a good information per se, whatever the power saving, it tells how many cycles we use<br></div><div>More problematic is un-synced drifting TSC on multi-core, because diffing makes no sense then if ever affinity changes...</div><div>I suggest making it a Preference (inbox).</div><div><br></div><div>Normally, the best feature of TSC is that they have very cheap access.</div><div>Unfortunately, t's not that cheap thru the primitive.</div><div>I re-ran today:</div><div><br>[Time utcMicrosecondClock] bench.<br> '20,500,000 per second. 48.7 nanoseconds per run.'<br>[Time highResClock] bench.<br> '22,800,000 per second. 43.8 nanoseconds per run.'</div><div><br></div><div>and <br></div><div>(1 to: 200) collect: [:i | Time highResClock - Time highResClock * 1000000 // Time highResClockTicksPerMillisecond]<br> #(-5479 -203 -45 -41 -36 -39 -38 -38 -41 -41 -39 -42 -41 -41 -41 -41 -39 -41 -39 -41 -39 -39 -38 -39 -41 -38 -41 -41 -41 -41 -41 -41 -39 -41 -41 -39 -39 -41 -41 -39 -43 -43 -39 -36 -36 -39 -38 -38 -38 -36 -35 -36 -35 -35 -35 -35 -35 -36 -36 -35 -35 -35 -36 -35 -36 -35 -35 -36 -35 -35 -35 -35 -36 -35 -36 -35 -36 -35 -36 -35 -35 -36 -36 -35 -36 -35 -36 -35 -36 -36 -35 -35 -36 -35 -36 -36 -35 -35 -35 -36 -35 -35 -35 -35 -38 -36 -35 -36 -35 -35 -35 -35 -35 -36 -36 -35 -35 -35 -36 -35 -36 -36 -35 -36 -35 -35 -35 -35 -36 -35 -36 -35 -36 -35 -36 -35 -35 -36 -36 -35 -36 -35 -36 -35 -36 -36 -35 -35 -36 -36 -36 -36 -35 -35 -35 -35 -36 -35 -36 -35 -36 -36 -36 -35 -35 -36 -35 -35 -35 -36 -36 -35 -35 -35 -36 -35 -36 -36 -35 -36 -35 -35 -35 -35 -36 -35 -36 -35 -36 -35 -36 -35 -35 -36 -36 -35 -36 -35 -36 -35)</div><div><br></div><div>which is somehow consistent</div><div><br></div><div>The utcMicrosecondsClock is very poor on windows VM (1 ms resolution).<br></div><div>So maybe the high res clock can still be an interesting add-on...</div><div><br></div><div>
Levente<br>
<br>
[1] <a href="https://en.wikipedia.org/wiki/Time_Stamp_Counter" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Time_Stamp_Counter</a><br>
<br>
On Fri, 26 Apr 2019, Nicolas Cellier wrote:<br>
<br>
> Huh, in fact it's a bit different...<br>
> <br>
> Le jeu. 25 avr. 2019 à 23:28, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br>
> <br>
> <br>
> Le jeu. 25 avr. 2019 à 23:22, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br>
>       Hi,<br>
> I recently published a Chronology-Core version for using high resolution clock.<br>
> <br>
> On my 2.7GHz core i5 MBP (2015) I get this:<br>
> <br>
> Time highResClockTicksPerMillisecond<br>
> <br>
>  2699824<br>
> => OK, consistent with 2.7GHz<br>
> <br>
> Time highResClock - Time highResClock * 1000000 // Time highResClockTicksPerMillisecond.<br>
> <br>
>  -578 -563<br>
> => Huh, invoking a primitive takes that long (500 to 600 nanoseconds)<br>
> <br>
> <br>
> <br>
> (1 to: 200) collect: [:i | Time highResClock - Time highResClock * 1000000 // Time highResClockTicksPerMillisecond].<br>
> <br>
>  #(-528 -96 -71 -61 -63 -61 -61 -61 -63 -61 -58 -61 -61 -61 -61 -61 -58 -58 -61 -57 -61 -58 -63 -61 -61 -61 -61 -61 -61 -63 -61 -61 -61 -61 -61 -61 -61 -58 -61 -61 -61 -61 -61 -63 -61 -61 -61 -61 -61 -61 -61 -61 -61 -64 -58<br>
> -63 -61 -58 -61 -58 -61 -61 -61 -57 -61 -61 -58 -61 -61 -61 -58 -61 -61 -61 -61 -61 -61 -58 -61 -61 -61 -61 -61 -65 -61 -61 -61 -61 -61 -61 -61 -61 -61 -61 -61 -61 -61 -63 -61 -58 -61 -58 -61 -58 -63 -61 -61 -61 -61 -61 -61<br>
> -63 -61 -58 -61 -57 -61 -58 -61 -58 -61 -61 -61 -61 -61 -61 -61 -61 -61 -61 -61 -61 -61 -57 -61 -61 -61 -61 -61 -61 -61 -61 -61 -61 -61 -61 -61 -58 -61 -61 -61 -61 -61 -61 -61 -61 -61 -61 -63 -61 -63 -61 -58 -61 -57 -61 -61<br>
> -61 -61 -58 -61 -58 -63 -57 -61 -58 -61 -61 -58 -63 -58 -63 -58 -58 -61 -61 -61 -61 -63 -61 -58 -61 -58 -61 -61 -61 -61 -57 -61 -58)<br>
> In fact it's 500ns at first eval (JIT or something), then it's only 60ns.<br>
> <br>
><br>
>             But I can correct it. Let's try it:<br>
> <br>
> [10 factorial] bench.<br>
> <br>
>  '14,000,000 per second. 71.2 microseconds per run.'<br>
> => this is the reference result<br>
> <br>
> Huh, I messed up with printing the timing (because I modified benchFor: using µsec clock)<br>
> <br>
> [10 factorial] bench.<br>
>  '14,500,000 per second. 69 nanoseconds per run.'<br>
> <br>
> [] bench.<br>
>  '191,000,000 per second. 5.25 nanoseconds per run.'<br>
> <br>
> So this is including 5ns for evaluating block + incrementing counter + looping...<br>
> <br>
> tmp := [].<br>
> (1 to: 50) collect: [:i || ticks |<br>
> ticks := Time highResClock.<br>
> tmp value.<br>
> Time highResClock - ticks + (Time highResClock - Time highResClock) * 1000000 // Time highResClockTicksPerMillisecond].<br>
> <br>
>  #(1020 54 14 11 4 4 4 4 2 5 1 2 4 4 2 4 5 2 4 2 2 5 2 2 2 4 4 4 5 4 4 4 4 2 5 4 4 4 2 0 5 2 5 4 5 5 4 4 4 4)<br>
> => it's about 5ns but here we are in the noise of correction (it varies between 57 and 63ns as we saw above)<br>
> That's the limit os single evaluation with µ-bench<br>
> <br>
> | tmp |<br>
> tmp := [10 factorial].<br>
> (1 to: 200) collect: [:i || ticks |<br>
> ticks := Time highResClock.<br>
> tmp value.<br>
> Time highResClock - ticks + (Time highResClock - Time highResClock) * 1000000 // Time highResClockTicksPerMillisecond].<br>
> <br>
> | tmp |<br>
> tmp := [10 factorial].<br>
> (1 to: 100) collect: [:i || ticks |<br>
> ticks := Time highResClock.<br>
> tmp value.<br>
> Time highResClock - ticks + (Time highResClock - Time highResClock) * 1000000 // Time highResClockTicksPerMillisecond].<br>
> <br>
>  #(3227 267 212 161 130 125 130 127 127 126 127 126 125 133 124 130 125 128 125 130 127 125 126 127 128 127 130 127 130 127 130 124 125 124 125 126 124 126 124 131 127 132 125 130 124 130 124 130 126 124 128 126 130 126 130<br>
> 127 131 126 130 125 124 125 124 127 125 127 125 130 127 133 124 130 125 128 127 125 122 130 124 127 126 124 128 124 130 123 130 124 130 126 130 124 127 128 127 128 124 130 125 130)<br>
>  #(1663 208 97 94 96 118 97 94 94 94 96 94 93 93 94 93 94 93 93 94 94 93 93 96 93 94 93 94 91 94 93 93 94 93 94 94 93 93 96 94 93 93 94 91 93 93 94 93 93 94 94 93 93 94 93 94 91 93 91 77 94 93 94 94 93 93 96 94 93 93 94 91 93<br>
> 93 94 93 93 94 94 93 93 94 93 94 91 93 91 77 77 93 93 77 80 94 80 94 93 93 94 91)<br>
> <br>
> two regimes again... and not the 70ns of bench this time...<br>
> <br>
> <br>
> (1 to: 10) collect: [:i |<br>
>     | ticks |<br>
>     ticks := Time highResClock.<br>
>     10 factorial.<br>
>     Time highResClock - ticks +<br>
> <br>
> sorry for the extra +, editing code in mail and not doing it is a recipe for not validating!<br>
>           + (Time highResClock - Time highResClock) "correction"<br>
>     * 1000000 // Time highResClockTicksPerMillisecond "get nanoseconds"].<br>
> <br>
>  #(1309 247 88 84 74 69 71 71 71 69)<br>
> => OK, first runs are a bit long, but we get 70ns per run as the reference<br>
> <br>
>  #(1977 191 143 148 142 120 122 122 117 120)<br>
> => Oups??? Second run gives different results???<br>
> <br>
>  #(2239 180 143 143 142 116 117 117 117 114)<br>
> => and third about the same than second...<br>
> Any idea how to explain that?<br>
> <br>
> <br>
> If I run 200 times, I sometimes get the two regimes separated by hickups<br>
> <br>
>  #(1899 107 142 150 123 124 115 122 117 122 118 120 120 120 120 120 121 120 118 120 120 120 120 120 121 120 118 120 120 120 120 120 121 120 118 120 120 120 120 120 121 120 118 120 120 123 117 122 117 122 116 122 117 123<br>
> 117 122 117 122 7950 128 117 122 120 118 9963 87 69 71 69 71 69 69 71 71 68 69 72 71 68 69 72 71 68 69 72 71 68 69 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69<br>
> 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 72 71 68 69 72 71 68 69 69 71 69 71 69 71 68 69 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71 69 71<br>
> 69 71 69 71)<br>
> <br>
> <br>
><br>
</div></div></div></div></div></div>