pso
Joined 19 years ago
Joined 19 years ago
Which countries in Europe charge their electricity to consumers based on 'extreme peaks' at between 60 to 100 cents? https://ec.europa.eu/eurostat/statistics-explained/index.php...
So the only pawn that was offered and that Rowson took was on move 10 in reply.
The only reason I checked was to see how far a grandmaster was looking ahead, in this case 14 moves, which i find impressive. "...I discovered a surprising detail right at the end of the line, in which my knight could retreat back to its original square, "
Like you, I wouldn't be impressed if he only saw from move 18 to move 24.
The final graph shows a binary trees program in C, with a 6% variation between "in process executions", and no steady state, it seems logical that most VMs will show the same or worse variation.
The "warmed-up steady state" does exist, but not if they define it so narrowly. All of their iterations and timings are running at x30 to x100 interpreted speed, the only 'cold' interpreted code is in a few microseconds of the first loops of an execution.
All of the warmup, and transitions from interpreter, to JIT, to optimised JIT , happen inside the first few micro or milliseconds of EVERY one of their thousands of process iteration. Their measurements are ALL of the system variation of the VM after warm up has taken place. The VM is optimizing within the first 1-1000 inner loops occuring at the start of EACH process iteration. For most working programmers, a variation of a few percent on a running system AFTER warm-up in "steady-state peak performance", and before any I/O takes place (because language benchmarks avoid I/O), would not be an issue. If it is an issue, then the article perhaps demonstrates that a compiled language would offer less variation.
The benchmarks listed range from a shortest of around 0.4s for fannkuch/hotspot/linux, up to 1.8s for n-body, pypy, linux. This 'long-running' benchmark code (of .4 to 1.8s ), by definition, has to include multiple inner loops/hot code, which is quickly optimized, otherwise benchmark code would have to be millions of lines long, in order to have a sufficient runtime length. Tests need to run for at least tenths of a second, for cross language comparisons, since JITted languages take some iterations to warm-up.
They don't ship minified javascript to final app, but bytecode, which they say is 1/3 smaller (both minified). They have moved the parse and compile stages to ahead of time, making the VM smaller, and giving the bytecode benefit. The bytecode benefit also means a quicker time to live/first reponse from 4s to 2s in their example.
Link to the talk, from FB employee announcement made at React Conference today, 15 minutes length. Linked 2 mins in, because the audio is poor to start.