Le jeudi 11 décembre 2014 à 21:14 -0800, Iain Dunning a écrit : > I'm imagine its something like the following pattern: > > > Run 1: generate X garbage > Run 2: generate X garbage, for total 2X garbage, which is over > threshold, reduce back to 0 > Run 3: generate X garbage > Run 4: generate X garbage, for total 2X garbage, which is over > threshold, reduce back to 0 > and so on I'm no expert on this field either, but this is probably a pattern that can be made to give more consistent timings by the generational gc work: https://github.com/JuliaLang/julia/pull/8699
If you're building from git master you can easily build this branch and test it if you want. They're precisely looking for benchmarks. Regards > On Friday, December 12, 2014 12:09:19 AM UTC-5, Sean McBane wrote: > Alright. I am curious now as to what causes this behavior; > hopefully someone will offer an explanation. > > I'll be sure to from now on. > > -- Sean > > On Thursday, December 11, 2014 11:07:07 PM UTC-6, John Myles > White wrote: > This is just how the GC works. Someone who's done more > work on the GC can give you more context about why the > GC runs for the length of time it runs for at each > specific moment that it starts going. > > As a favor to me, can you please make sure that you > quote the entire e-mail thread you're responding to? I > find responding to e-mails without context to be > pretty jarring. > > -- John > > On Dec 12, 2014, at 12:04 AM, Sean McBane > <[email protected]> wrote: > > > Right, I know I'm allocating it and discarding > memory. However, if the GC cleans up at deterministic > points in time, as you point out in your first reply, > why is timing erratic? And why the regular pattern in > timing? It's always faster one call, slower one call, > faster one call, slower one call... >
