What work is Graal finding?

[masklinn]

I've been adding graal support to a project I maintain, and one thing's been bugging me: even though the benchmarks are completely single threaded, Graal somehow peaks at 400% CPU (this is on an M1 Pro, so 8 P cores and 2 E cores).

I figure GC is probably part of it but 3 cycles of GC per cycle of program seems high even if the bench was ridiculously garbage heavy. And the bench runs for nearly 2 minutes (~110 seconds) so it seems unlikely that the JIT is still JIT-ing at this point, kinda.

I tried running some of the bundled tools, but they (pretty logically) only report my own code, it doesn't really talk about graal's side hustles.

Is there a way to get insight into that?

[qunaibit]

Which version of GraalPy have you tried? release or master?
Which benchmarks have you used?

even though the benchmarks are completely single threaded, Graal somehow peaks at 400% CPU

Background compilation is done on separate threads. You can control the number of threads using the engine options:
https://www.graalvm.org/latest/graalvm-as-a-platform/language-implementation-framework/Options/#expert-engine-options

Is there a way to get insight into that?

In case you haven't looked at:
https://www.graalvm.org/latest/tools/graalvm-insight/manual/#insights-with-python

One additional option you can try --experimental-options --python.ExposeInternalSources=true which will expose internal sources, e.g. standard library

[masklinn]

Which version of GraalPy have you tried? release or master?

24.1.0

Which benchmarks have you used?

The project's benchmark, it's basically a regex-heavy classifier (so a few hundred regexes being run on a bunch of lines to classify and data-extract them, the sample file for the benchmark is ~75000 lines long).

Background compilation is done on separate threads. You can control the number of threads using the engine options: https://www.graalvm.org/latest/graalvm-as-a-platform/language-implementation-framework/Options/#expert-engine-options

Right, but for the innermost statements CPU trace (--cputrace --cputrace.TraceStatements) tells me they're 99%~100% "Compiled Count" so I'd assume it's not background compilation.

Is there a way to get insight into that?

In case you haven't looked at: https://www.graalvm.org/latest/tools/graalvm-insight/manual/#insights-with-python

That seems to be a way to observe the execution of the language right? So similar to the standard cpusample and cputrace tools?

But that accounts for one full core, what I'd like to know (mostly out of curiosity) is what the other 3 are doing.

One additional option you can try --experimental-options --python.ExposeInternalSources=true which will expose internal sources, e.g. standard library

That is definitely useful, as I was pretty sure the time was spent in the stdlib but by default it was completely opaque, it's good to know what I was not completely off the mark at least.

[msimacek]

It's possible that there are still some compilations happening. It could be a bug on our side or you keep creating new code (running eval on changing code, creating new regexes) . You can see those with --experimental-options --engine.TraceCompilation=true

[masklinn]

That makes sense if as you explained on #445 the regexes are JITed lazily. I'll take a look at the compilation tracing. Thanks.