Hacker News

points by somethingsome 2 days ago | 0 comments

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)

[–] ModernMech 2 days ago

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.

[–] FacelessJim 2 days ago

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

[–] StefanKarpinski 22 hours ago

It's not unavoidable, it just hasn't yet been avoided. It could be avoided the same way as other JITs: by interpreting until a compiled version of the code is available. That's actually being worked on, but it adds considerable complexity. Among other things, it requires being able to jump out of an executing interpreter loop into an optimized, compiled version of the same function. Doable, but annoying to implement and requires compiling two versions of the function instead of one. It can also cause performance instability — see https://tratt.net/laurie/blog/2022/more_evidence_for_problem... and the older paper referenced there.

[–] pjmlp 2 days ago

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.

[–] ModernMech 2 days ago

I think it's true that it's exaggerated, but that doesn't mean the tradeoff doesn't exist.

[–] pjmlp 2 days ago

A tradeoff that doesn't make sense to complain about, when the alternative is waiting for native libraries being compiled, in a mix of C, C++, Fortran and more recently Rust.

A pain point that is big enough that at least two programming languages, Julia and Mojo, were created to move beyond it.

Which would not even be an issue, if Lisp, Scheme and Prolog had not lost their aura among AI devs.

[–] ModernMech 2 days ago

Julia and Mojo are attempts at solving the "two language problem", which not every Python user actually has -- they're fine doing work exclusively in Python, not even using any of the libraries you're talking about.

Mojo in particular recognized to compete with Python they'd have to be a superset, then they backed of that goal when they realized it would be too hard.

So at the end of the day, Python has a value proposition and it cannot be entirely subsumed by other languages, because those languages make tradeoffs that move away from Python's value.

[–] pjmlp 2 days ago

Python's value is being a portable scripting language, a better Perl, unfortunately some try to do full blown applications with an interpreted language.

[–] necovek 2 days ago

Perhaps it's worse that some even succeed in building very complex systems that can handle a lot of load too (see eg. Instagram)? ;-)

Python has a known set of trade-offs, mostly related to loop performance. But if you understand the trade-offs and available mitigations, it should not stop you from building good software. You know, just like any other ecosystem.

[–] zahlman 2 days ago

> 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.

[–] mcepl 1 day ago

Python doesn’t really compile to *.pyc. These are just parsed tokens and AST, really not proper machine code.

[–] pjmlp 2 days ago

The Julia approach is the same as BASIC (as originally designed), Lisp, Prolog, as added info.

[–] klaff 2 days ago

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.]

[–] pjmlp 2 days ago

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

[–] orf 2 days ago

The language forum is the place to start- you should already have a thread there gathering feedback before writing a pep?

[–] somethingsome 2 days ago

Thank-you, it's a longtime idea, but I was finally able to implement it, but now I'm trying to learn the procedure

[–] mirashii 2 days ago

There’s an #internals-and-peps channel in the Python discord where some folks hang out.

[–] cpburns2009 2 days ago

That's basically how Python already compiles source to byte-code.

[–] jey 2 days ago

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.

[–] cpburns2009 2 days ago

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.