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

Julia 1.6 Highlights

julialang.org

Post reply on HN
Print view View original

201–210 of 224 posts

Re: Julia 1.6 Highlights

#201

Post by mbauman »

RyEgswuCsn wrote: post #186
snicker7 wrote: post #163

Earlier quoted context omitted.

> Second to write very fast julia u need to knew a lot of "tricks" and in most cases u won't be doing it as easy as writing normal code. That's true in literally any language. Some languages require inlined assembly. Others require preprocessor directives. In almost all languages, you need to understand the difference between stack and heap, know how to minimize allocations, know how to minimize dynamic dispatch, kno…

> That's true in literally any language. Some languages require inlined assembly. Others require preprocessor directives. In almost all languages, you need to understand the difference between stack and heap, know how to minimize allocations, know how to minimize dynamic dispatch, know how to efficiently structure cache-friendly memory layouts. And of course, data structures & algorithms 101. I think what s/he meant…

> Julia is not "magically" faster than other languages

That's somewhat true, and is at the end-point of some mismatched expectations when folks come to Julia. Julia is a high-level dynamic language whose semantics are conducive to creating the ~same performance as static languages.

So if your unoptimized Julia program relies upon traditional "dynamic" features like `Any[]` arrays, then you should expect to see dynamic- (read: python-) like performance out of Julia. Julia should match performance of other dynamic languages here, but the complier doesn't have all the typical dynamic optimizations because, well, it's often easy to write your code in a manner that ends up hitting the happy path that gets the static-like performance.

Conversely, if your dynamic language baseline is just glue to an optimized static library, then you should expect to see static-like (read: C/C++-like) performance out of your dynamic language. Julia really should match performance here, and if it doesn't, open an issue: it's a bug.

Where Julia truly excels are the cases where you don't have a library implementation (like numpy) to lean on and find yourself writing a hot `for` loop in a dynamic language. Further, it excels at facilitating library creation, leading to more and more first-class ecosystems that are best-in-class like DiffEq.

Re: Julia 1.6 Highlights

#202

Post by neolog »

yellowcake0 wrote: post #196
neolog wrote: post #162

Earlier quoted context omitted.

I'm a daily Julia user but tbh I've gotta agree with parent commenter. I think Jeff's attitude in the "What's bad about Julia" talk is the right way to handle criticism: listen to the person, ask about their use cases, understand how Julia could be improved for that user. Accepting criticism makes a good product, and seeing project leaders do it makes a good impression.

Oh come now, are we really so delicate that one brusque comment gets our back up? Does the man have to be obsequious everytime he discusses his language in an informal setting?

It's not that we're delicate, it's that poor communication between users and maintainers leads causes problems. As for "one comment", OP already mentioned that defensiveness is becoming an issue in the community.

Re: Julia 1.6 Highlights

#203

Post by pjmlp »

eigenspace wrote: post #200
pjmlp wrote: post #171

Earlier quoted context omitted.

Except everyone is forgetting that I also mentioned Dylan, from Apple, and whose goal was to be a system programming language for the Newton OS, with the Dylan team winning over the C++ one, but internal politics made the decision to go with the outcome of the C++ team alongside NewtonScript.

I directed most of my comments towards CL because I know more about it than Dylan. My understanding is that Dylan lacks parametric types, so that comment can be straightforwardly applied to Dylan. IMO Parametric types are a really important part of this. Regarding performance, I don't know much about this in Dylan. Was Dylan able to completely remove the runtime overhead of multiple dispatch for type stable code?

Yep, some research was done in that domain, https://opendylan.org/documentation/publications.html

Also note that it was competing against C++ as the Newton OS system programming language, it only lost due to politics.

https://news.ycombinator.com/item?id=15107367

Re: Julia 1.6 Highlights

#204

Post by cbkeller »

pjmlp wrote: post #171
cbkeller wrote: post #152

Earlier quoted context omitted.

In this context, I think there might be an argument to be made that Julia is to multiple dispatch (or multiple dispatch + JAOT) as the iPhone is to “touchscreen computers that can make phone calls”. It’s not that it’s the first, but it seems to be the first where the use of multiple dispatch throughout the community was sufficiently pervasive to kick-start the emergence of the strong network effects we’re now seeing…

Except everyone is forgetting that I also mentioned Dylan, from Apple, and whose goal was to be a system programming language for the Newton OS, with the Dylan team winning over the C++ one, but internal politics made the decision to go with the outcome of the C++ team alongside NewtonScript.

I think Dylan would be (perhaps ironically) the Newton in this analogy. (or maybe General Magic?)

Pioneering and ahead of its time in many ways, but for whatever reason it seems that the use of multiple dispatch in Dylan seems to have not (yet?) led to the same level of ecosystem-wide composability.

Re: Julia 1.6 Highlights

#205

Post by StefanKarpinski »

dagw wrote: post #199
StefanKarpinski wrote: post #116

Earlier quoted context omitted.

Please file an issue describing the situation: https://github.com/JuliaLang/julia/issues/new

A quick bit of googling shows that people have been complaining about and reporting this for years.

Many years of being on the receiving end of issues shows that there are a large number of different potential problems which manifest themselves in similar ways. Some are fixed, some persist, some may be new. If people don’t file issues describing exactly what they tried and what happened, this vague complaint just goes into the bucket of “Who knows? Hopefully someone else files a proper bug report.”

I’m not sure what issue you think you identified by googling such a short problem description, but it seems like it could be any of:

- slow internet connection

- firewall / proxy issues

- antivirus gumming things up

- file system being slow when dealing with lots of small files (Windows mostly)

- precompiling Plots took longer than expected

- precompiling Plots hit a deadlock

- loading Plots took longer than expected

- loading Plots hit a deadlock

- something else?

Worse, what “stuck” means is also ambiguous. Does that mean it failed with an error? Does that mean a download started but then was too slow for the user’s taste? Does it mean that a download started but never got any data at all? How long did the user wait?

My best guess is that git cloning the registry on Windows is taking a long time and isn’t actually stuck. There’s a fix for that being worked on for 1.7 (don’t unpack registries).

Re: Julia 1.6 Highlights

#206

Post by eigenspace »

pjmlp wrote: post #203
eigenspace wrote: post #200

Earlier quoted context omitted.

I directed most of my comments towards CL because I know more about it than Dylan. My understanding is that Dylan lacks parametric types, so that comment can be straightforwardly applied to Dylan. IMO Parametric types are a really important part of this. Regarding performance, I don't know much about this in Dylan. Was Dylan able to completely remove the runtime overhead of multiple dispatch for type stable code?

Yep, some research was done in that domain, https://opendylan.org/documentation/publications.html Also note that it was competing against C++ as the Newton OS system programming language, it only lost due to politics. https://news.ycombinator.com/item?id=15107367

Yes, I fully agree it's a darn shame that Dylan was abandoned by Apple.

Re: Julia 1.6 Highlights

#207

Post by snovv_crash »

pjmlp wrote: post #180
snovv_crash wrote: post #174

Earlier quoted context omitted.

Having a Lamborghini racing a Toyota Corolla is of course going to show the Lambo winning. But if I need to maintain a fleet of them to move 1000 passengers around a city with certain availability guarantees, I'm going with the Toyotas every time.

Likewise if I do races for living I am picking the Lamborghini.

But Java isn't a Lamborghini exactly, is it? It just has the maintenance issues of one.

Re: Julia 1.6 Highlights

#208

Post by Buttons840 »

stellalo wrote: post #170
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,…

That’s interesting: did you use Flux?

Yes. I used Flux.

Re: Julia 1.6 Highlights

#209

Post by pjmlp »

snovv_crash wrote: post #207
pjmlp wrote: post #180

Earlier quoted context omitted.

Likewise if I do races for living I am picking the Lamborghini.

But Java isn't a Lamborghini exactly, is it? It just has the maintenance issues of one.

When compared with Go it certainly is, across all axes.

Then there are a couple of McLaren, Lotus and F1, but then it is another level altogether.

Re: Julia 1.6 Highlights

#210

Post by snicker7 »

mbauman wrote: post #201
RyEgswuCsn wrote: post #186

Earlier quoted context omitted.

> That's true in literally any language. Some languages require inlined assembly. Others require preprocessor directives. In almost all languages, you need to understand the difference between stack and heap, know how to minimize allocations, know how to minimize dynamic dispatch, know how to efficiently structure cache-friendly memory layouts. And of course, data structures & algorithms 101. I think what s/he meant…

> Julia is not "magically" faster than other languages That's somewhat true, and is at the end-point of some mismatched expectations when folks come to Julia. Julia is a high-level dynamic language whose semantics are conducive to creating the ~same performance as static languages. So if your unoptimized Julia program relies upon traditional "dynamic" features like `Any[]` arrays, then you should expect to see dynami…

> So if your unoptimized Julia program relies upon traditional "dynamic" features like

Dynamic dispatch is slow in any language, including C/C++ (provided that the compiler can't devirtualize the method). This is why such things are never done in an inner loop.

In C++, its harder to "accidentally" use dynamic dispatch because you have to explicitly annotate a function as being virtual. In Julia, which is much more concise, type stability or instability is implicit. But it can be inspected statically via @code_warntype. Good IDE plug-ins can make it easier.

Post reply on HN