Live data from Hacker News

A Deep Introduction to JIT Compilers: JITs are not very Just-in-time

carolchen.me

91–100 of 103 posts

Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time

#91
post #86

Earlier quoted context omitted.

I know Python does the dunders and all, but couldn’t they have at least stuck a dot in front of it if they wanted to move it out of the way :(

That won't work on other operating systems anyway.

Those files are typically generated on each platform anyway, so just have the dot on platforms that allow it and not on platforms that don’t.

Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time

#93
post #89
post #10

Earlier quoted context omitted.

Yep, class of 2019, jit to actually have a physical prom and graduation

How does a high school kid get so interested in (and manages to pull off a great article about) stuff like Intermediate Representations, compiler optimisation techniques, JITs as different as those of Julia and GraalVM, that would easily scare even a seasoned programmer with years of experience and a CompSci degree under the belt?

You don't know many nerds, do you?

EDIT: When I was in high school, msdos and windows viruses were all the rage: self-modifying polymorphic code that injected itself into the RAM of other processes, having no identical strings longer than a few bytes between each instance of the virus, etc. Way useless than jit stuff, but a comparable level of "depth", and 100% assembly code.

Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time

#94
post #89
post #10

Earlier quoted context omitted.

Yep, class of 2019, jit to actually have a physical prom and graduation

How does a high school kid get so interested in (and manages to pull off a great article about) stuff like Intermediate Representations, compiler optimisation techniques, JITs as different as those of Julia and GraalVM, that would easily scare even a seasoned programmer with years of experience and a CompSci degree under the belt?

I suppose I can answer this, as a high school kid: because it's interesting! I'm really interested in compilers and interpreters as well, I suppose because I think it's cool how they're so integral to all kinds of programming, and how it takes so much work to build one that can then almost magically understand what you tell it to do. I work on RustPython[0], and even though I've seen and edited the bytecode interpreter loop and the parser and the ast->bytecode compiler and all of the builtin functions and types, it's still hard to fathom that all of that is running under the hood when I type something at the REPL and it just runs.

[0]: https://github.com/RustPython/RustPython

Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time

#95
post #89
post #10

Earlier quoted context omitted.

Yep, class of 2019, jit to actually have a physical prom and graduation

How does a high school kid get so interested in (and manages to pull off a great article about) stuff like Intermediate Representations, compiler optimisation techniques, JITs as different as those of Julia and GraalVM, that would easily scare even a seasoned programmer with years of experience and a CompSci degree under the belt?

[deleted]

Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time

#96

There is also an interesting presentation about how Azul implemented their JIT called Falcon, that is fully based on LLVM. https://www.youtube.com/watch?v=Uqch1rjPls8 Generally LLVM is a nice idea that allows vendors to reuse major components.

The one problem with LLVM is that it’s not very well suited to JIT compilers, a major component of which is its slowness.

Former Azul employee here

Absolutely correct that LLVM is a fair amount slower than C1 or C2. Azul augmented our JITs with a compilation recording & replay mechanism to combat the general start-up problems posed by JITs (including Falcon).

For those who are curious, here's my presentation on the topic: https://2018.jpoint.ru/en/talks/63npsyjpokmukqsag80oia/.

Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time

#97
post #89
post #10

Earlier quoted context omitted.

Yep, class of 2019, jit to actually have a physical prom and graduation

How does a high school kid get so interested in (and manages to pull off a great article about) stuff like Intermediate Representations, compiler optimisation techniques, JITs as different as those of Julia and GraalVM, that would easily scare even a seasoned programmer with years of experience and a CompSci degree under the belt?

You should change seasoned programmer to seasoned framework web dev.

Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time

#98

Earlier quoted context omitted.

That’s not really accurate. It has strict requirements about stack traversal required to appropriately trace memory roots. This is incidental to JIT vs AOT.

Did you reply to the wrong comment?

Sorry, what did you read?

Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time

#99

Earlier quoted context omitted.

Did you reply to the wrong comment?

Sorry, what did you read?

This comment: https://news.ycombinator.com/item?id=23744360, where you're talking about JIT vs AOT in response to my LLVM one. I couldn't really understand how it followed.

Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time

#100

Earlier quoted context omitted.

> Same goes for the idea that garbage collection can be faster than manually managed memory. It's really workload dependent and depend a lot of the GC involved (a pretty dumb one like Python's or Go's won't get you anything performance wise), but a copying collector can achieve allocation way faster than a regular heap allocator (the allocation can be almost as cheap as allocating on the stack). If you can't avoid bo…

CPython and Go's allocators are already faster than simple heap allocation using malloc/free. CPython has a specialized arena allocator for small allocations called obmalloc. Go's allocator is descended from tcmalloc but faster because it doesn't need to support the free(1) api and all the book-keeping required.

You're missing the point here: modifying tcmalloc can give you percentage point improvement, but a copying collector can speed up the allocation by orders of magnitude (the allocation is done in a contiguous memory space, every object adjacent to each other and allicating just becomes a few asm instructions, like 5 or something).

It's like comparing speed of a bike vs airplane: the brand and the quality of the bike doesn't really matter…

Post reply on HN