Julia 1.6 Highlights • Hacker News Board

Re: Julia 1.6 Highlights

#221

Post by DNF2 » Mon, Mar 29, 2021, 9:54 AM UTC

dan-robertson wrote: post #214

eigenspace wrote: post #65

Earlier quoted context omitted.

Julia's garbage collector is quite good. > I know that you shouldn't produce garbage, but I happen to like immutable data structures and those work better with optimised GCs. If you use immutable data-structures in julia, you're rather unlikely to end up with any heap allocations at all. Unlike Java, Julia is very capable of stack allocating user defined types.

I think that’s true for small structs made of floats but not true for something like an immutable lisp-style linked list.

Not just floats, and I'm not sure they have to be that small. All sorts of structs containing bitstypes/value types can be stack allocated. In fact, even some structs with pointers to heap-allocated memory can be stack-allocated (such as array views.)

I don't know about linked lists, though.

Re: Julia 1.6 Highlights

#222

Post by RyEgswuCsn » Mon, Mar 29, 2021, 11:26 AM UTC

DNF2 wrote: post #219

RyEgswuCsn wrote: post #217

Earlier quoted context omitted.

Yes I get your point. I guess I should have phrased my first question like the following 1. Can unoptimised Julia code run faster than unoptimised Python code (with numpy being used to do the heavy lifting)? Let's say one is prototyping some algorithm so iteration speed is more relevant than running speed. Then one can choose either Julia or Python (with the help of numpy perhaps) and get an implementation in similar…

This depends on what you mean by '(un)optimized code'. Because there's a difference between unoptimized and naive code. 'Unoptimized' code should still observe most of the performance tips in the manual (such as avoiding globals and type instability), while 'naive' code frequently does not. With some experience, you never write naive code, even for quick prototypes. In those cases, Julia should outperform other dynam…

Well there is no type stability or scoping rules to worry about in Python, so just for the sake of comparing the two, I was indeed thinking of 'naive' Julia code vs 'naive' Python code.

The thing with Python is that 'naive' Python code is already pretty close to 'unoptimised' Python code, so one can write naive Python code with numpy and still ends up with not-too-shabby performance, provided they chose an efficient algorithm, of course. In other words, there are not as many performance mistakes one can make with Python (perhaps because it can't get any worse). I imagine that's also why so many Python users who tried Julia were disappointed that direct translations of their Python program fail to perform as fast as advertised.

Re: Julia 1.6 Highlights

#223

Post by timholy » Tue, Mar 30, 2021, 12:28 PM UTC

RyEgswuCsn wrote: post #222

DNF2 wrote: post #219

Earlier quoted context omitted.

This depends on what you mean by '(un)optimized code'. Because there's a difference between unoptimized and naive code. 'Unoptimized' code should still observe most of the performance tips in the manual (such as avoiding globals and type instability), while 'naive' code frequently does not. With some experience, you never write naive code, even for quick prototypes. In those cases, Julia should outperform other dynam…

Well there is no type stability or scoping rules to worry about in Python, so just for the sake of comparing the two, I was indeed thinking of 'naive' Julia code vs 'naive' Python code. The thing with Python is that 'naive' Python code is already pretty close to 'unoptimised' Python code, so one can write naive Python code with numpy and still ends up with not-too-shabby performance, provided they chose an efficient…

The point is, once you've gotten used to Julia you tend to write good code most of the time without even thinking about it. And that good code still "looks good," meaning it takes advantage of Julia's expressiveness and brevity. Understandably, newcomers make many more performance mistakes.

So there's often a huge difference between "unoptimized code" (something written by an experienced developer who's deliberately taking the easy way out) and "naive code" (something a newcomer might write). There can literally be orders-of-magnitude performance difference.

I agree that there isn't as much to learn about Python. But of course that's largely because of the gap in opportunities.

Re: Julia 1.6 Highlights

#224

Post by gdpr » Thu, Apr 01, 2021, 12:45 AM UTC

Buttons840 wrote: post #157

I recently ported a reinforcement learning algorithm from PyTorch to Julia. I did my best to keep the implementations the same, with the same hyperparameters, network sizes, etc. I think I did a pretty good job because the performance was similar, solving the CartPole environment in the a similar number of steps, etc. The Julia implementation ended up being about 2 to 3 times faster. I timed the core learning loops,…

Similar experience over here. (G)ARCH models are severely underserved in Python, and I could not be bothered to learn a Probabilistic programming abstraction like Pyro or Stan just to build a quick prototype myself.

Chose Julia instead. Took 4 hours to get everything sorted out (including getting IT to allow Julias package manager to actually download stuff) and have the first model running just putting a paper into code. Since code is just writing the math, this is a vast communication improvement.

After fiddling around withit at home for a week, this was the first professional experience and I'm blown away.