On Fri, Feb 27, 2015 at 10:36 PM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> Dmitry, > > >> That's not to say there's anything wrong with this approach, nor that > >> there isn't a ton we can learn from it. I think it's a fantastic > >> research effort and plan on digging through it myself. Thank you for > >> open sourcing it. > > > > > > Thanks for good words :) > > > > This work may be adopted for some specific cases. > > 25-30 times speedup on Mandelbrot allows usage for numeric calculation > > instead of C. > > > > https://gist.github.com/dstogov/12323ad13d3240aee8f1 > > > > anyone may repeat the language battle :) > > These tests seem really odd. A 15% speed advantage over GCC -O2? Sure, > it's possible. But I don't think it's likely. It really smells to me > like bias in the testing methodology. (and the lack of an -O3 result > is suspicious as well). > No. it true, but of course it's not 100% fair. gcc compiles files for x86 or x86_64 platform in general. When we compile in run-time we may relay on knowledge of our CPU. In this case LLVM generates AVX instructions, while gcc SSE2. Looking into assembler code, you may see that PHP even not inferred type of all variables and makes few unnecessary check in the loop, but modern CPU are so smart that the code looking mach worse work with the same speed as (gcc -O2). Unfortunately it works in the other direction as well. gcc -O2 -mavx will outperform us :) > > And looking at the code, I can see why. The PHP version is writing to > an internal buffer, while every other version has to write to STDOUT > on every single iteration. > > So you are intentionally not benchmarking the output in the PHP > version (you even explicitly call ob_start()) but are benchmarking it > in every other version. So in fact, the PHP code does something > different than the rest of the code. > > Sneaky sneaky. Also completely fake. A proper methodology would have > explicitly disabled any buffer so that the tests all tested the same > thing. Or even better, build up an internal buffer in all of the > implementations. That way you can compare the computation and not rely > on STDOUT (terminal) response. > this also may make some difference, but I think PHP stream layer is not as good as C. just profile it with Linux perf, oprofile, callgrind, ... perf record <command> perf report -n Thanks. Dmitry > > Anthony >
