6 ms·

I wish I could understand LuaJit completly. I think if there is any (reasonably sized) software I would like to completly understand its this one. There is not

by nickik 14y ago

I wish I could understand LuaJit completly. I think if there is any (reasonably sized) software I would like to completly understand its this one. There is not only lots of good algorithms but also a lot of fantastic engineering. Things that you can not learn by reading papers. Congrats Mike Pall. Now lets see if you can do the same for GC community that you did to the JIT community. Good Luck.

chubot 14y ago
Yeah I agree it's a very interesting piece of software. But do you understand the prequisites -- namely processor microarchitecture? I know that's why I don't understand it. I imagine if I did it might not be that hard to understand. Most people's knowledge of the stack stops somewhere around C. C hasn't changed for 40 years. It's a portable assembly language, i.e. the common mental model is that each construct in C is a handful of assembly instructions on any processor. But to get LuaJIT-type performance you have to understand exactly how the CPU works, i.e. pipelining and reordering, internal caching algorithms, internal branch prediction algorithms, and maybe to some extent multicore, although I guess LuaJIT is single-threaded like Lua. Mike Pall's mental model is for sure not C (since a lot of it isn't even written in C), but the lower level CPU architecture. And that has changed a lot in the last 10 years. I think even if you coded a lot of assembly language in the 80's it wouldn't necessarily translate to working on something like LuaJIT. My impression from skimming some online posts is that he has read hundreds of pages of Intel/ARM reference documentation from cover to cover, for multiple CPUs. I think there are a limited number of people with the patience to do that, since it's non-portable and changes relatively quickly. Another problem is I think that the open source tools that are available don't work at the right level. Like when you are running profilers, they are helping you profile assembly code generated by a C compiler. The performance characteristics he's taking advantage of are at a lower level. I think you need CPU-specific performance counters and so forth, and there's a different way of getting those for each make/model. Are there even open source tools that allow you to get this information? I'd appreciate a pointer. It's just a different level of abstraction than most programmers are working with. Not that many people are even writing "low level" C these days, e.g. something like redis. A lot of "application level" C code you see these days is old and/or not particularly fast. I would be interested if anyone has any pointers for this style of code other than "read a bunch of CPU manuals". :)
- daurnimator 14y ago
  "Another problem is I think that the open source tools that are available don't work at the right level. Like when you are running profilers, they are helping you profile assembly code generated by a C compiler. The performance characteristics he's taking advantage of are at a lower level. I think you need CPU-specific performance counters and so forth, and there's a different way of getting those for each make/model. Are there even open source tools that allow you to get this information? I'd appreciate a pointer." The way forward is a sampling profiler. By sampling the stack every (eg) millisecond, you can build a picture of what is taking the longest.
  - nitrogen 14y ago
    A sampling profiler still doesn't tell you what specific instructions are taking longer, how much memory contention is happening between CPUs, how many cache and TLB misses there are, etc.
    - daurnimator 14y ago
      Sure it can; you can look at the next or previous machine instructions. If they occur more often than others than you can see which are taking longer. The other metrics you mentioned are often built into the operating system/memory manager IIRC.
- nickik 14y ago
  > But do you understand the prequisites -- namely processor microarchitecture? I do not but I try to learn more about that (coursera ftw). LuaJit is awesome on many level, first as you have pointed out attention to detailed on processer level is quite special and not many people can do that. Other then the good usage of the processor is not the only reason luajit is fast. On the compiler level, the optimization luajit does are extensive. Even lots of novel innovations are in that that people writting papers should read (Mike Pall has posted a list of thing that he thinks are somewhat novel). The nature of the trace compiler makes many of these things less complicated then they would have been otherwise.
- 14y ago
malkia 14y ago
I would love if someone starts a project - "Reading & Understanding LuaJIT". I've seen a similar project for PostgreSQL.
- elliptic 14y ago
  Have you a link for that?
  - malkia 14y ago
    I just found about it today actually - http://code.google.com/p/postgres-learning/ http://code.google.com/p/postgres-learning/
- nickik 14y ago
  There are many compiler books but no books about JITs in general. There are some good blogpost about LuaJit but not that many. Following Mike Pall (MikeMike on HN or reddit is intressting too) This is a good start: http://playingwithpointers.com/archives/1010 http://playingwithpointers.com/archives/1010
  - daurnimator 14y ago
    Great link; I haven't read that one before. Just submitted as own item: http://news.ycombinator.com/item?id=4777186 http://news.ycombinator.com/item?id=4777186
- Scaevolus 14y ago
  Mike Pall wrote a brief summary for "Reading & Understanding Lua", which is likely a prerequisite. http://www.reddit.com/r/programming/comments/63hth/ask_reddit_which_oss_codebases_out_there_are_so/c02pxbp http://www.reddit.com/r/programming/comments/63hth/ask_reddi...

by nickik 14y ago

chubot 14y ago

Yeah I agree it's a very interesting piece of software. But do you understand the prequisites -- namely processor microarchitecture? I know that's why I don't understand it. I imagine if I did it might not be that hard to understand. Most people's knowledge of the stack stops somewhere around C. C hasn't changed for 40 years. It's a portable assembly language, i.e. the common mental model is that each construct in C is a handful of assembly instructions on any processor. But to get LuaJIT-type performance you have to understand exactly how the CPU works, i.e. pipelining and reordering, internal caching algorithms, internal branch prediction algorithms, and maybe to some extent multicore, although I guess LuaJIT is single-threaded like Lua. Mike Pall's mental model is for sure not C (since a lot of it isn't even written in C), but the lower level CPU architecture. And that has changed a lot in the last 10 years. I think even if you coded a lot of assembly language in the 80's it wouldn't necessarily translate to working on something like LuaJIT. My impression from skimming some online posts is that he has read hundreds of pages of Intel/ARM reference documentation from cover to cover, for multiple CPUs. I think there are a limited number of people with the patience to do that, since it's non-portable and changes relatively quickly. Another problem is I think that the open source tools that are available don't work at the right level. Like when you are running profilers, they are helping you profile assembly code generated by a C compiler. The performance characteristics he's taking advantage of are at a lower level. I think you need CPU-specific performance counters and so forth, and there's a different way of getting those for each make/model. Are there even open source tools that allow you to get this information? I'd appreciate a pointer. It's just a different level of abstraction than most programmers are working with. Not that many people are even writing "low level" C these days, e.g. something like redis. A lot of "application level" C code you see these days is old and/or not particularly fast. I would be interested if anyone has any pointers for this style of code other than "read a bunch of CPU manuals". :)

daurnimator 14y ago
"Another problem is I think that the open source tools that are available don't work at the right level. Like when you are running profilers, they are helping you profile assembly code generated by a C compiler. The performance characteristics he's taking advantage of are at a lower level. I think you need CPU-specific performance counters and so forth, and there's a different way of getting those for each make/model. Are there even open source tools that allow you to get this information? I'd appreciate a pointer." The way forward is a sampling profiler. By sampling the stack every (eg) millisecond, you can build a picture of what is taking the longest.
- nitrogen 14y ago
  A sampling profiler still doesn't tell you what specific instructions are taking longer, how much memory contention is happening between CPUs, how many cache and TLB misses there are, etc.
  - daurnimator 14y ago
    Sure it can; you can look at the next or previous machine instructions. If they occur more often than others than you can see which are taking longer. The other metrics you mentioned are often built into the operating system/memory manager IIRC.
nickik 14y ago
> But do you understand the prequisites -- namely processor microarchitecture? I do not but I try to learn more about that (coursera ftw). LuaJit is awesome on many level, first as you have pointed out attention to detailed on processer level is quite special and not many people can do that. Other then the good usage of the processor is not the only reason luajit is fast. On the compiler level, the optimization luajit does are extensive. Even lots of novel innovations are in that that people writting papers should read (Mike Pall has posted a list of thing that he thinks are somewhat novel). The nature of the trace compiler makes many of these things less complicated then they would have been otherwise.
14y ago

malkia 14y ago

I would love if someone starts a project - "Reading & Understanding LuaJIT". I've seen a similar project for PostgreSQL.

elliptic 14y ago
Have you a link for that?
- malkia 14y ago
  I just found about it today actually - http://code.google.com/p/postgres-learning/ http://code.google.com/p/postgres-learning/
nickik 14y ago
There are many compiler books but no books about JITs in general. There are some good blogpost about LuaJit but not that many. Following Mike Pall (MikeMike on HN or reddit is intressting too) This is a good start: http://playingwithpointers.com/archives/1010 http://playingwithpointers.com/archives/1010
- daurnimator 14y ago
  Great link; I haven't read that one before. Just submitted as own item: http://news.ycombinator.com/item?id=4777186 http://news.ycombinator.com/item?id=4777186
Scaevolus 14y ago
Mike Pall wrote a brief summary for "Reading & Understanding Lua", which is likely a prerequisite. http://www.reddit.com/r/programming/comments/63hth/ask_reddit_which_oss_codebases_out_there_are_so/c02pxbp http://www.reddit.com/r/programming/comments/63hth/ask_reddi...