LuaJIT 2.1 Profiler released(permalink.gmane.org) |
LuaJIT 2.1 Profiler released(permalink.gmane.org) |
Mike Pall needs several Jolt Awards.
Now does Mike have any kids? Start pointing them in the direction of Rust, por favor :)
As you might have noticed, I had to change my plans compared to the original approach presented in June. The main problem with the instrumenting profiler was finding high-precision and high-speed timing sources for all platforms. (...) The necessary pipeline flushes shadowed the actual timings up to the point where the measurements were less accurate than with a sampling profiler! Other platforms offered only inaccurate timing sources or none that are accessible from user mode. And to top it off, the instrumentation added considerable overhead. (...) I had to scrap that work and decided to go with a sampling profiler.
And I don't know any other scripting language with a built-in sampling profiler. Does anybody?
Also, Julia has a built-in sampling profiler (built by Tim Holy):
http://docs.julialang.org/en/latest/stdlib/profile/
Hard to say whether Julia qualifies as a "scripting language" though – that's a pretty meaningless term these days.
The distortion effect of measurement is higher with instrumentation, and is the chief reason I prefer sampling when trying to find performance problems.
But finding CPU performance issues is far from the only reason for using a profiler.
You can thank GIANTS Software for this one: http://luajit.org/sponsors.html
GIANTS Software GmbH is sponsoring the development of a low-overhead profiling functionality for LuaJIT 2.1, starting in June 2013. GIANTS Software develops a variety of simulation games for desktop, mobile and consoles. These games make extensive use of Lua for scripting and modding. Switching to LuaJIT was instrumental in reducing the CPU load and sustaining the required frame rates on all platforms.
Existing profilers for Lua and LuaJIT are based on Lua hooks and debug queries. The use of these generic mechanisms incurs a high overhead. Execution of a program under control of such a profiler causes substantial slow-downs. Actual use of the program (gameplay) may be impossible in some cases.
The goal is to design and implement a new profiling functionality that has a much lower overhead, better control of detail and high flexibility.
Mike Pall is without doubt one of the most talented developers of our generation, alongside people like Fabrice Bellard and Jeff Dean (to name a few).