Re: Hi!
- From: Mike Pall <mike-1210@xxxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Thu, 11 Oct 2012 16:56:52 +0200
Sanjoy Das wrote:
> Nothing specific. I have only worked with method-at-a-time JITs in
> the past and consequently have little more than an armchair idea of
> how a tracing JIT works. I want to change that.
There are a couple of unsolved problems with trace compilers that
would be worth quite a few research papers.
One, that relates to profiling, is how to map traces back to source
code lines. A trace may encompass selected code paths of multiple
functions. And multiple traces may have code originating from a
single line. Also, not every trace runs to completion and there's
extra overhead due to frequent trace switches. E.g. it's very bad
if a single line of code spawns 20 traces (overspecialization),
but it's perfectly ok if 20 traces contain that line, if it's part
of a common utility function.
In general, it's hard to present feedback to a user how well their
code performs, what's costly and what's not and to give suitable
advice for improvements to their code.
I'm not trying to talk you into working on something related to
profiling. It's just that this has been a pressing need for many
developers and so far nobody had enough perseverance to tackle this
(including myself).
You're welcome if you want to work on any other aspect of LuaJIT.
But it would be a good start to look at the dump output or at
execution profiles, to get a feeling for the inner workings of the
trace compiler. There are a few surprises ahead, rest assured.
[E.g. the trace selection algorithm comes up with 'interesting'
but profitable traces you'd never pick yourself. Nested loops are
the textbook example. But e.g. for nsieve the compiler discovers
some basic facts about primality and optimizes the traces for
divisors of 2, 3, 5 without you telling it anything about that.]
> One thing: how will a sampling profiler be more informative than
> perftools? What is the motivation behind adding a second profiler to
> LuaJIT?
First, LuaJIT is cross-platform and perftools is not. The majority
of LuaJIT users are on 1) Windows, 2) embedded and 3) mobile
platforms right now (and mobile is catching up quickly). Only the
typical server-side apps using LuaJIT (scientific computing, HFT)
are run under Linux, BSD et al.
The other problem is that LuaJIT has lots of information about the
Lua side of things, but it's very hard to present this to a classic
profiler designed for C programs. The contortions one has to go
through to get somewhat useful output from perftools or the GDB-JIT
API are unspeakable.
And, last but not least, the memory and performance impact on the
profiled or debugged process must be minimal. Embedded and mobile
developers would really welcome some kind of lightweight remote
probe capability. There are quite a few profiling frameworks that
fail miserably on that aspect -- linking in a multi-megabyte
library is just not going to fly for the typical LuaJIT developer.
--Mike
Other related posts:
