Comment by somethingsome
19 hours ago
I like Julia approach, compile everything on first launch, then reuse without speed penality, if you change a function, recompile that.
On another note, I'm working on a (big) PEP for python, and looking for maintainers and sponsors (as per python's rules). Do someone know where I could find such amazing persons? (I already have the code, works in cython,graalVM and pypy, and it's kind of a big change but I believe it will help a lot the language)
> I like Julia approach, compile everything on first launch, then reuse without speed penality, if you change a function, recompile that.
Python already compiles to bytecode (the .pyc files are a cache thereof). It's just that interpreting even the simple bytecode instructions can take dozens of clock cycles each. I imagine that a lot of this is not in the interpreter loop (which has seen quite a bit of optimization, IIRC up to the level of "predictive" gotos within a big switch statement within a loop) but just unwrapping objects and moving values to and from registers, dealing with the fact that there is basically never any cache coherency for anything etc.
Basically I'm not convinced that writing out the set of machine-code instructions needed to interpret the bytecodes would be a big win, because it takes too many instructions for simple tasks.
The Julia approach is the same as BASIC (as originally designed), Lisp, Prolog, as added info.
I don't recall being able to inspect compiled machine code in basic like I can in Julia.
[EDIT - I assume you are commenting on Dartmouth BASIC.]
And? That doesn't change the fact it was compiled into machine code before execution, nor that with exception of 8 bit home computers, there were plenty of compiled BASICs in mainframes and later 16 bit home computers.
Since we have to prove everything on Internet forums,
https://archive.org/details/bitsavers_dartmouthB_3679804/mod...
=> Saving of Compiled Programs
The language forum is the place to start- you should already have a thread there gathering feedback before writing a pep?
Thank-you, it's a longtime idea, but I was finally able to implement it, but now I'm trying to learn the procedure
However because of this, Julia has has persistent problems with "time to first plot", which has gotten better, but they cannot fully ameliorate due to the way it fundamentally works. So there are tradeoffs -- the performance gets better, but the interpreted REPL experience is markedly worse.
By the way, the current nightly (especially if considering the optimized build) has a very substantial TTFX drop compared to the current release [1]
[1] https://perf.julialang.org/?tab=overview
It is overly exaggerated, especially when taken into account how long it takes to compile native libraries that people keep calling "Python" libraries, if there isn't a suitable wheel for the current environment.
I think it's true that it's exaggerated, but that doesn't mean the tradeoff doesn't exist.
4 replies →
There’s an #internals-and-peps channel in the Python discord where some folks hang out.
That's basically how Python already compiles source to byte-code.
Julia gets a lot more benefit out of it because it's compiling type-specialized version of the function all the way down to machine code. So for example, a function that's being called with a `Vector{Int64}` ends up dealing with an array of unboxed ints, not going through dynamic dispatch on a generic array for every operation.
I have no doubt Julia's far better with this. I just wanted to point out Python does have a similar precedence for ahead-of-time compilation, albeit with byte-code only. If the Python steering council ever gets its act together, maybe Python could have real AOT and JIT.
1 reply →