Hacker News Reader

Comment by toolslive | Hacker News Reader

| php is fast.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

it's faster than python, but my grandma is too and she died in 1993. However, function calls are extremely slow. If you would bench something like a naieve fibonacci implementation (or ackermann's function) you would be surprised.

View on HN

(naieve fibonacci) like this:

    <?php
    
    function fib($n) 
    {
        if($n === 0) { return 1;}
        if($n === 1) { return 1;}
        $r = fib($n-1) + fib($n-2);
        return $r;
    }
    

    $n= (int) $argv[1];
    $r = fib($n);
    printf("%d %d\n",$n,$r);

just did some measurements on my laptop:

    | Language             |  n | time(s) |
    |----------------------+----+---------|
    | php (7.4.25)         | 42 |   422.0 |
    | python3              | 42 |    90.0 |
    | haskell (ghc -O3)    | 42 |    13.8 |
    | f#                   | 42 |     5.6 |
    | ts                   | 42 |     2.8 |
    | ocaml (ocamlopt -O3) | 42 |    0.98 |
    | C (gcc -O3)          | 42 |    0.66 |

(edit: added php version in table. )

Is JIT enabled and configured for PHP?

naieve and micro benchmarks is not meaningful in 95% of cases. Did you run on the CLI with -dopcache.enable_cli=1 for example?

Opcache avoids the compilation step. It's not relevant in this case (compilation ~0.01s out of ~400s).

Microbenchmarks are meaningful as long as one doesn't read too much from them. This benchmark shows that PHP seems to have a problem with recurrent calls.

that was PHP 7.4.25

Yes this is a microbenchmark. Yes, I know binet's formula... Yes it's weird function calls are so slow in php.

with php 8.0 (jit enabled) you get something like 120s (for n= 42)

This is what I get locally:

    time php fib.php 42
    23s

    time python3 fib.py 42
    1m1s

I suspect that you're doing something very wrong, like running PHP with an active debugger or similar.

If we're talking in comparison to slow interpreted languages like Python, then function calls in PHP are not particularly expensive. Debuggers can make them quite expensive though.

Edit: Just to note, PHP's execution time drops to 4s with enabled JIT.

I also get around 23s, PHP 7.4.5

Likely. I tried the benchmark and saw runtimes of over 5 minutes before realizing that XDebug was active and in develop mode. Adding `-d xdebug.mode=off` dropped it to 26s. That was with `opcache.jit` in the (default?) `tracing` mode. Turning it off didn't change the runtime, which is a bit puzzling. This is all with PHP8 on macOS, although I tried 8.1RC in docker and saw similar results.

Something doesn't quite add up across everyone's results here, but the extremely slow result at the top of the thread is almost certainly a debugger slowing things down.

Edit: I was missing `opcache.jit_buffer_size`, and saw the runtime drop to under ten seconds with that correctly configured.

How is php 422 seconds? Are you basing that off the return value of the function? FWIW, I get 57 seconds when I run your function with PHP 7.4 using microtime().

Is that still true when using PHP 8.0 with JIT enabled?

https://twitter.com/ArkadiuszKondas/status/11196548025800212...

Was curious. The same implementation as /u/toolslive:

  PHP 8.0.12:
  
  $ time php fib.php 42
  42 433494437
  
  real 0m29.274s
  user 0m29.003s
  sys 0m0.105s

  $ time php -dopcache.enable_cli=1 fib.php 42
  42 433494437

  real 0m26.341s
  user 0m26.179s
  sys 0m0.058s
  ----------------------------------------
  PHP 7.3.5:
  $ time php fib.php 42
  42 433494437

  real 10m23.573s
  user 10m16.592s
  sys 0m1.828s
  ----------------------------------------
  Settings for PHP 8:
  PHP Version => 8.0.12
  auto_globals_jit => On => On
  pcre.jit => 1 => 1
  opcache.jit => tracing => tracing
  opcache.jit_bisect_limit => 0 => 0
  opcache.jit_blacklist_root_trace => 16 => 16
  opcache.jit_blacklist_side_trace => 8 => 8
  opcache.jit_buffer_size => 0 => 0
  opcache.jit_debug => 0 => 0
  opcache.jit_hot_func => 127 => 127
  opcache.jit_hot_loop => 64 => 64
  opcache.jit_hot_return => 8 => 8
  opcache.jit_hot_side_exit => 8 => 8
  opcache.jit_max_exit_counters => 8192 => 8192
  opcache.jit_max_loop_unrolls => 8 => 8
  opcache.jit_max_polymorphic_calls => 2 => 2
  opcache.jit_max_recursive_calls => 2 => 2
  opcache.jit_max_recursive_returns => 2 => 2
  opcache.jit_max_root_traces => 1024 => 1024
  opcache.jit_max_side_traces => 128 => 128
  opcache.jit_prof_threshold => 0.005 => 0.005

I have stopped trusting the aforementioned link because they play dirty games with benchmarks, most of the times.

Let me give you an example;

  https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-python3-2.html

and

  https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-perl-4.html

The Python code uses ctypes, thus the unfair marginal difference.

I have seen the same unjust comparison with the majority of the examples and decided to stop relying on this page for validating programming language performance.

> … because they play dirty games with benchmarks, most of the times

No they do not.

Let me give you an example:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

*** You ignored the Python code that does not use ctypes.

> I have seen the same unjust comparison with the majority of the examples…

No you have not.

There are 10 different tasks.

pidigits accepts the use of third-party libraries (GMP)

regex-redux accepts the use of third-party libraries (PCRE)

That's 2 out of 10.

Reply on news.ycombinator.com