Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia 1.6 addresses latency issues

lwn.net

Post reply on HN
Print view View original

41–50 of 160 posts

Re: Julia 1.6 addresses latency issues

#41

Post by TchoBeer »

throwaway894345 wrote: post #7
Buttons840 wrote: post #4

I'm a big fan of Julia. It does live up to its speed claims. I've implemented the board game Go in Python, Rust, and Julia and Julia is definitely closer to Rust in speed. Same algorithms were used for all implementations. Julia's time to first plot still has some problems. The Plots library can build animations, but the time to first animation on my computer is like 10 minutes, and the time to second animation is an…

> I've implemented the board game Go in Python, Rust, and Julia and Julia Oof. I reread this several times consecutively as "I've implemented the board game in Go, Python, Rust ...".

Same, and I literally have a correspondence game going on in another tab

Re: Julia 1.6 addresses latency issues

#42

Post by ku-man »

krastanov wrote: post #16
enriquto wrote: post #14

Earlier quoted context omitted.

> your targets are ridiculous Only because you are not used to somewhat fast programs: $ /usr/bin/time -v gnuplot -e 'set term png; plot sin(x)' > sin.png ... User time (seconds): 0.02 System time (seconds): 0.00

Come on, it is silly to compare a full general purpose language against a special-purpose tool. Yes, grep is also better than julia at searching for a string in a file. Julia is a terrible replacement for gnuplot and gnuplot is a terrible replacement for julia.

"... it is silly to compare a full general purpose language against a special-purpose tool..."

Wait, wait... isn't Julia a general purpose language? At least is what the fanboys keep repeating ad-nauseaum

Re: Julia 1.6 addresses latency issues

#43

Post by Buttons840 »

dunefox wrote: post #24
Buttons840 wrote: post #4

I'm a big fan of Julia. It does live up to its speed claims. I've implemented the board game Go in Python, Rust, and Julia and Julia is definitely closer to Rust in speed. Same algorithms were used for all implementations. Julia's time to first plot still has some problems. The Plots library can build animations, but the time to first animation on my computer is like 10 minutes, and the time to second animation is an…

> but the time to first animation on my computer is like 10 minutes Have you tried 1.6 already? I find it's substantially faster.

Yes, I was doing it just this week with Julia 1.6.

Re: Julia 1.6 addresses latency issues

#44

Post by Buttons840 »

vavooom wrote: post #25
Buttons840 wrote: post #4

I'm a big fan of Julia. It does live up to its speed claims. I've implemented the board game Go in Python, Rust, and Julia and Julia is definitely closer to Rust in speed. Same algorithms were used for all implementations. Julia's time to first plot still has some problems. The Plots library can build animations, but the time to first animation on my computer is like 10 minutes, and the time to second animation is an…

Do you have any documentation / Github repos where you build those Go implementations? I am a huge fan of the game and would be curious to see how you built it, specifically in Python / Julia.

https://github.com/DevJac/gobot https://github.com/DevJac/julia_gobot

Re: Julia 1.6 addresses latency issues

#45

Post by ufo »

Zababa wrote: post #23
gugagore wrote: post #5

Speeding up compilation itself is one approach to the latency issue. And there's also the idea of blending compilation and interpretation using e.g. https://github.com/JuliaDebug/JuliaInterpreter.jl .

V8 reduced the start up times of WebAssembly this way but with a single pass compiler instead of an interpreter. Here's the article: https://v8.dev/blog/liftoff

One difference is that web assembly is typed and is designed to make these compilers possible.

In the context of Javascript, V8 did the opposite. Originally they had a baseline compiler for Javascript but now they use an interpreter, which reduces the startup latency.

Re: Julia 1.6 addresses latency issues

#46

Post by nightfly »

reikonomusha wrote: post #28
krastanov wrote: post #21

Earlier quoted context omitted.

Could you elaborate or give examples? I guess all the complaints about binaries come from people used to something like Common Lisp, but while I have a general understanding of what a lisp is, this type of "provide a binary for your interpreted-ish language" is an incredibly foreign idea to me.

Common Lisp was designed to be interactive and have a REPL. You can redefine functions, classes, etc. on the fly with strictly-defined semantics. (You don’t have to guess what happens if you, say, re-name a field of your class.) This is insanely useful during development, where you absolutely want to avoid doing full recompiles every time you make a little change you want to test. Some people call this “interactive a…

The way that common lisp does this though is pretty much creating a core dump that you can execute, which isn't what most people are expecting from an executable. It's not a _bad_ way, it's just pretty unique to common lisp.

Re: Julia 1.6 addresses latency issues

#47

Post by reikonomusha »

nightfly wrote: post #46
reikonomusha wrote: post #28

Earlier quoted context omitted.

Common Lisp was designed to be interactive and have a REPL. You can redefine functions, classes, etc. on the fly with strictly-defined semantics. (You don’t have to guess what happens if you, say, re-name a field of your class.) This is insanely useful during development, where you absolutely want to avoid doing full recompiles every time you make a little change you want to test. Some people call this “interactive a…

The way that common lisp does this though is pretty much creating a core dump that you can execute, which isn't what most people are expecting from an executable. It's not a _bad_ way, it's just pretty unique to common lisp.

What exactly are people “expecting” from an executable? It is a piece of binary code on disk, full of machine code, that runs without a VM or external runtime libraries.

    ./mycoolprog
just works. From a user perspective, there’s no difference.

The binary itself isn’t structured like a typical one with C debugging symbols, etc. But it’s also not some “faux binary” like a bunch of .pyc bundled as data and unzipped when the program runs. It truly is machine code, just arranged differently than a bunch of C ABI functions.

I claim most people running binaries don’t care about the memory layout of the binary. I certainly am never thinking about that every time I run `grep`. You don’t debug Lisp programs with C’s tooling. You use Lisp’s tooling.

(Unless, of course, you use an implementation like Embeddable Common Lisp, which does compile your Lisp program as a C program, and does produce a non-image-based executable. That’s the beauty of Lisp being a standardized language with multiple conforming implementations.)

Re: Julia 1.6 addresses latency issues

#48

Post by adgjlsfhk1 »

superdimwit wrote: post #32
reikonomusha wrote: post #28

Earlier quoted context omitted.

Common Lisp was designed to be interactive and have a REPL. You can redefine functions, classes, etc. on the fly with strictly-defined semantics. (You don’t have to guess what happens if you, say, re-name a field of your class.) This is insanely useful during development, where you absolutely want to avoid doing full recompiles every time you make a little change you want to test. Some people call this “interactive a…

I am hopeful that Julia should be able to get this cross-session caching of compiled code. Would make restarting the REPL (to e.g. add a field to a struct) much less frustrating.

Caching is easy. The hard part here is correctly invalidating the cache. Specifically, if a user is using different libraries between sessions, figuring out which methods have been overridden (or inline code that was overridden) becomes complicated.

Re: Julia 1.6 addresses latency issues

#49

Post by oblio »

pjmlp wrote: post #39
Zababa wrote: post #33

Earlier quoted context omitted.

> Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? I think this is the case for at least the most popular JIT'd languages: Java, C#, JS, and PHP. Also for the most popular interpreted languages: Python, Ruby and also PHP. I don't know about Visual Basic and R though. I know that an exception is Dart, that combines a JIT and an AOT. I think EmacsLisp can now be also compiled, b…

Java and C# also have combined JIT and AOT since they exist, .NET moreso. Other examples are Lisp and Scheme variants, Eiffel, OCaml, Haskell, Prolog.

The main SDKs and programming paradigms for Java and C# both don't mesh well with AOT, though. Reflection, heavy reflection based frameworks.

Not that many places use Java/C# AOT compilation, except for games/iOS apps.

Almost every place I've seen using Java/C# was using JIT.

Re: Julia 1.6 addresses latency issues

#50

Post by neolog »

adgjlsfhk1 wrote: post #18
krastanov wrote: post #11

Earlier quoted context omitted.

Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? If you generate a "python binary", you need to package python with your binary. Same for perl/ruby. It just seems weird that people expect julia to be able to do that. It is cute that PackageCompiler.jl exists and it is cute that more AOT compilation work is being currently done, but it seems crazy to expect Julia to be good at…

The reason Julia should be able to do this is that it uses LLVM to generate machine code "just ahead of time". As such, (at least for type stable code), it should be possible to save the code we generate. The main place where static AOT matters for Julia isn't full applications, but libraries. Being able to generate static libraries would allow Julia to replace C++ and Fortran much more fully in places like python li…

> The main place where static AOT matters for Julia isn't full applications, but libraries.

That depends on the use case. With improvements in static compilation, julia could probably be a good application language. Game development would be an interesting market.

Post reply on HN