Re: how to read the source codes of luajit?

  • From: Semi Essessi <jheriko@xxxxxxxxx>
  • To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
  • Date: Fri, 3 Jul 2015 01:54:03 +0100

at the risk of offense...

i don't think the code is excessively complicated beyond what it needs,
just bad in some particular ways that make it difficult to understand when
approaching it for the first time. at least looking at
https://github.com/LuaDist/luajit/tree/master/src

looking at it there are lots of classic mistakes... a big cleanup and
refactor would make this easy to read and work with, but is probably a
couple days work or more, after you have some decent knowledge of the code
base (and probably a week or two full time if you do it as you go along imo)

the biggest offender by far are the naming conventions. two and three
letter variable names are often hard to decipher, and sadly a lot of people
use them despite there being no excuse these days to not use a proper
descriptive name, even without an ide and autocompletes.

that being said there is some ok high level organisation and fairly
consistent style, so following the logic isn't too hard at any given place
and working out the top level architecture (or near absense there of) is
quite easy too... although the filenames are equally awful as the rest of
the naming conventions. there are also some needlessly large files.... they
might be intimidating but find/replace or a good ide will take that pain
away

there is some dumb psuedo-cleverness as well... a lot of programmers do
this, stuff like writing x << 1 instead of x * 2, which was nearly never a
valid optimisation (optimising this in compilers has been trivial since the
very beginning, and actually they can do a better job know with
architecture knowledge... a mul may actually be faster depending on the
surrounding code and the architecture targetted).

its a shame this is such a useful and popular project in some ways... like
many absolutely awful codebases, its all about the end user experience. and
cleaning it up so it becomes fast to develop on and safer to use would be
tricky without ruining that inbetween. until something like that happens (i
don't care anywhere near enough to want to try) this will always be more
difficult to approach than necessary.

On 29 June 2015 at 15:16, Luke Gorrie <luke@xxxxxxxx> wrote:

On 29 June 2015 at 12:52, Gustavo Serra Scalet <
gustavo.scalet@xxxxxxxxxxxxxxx> wrote:

Also I wanted to share an interesting link about the trace compiler:

//www.freelists.org/post/luajit/How-does-LuaJITs-trace-compiler-work,1


Here is another: Thomas Schilling's PhD thesis which discusses LuaJIT and
applies some of the same techniques to another language. Especially Chapter
3 "Trace-based Just-in-time compilation".


https://dl.dropboxusercontent.com/u/3265448/schilling.thesis.final.2014-01-20.pdf



Other related posts: