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

Julia 1.9

julialang.org

Post reply on HN
Print view View original

181–190 of 216 posts

Re: Julia 1.9

#181

Post by mathisfun123 »

PartiallyTyped wrote: post #179
mathisfun123 wrote: post #174

Earlier quoted context omitted.

well i mean if we redefine all the words so they mean whatever we want them to mean then sure blob code that isn't visible even in the source tree can be considered transparent and conversely, perfectly accessible script code (jax's interpreters) can be considered opaque what do i know i'm just a contrib on both projects shrug lots of your other claims are just complete misunderstandings e.g. whether the graph is cre…

> we redefine all the words I work for AWS; these are the definitions we use, more or less. https://stackoverflow.com/questions/17384020/what-do-transpa... > whether the graph is created at runtime I was specifically referring to the computation graph of the model that is used by autograd. Taken from [1,2]: > Instead, PyTorch uses the operator overloading approach, which builds up a representation of the computed fun…

>I work for AWS; these are the definitions we use, more or less.

you're just being asinine - we're literally talking about binary code that's never seen by anyone that doesn't compile from source and goes digging around in the build dir - how could you possibly call that code "transparent" in any sense of the word? are blob drivers also transparent according to these "AWS" definitions?

>I was specifically referring to the computation graph of the model that is used by autograd.

it's literally right there in bolded text on the first page of the original paper (the 2017 neurips paper):

>Immediate, eager execution. An eager framework runs tensor computations as it encounters them; it avoids ever materializing a “forward graph”, recording only what is necessary to differentiate the computation

autograd has absolutely nothing to do with the graph - autograd is literally 10s of thousands of lines of generated, templatized, code that connects edges one op at a time. you can argue with me all you want or you can just go to repo tip and see for yourself https://github.com/pytorch/pytorch/blob/main/aten/src/ATen/t...

Re: Julia 1.9

#182

Post by dunefox »

cookieperson wrote: post #139
freilanzer wrote: post #130

Earlier quoted context omitted.

Why do you update a programming language version in production with deadlines in the first place?

Because it has a new feature that's save the day(if it worked), fixes bugs in a janky patched Julia version, and production in the data science world looks different in research and development phases then it does for software. Production in r and d can simply be, boss wants to see the pros and cons next week with a successful run. Only with Julia have I run into these kinds of predicaments

Other languages and libraries break as well so that's just bad practice.

Re: Julia 1.9

#183

Post by ziotom78 »

majoe wrote: post #133

I really like "Julia, the programming language" and had a great experience using it on the few occasions, where it made sense. But whenever a colleague asks me, if I can recommend it, I have to say "no". The crux is, that its "just-ahead-of-time" compiler disqualifies it for a lot of use cases: I actually would prefer it over Python for small scripts, but the compilation overhead is too long. On the other hand I woul…

I have the same feelings as you: I stick to Python for tasks that aren't worthy of a long compilation because the execution time would be small, but I always use Julia for computation-intensive tasks.

However, because of this, when somebody asks me if I would recommend Julia to them, instead of answering “no” I just say “it depends”

Re: Julia 1.9

#184

Post by henearkr »

331c8c71 wrote: post #180
henearkr wrote: post #152

Earlier quoted context omitted.

But why should the slice notation be consistent with the range() syntax, which is itself weird? They could have added, in parallel to range(start,end+1), some interval() function that would adopt the more sensible syntax interval(start,end), and then design the slice syntax on this new interval() one. And to begin with, why on Earth is range() using the syntax range(start,end+1)? I honestly can't understand why it wa…

Python's slice/range semantics never occured to be really weird to me because half-open intervals [x,y) are widely used in measure theory textbooks.

How hard can you continue to advocate for this way of asking like: "please count from 0 to 7 excluded"? Ask this to anybody in the street and they'll be confuse why you mentionned 7 if it's excluded! That's natural numbers, not reals!

> measure theory

First of all, even for a specialist, that extremely hard to be delusioned into thinking we're doing measure theory, when we're manipulating indices of arrays/matrices/tensors.

But anyways, assuming you think it's measure theory. I'm trained in the field and that's impossible to expect half-open intervals in this particular place!

To the contrary: the support of base elements of major functional spaces used in measure theory textbooks are always compacts.

Re: Julia 1.9

#185

Post by PartiallyTyped »

mathisfun123 wrote: post #181
PartiallyTyped wrote: post #179

Earlier quoted context omitted.

> we redefine all the words I work for AWS; these are the definitions we use, more or less. https://stackoverflow.com/questions/17384020/what-do-transpa... > whether the graph is created at runtime I was specifically referring to the computation graph of the model that is used by autograd. Taken from [1,2]: > Instead, PyTorch uses the operator overloading approach, which builds up a representation of the computed fun…

>I work for AWS; these are the definitions we use, more or less. you're just being asinine - we're literally talking about binary code that's never seen by anyone that doesn't compile from source and goes digging around in the build dir - how could you possibly call that code "transparent" in any sense of the word? are blob drivers also transparent according to these "AWS" definitions? >I was specifically referring t…

> PyTorch (and Chainer) eschew this tape; instead, every intermediate result records only the subset of the computation graph that was relevant to their computation. This means PyTorch users can mix and match independent graphs however they like, in whatever threads they like (without explicit synchronization). An added benefit of structuring graphs this way is that when a portion of the graph becomes dead, it is automatically freed; an important consideration when we want to free large memory chunks as quickly as possible.

Either I am an absolute fucking moron or this reads that PyTorch keeps track of a graph.

Please explain.

Re: Julia 1.9

#186

Post by kukkukb »

cookieperson wrote: post #116
Sukera wrote: post #101

Earlier quoted context omitted.

Can you be more specific? As is, it's hard to follow what the issue was that you encountered.

At this point the only thing I can say is. Have you ever been a Julia user? Or are you actively developing Julia? If you are actively developing Julia, yea sure pull down the feature branch after someone's reported a bug, hot fix your toml to point too some specific version after reading ten diffs to be sure you have the right one, maybe stand up your own package server or pay 50k for one from julia computing, recomp…

We run Julia code in production. These are compute-heavy services called by other parts of the app. Version upgrades are normally easy. Upgrade, run the unit tests, build the Docker images and deploy to K8s. Maybe we've been lucky, but since 1.3 we've never had big issues with version upgrades.

Re: Julia 1.9

#187

Post by cookieperson »

dunefox wrote: post #182
cookieperson wrote: post #139

Earlier quoted context omitted.

Because it has a new feature that's save the day(if it worked), fixes bugs in a janky patched Julia version, and production in the data science world looks different in research and development phases then it does for software. Production in r and d can simply be, boss wants to see the pros and cons next week with a successful run. Only with Julia have I run into these kinds of predicaments

Other languages and libraries break as well so that's just bad practice.

Not as frequently. Having a broken release for a programming language is also bad practice.

Re: Julia 1.9

#188

Post by cookieperson »

jrockway wrote: post #120
cookieperson wrote: post #80

Earlier quoted context omitted.

Great way to eat a quarter gig of RAM before doing anything on a small compute device...

Probably less RAM than the average browser tab uses. 250MB of RAM? I've forgotten how to count that low. Today's smartphone has higher specs than my $10,000 workstation from 10 years ago.

Compare the Julia repls memory consumption and resources used vs python for using it as a calculator. Looking at orders of magnitude in different resources consumed and time to first anything especially on a computer restrained device...Better yet do the same as the unix tool BC. I am very much aware of when I start tossing quarter to half gbs of RAM on small devices to do things like 1+1=2... Leave two or three of those open by being lazy/forgetful and yea there goes a huge chunk of RAM. To be fair I also don't spend thousands of dollars on the latest phones...

Re: Julia 1.9

#189

Post by cookieperson »

amval wrote: post #151
cookieperson wrote: post #116

Earlier quoted context omitted.

At this point the only thing I can say is. Have you ever been a Julia user? Or are you actively developing Julia? If you are actively developing Julia, yea sure pull down the feature branch after someone's reported a bug, hot fix your toml to point too some specific version after reading ten diffs to be sure you have the right one, maybe stand up your own package server or pay 50k for one from julia computing, recomp…

I run in production several Julia projects and I honestly can't say I know what you are referring to. I do use some libraries through PyCall. This is a relatively frequent source of trouble, with libraries breaking because of 3rd party dependencies, behaviour changing, or even somehow installation suddenly stops working. This all happens in the python side, to the point that I am currently replacing all the libraries…

So much for solving the 2 language problem. Everytime I ended up in a similar situation the Julia code was rewritten either by me or someone else in c++ for practical/performance reasons. Hope you consider the same. The libraries for doing mathematics in C++ are surprisingly good and you might be surprised to find how easy parallel processing and fine tuning is in c++. In some ways it's less cognitive load than Julia because it's more explicit...

Re: Julia 1.9

#190

Post by cookieperson »

kukkukb wrote: post #186
cookieperson wrote: post #116

Earlier quoted context omitted.

At this point the only thing I can say is. Have you ever been a Julia user? Or are you actively developing Julia? If you are actively developing Julia, yea sure pull down the feature branch after someone's reported a bug, hot fix your toml to point too some specific version after reading ten diffs to be sure you have the right one, maybe stand up your own package server or pay 50k for one from julia computing, recomp…

We run Julia code in production. These are compute-heavy services called by other parts of the app. Version upgrades are normally easy. Upgrade, run the unit tests, build the Docker images and deploy to K8s. Maybe we've been lucky, but since 1.3 we've never had big issues with version upgrades.

That's wild, I've seen huge performance regressions from changes to Base, among commands being dropped, irreconcilable breakages with basics of the ecosystem, spurious bugs in the networking libraries that are nearly impossible to chase down, and the menagerie of compatibility with essential packages break. I stopped caring around 1.7 when I realized this was the norm and it wasn't going to change. You must be honed in on some specific packages with a lot of custom code.
Post reply on HN