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.
A Deep Introduction to JIT Compilers: JITs are not very Just-in-time
91–100 of 103 posts
Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time
#92Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time
#93Earlier 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?
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
#94Earlier 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?
Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time
#95Earlier 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?
Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time
#96There 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.
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
#97Earlier 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?
Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time
#98Re: A Deep Introduction to JIT Compilers: JITs are not very Just-in-time
#99Earlier quoted context omitted.
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
#100Earlier 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.
It's like comparing speed of a bike vs airplane: the brand and the quality of the bike doesn't really matter…