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

PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

dev-discuss.pytorch.org

Post reply on HN
Print view View original

171–180 of 291 posts

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#171

Post by FridgeSeal »

Mehdi2277 wrote: post #145
adgjlsfhk1 wrote: post #140

Earlier quoted context omitted.

One of the really nice things with Julia is some of the ecosystem needs disappear. Python needs a lot of ecosystem because none of the packages work together, and the language is slow so you have to make sure you are doing as much work as possible outside the language itself. To answer your question more specifically: Numpy -> Array + broadcasting (both in Julia Base) pytoch/tf -> Flux.jl (package) batch/stream proce…

Good spark support would be a good answer for batch/stream processing. I am a little scared of definition of support. Apache beam supports like 5 runners (flink, spark, data flow, etc) but the quality of runner support is extremely inconsistent. I’ve also noticed even for python flink sometimes have very useful operations only in Java with no wrapper. Although honestly having data pipelines in one language and downst…

> What’s workflow orchestration choice?

We’ve moved away from language-integrated orchestration entirely at my work: we use Argo Workflows on Kubernetes, so we’re just orchestrating containers and aren’t beholden to language-specific requirements anymore so you can use whatever language/tool you want provided it packs into a container and accepts/returns what the rest of the workflow expects.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#172

Post by joconde »

chaxor wrote: post #155
Tarq0n wrote: post #130

Earlier quoted context omitted.

I actually consider that a negative. Mathematical notation is fine when you're dealing with limited space on a blackboard, but if you're programming please name your name variables and take the time to model your domain explicitly.

I don't understand - what is wrong with condensing the python representation `sum_of_lambda_for_each_psi` to `Σλ∀φ`? It seems that 4 symbols is much quicker and easier to read than a slew of snake case stuff.

I'm not completely sure that you aren't joking. Maybe for a mathematician the latter would be "very readable"?

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#173

Post by bjourne »

hpcjoe wrote: post #28
zz865 wrote: post #14

Earlier quoted context omitted.

Wow I hadn't seen deno before, looks great. I dont like js/ts, but if you have to learn it for front end dev, it makes sense to use it at the back too. I'm not sure what advantage Julia has over Python. Yeah it has some typing and can be faster, but its too similar. Still single threaded.

Most definitely not single threaded. From one of my codes # Threaded inner loop, each thread has no dependence upon others Threads.@threads for t=1:Nthr inner_gen_cpu1!(psum,ms,me,cls,2) end That's all you need. You don't need pthread create/join, you don't need installable language extensions, you don't need to appeal to external tools/libraries to enable threading. Its built in to Julia. And it is trivial to use.

But is it real kernel threading or the same kind of cooperative threading that Python also supports?

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#174

Post by elcritch »

bjourne wrote: post #173
hpcjoe wrote: post #28

Earlier quoted context omitted.

Most definitely not single threaded. From one of my codes # Threaded inner loop, each thread has no dependence upon others Threads.@threads for t=1:Nthr inner_gen_cpu1!(psum,ms,me,cls,2) end That's all you need. You don't need pthread create/join, you don't need installable language extensions, you don't need to appeal to external tools/libraries to enable threading. Its built in to Julia. And it is trivial to use.

But is it real kernel threading or the same kind of cooperative threading that Python also supports?

It's real kernel threads. Julia also supports cluster computing too.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#175

Post by dunefox »

ted_dunning wrote: post #54
edgyquant wrote: post #44

Earlier quoted context omitted.

I like what Julia is doing but I just dislike the syntax. It seems to resemble ruby, whose syntax I also think is ugly, which to me resembles a modern form of basic.

Hmmm... this seems to be an odd first impression. There is the use of @ (but to signal macros), but otherwise, the syntax is much closer to a cross between Python and matlab except nicer for doing math. I tried writing a few programs in Julia and got sucked in by how effective it is. The real surprise is that just a few weeks in instead of pulling up R to do a quick calculation my fingers decided they wanted Julia.

Similar story for me. I did last years Advent of code in Julia and it was great.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#176

Post by dunefox »

rackjack wrote: post #152
geofft wrote: post #15

> Julia says: > A language must compile to efficient code, and we will add restrictions to the language (type stability) to make sure this is possible. > A language must allow post facto extensibility (multiple dispatch), and we will organize the ecosystem around JIT compilation to make this possible. > The combination of these two features gives you a system that has dynamic language level flexibility (because you h…

one day OCaml will win ;-;

Not with its Unicode handling.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#177

Post by pjmlp »

xbpx wrote: post #3

Java has a massive ecosystem yet we continue to see rapid replacement of backends in JavaScript (Node now Deno) and Golang. Each of those language ecosystems rapidly became both large (arguably too large) and robust. Rust has been eating C++ lunch. Same rapid rise of ecosystem story. Instead of forcing Python to be a language it isn't it might be more efficient and ultimately the "right choice" to invest the time in…

> Java has a massive ecosystem yet we continue to see rapid replacement of backends in JavaScript (Node now Deno) and Golang.

I guess in some startup scene, it has been Java and .NET over here and no signs of changing, despite the occasional junior projects that eventually get rewritten back into Java/.NET stacks when they move on.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#178

Post by ChrisRackauckas »

longqzh wrote: post #167
jolux wrote: post #126

Earlier quoted context omitted.

Probably not faster in an absolute sense but things like loops in Julia can be properly optimized and will sometimes be more readable than structuring your program entirely around NumPy constructs.

For numpy, it's correct. But numba can optimize the loop. So optimized and readable loop is not an advantage of julia compare to numba.

Not in real-world contexts. This is spelled out in Julia for Biologists (https://arxiv.org/abs/2109.09973) which does the operation counting to show why using Numba with SciPy is still an order of magnitude slower in scientific operations like solving differential equations compared to Julia. An order of magnitude on widely used scientific analyses is pretty significant!

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#179

Post by mbeex »

joconde wrote: post #172
chaxor wrote: post #155

Earlier quoted context omitted.

I don't understand - what is wrong with condensing the python representation `sum_of_lambda_for_each_psi` to `Σλ∀φ`? It seems that 4 symbols is much quicker and easier to read than a slew of snake case stuff.

I'm not completely sure that you aren't joking. Maybe for a mathematician the latter would be "very readable"?

Indeed it is (slight improvements not excluded). I would love to be able to write things like MTA (w/o the HTML rubbish seen here - flavour of the same problem) for two matrices directly as code (can Julia do that?). Instead, I've been forced to learn row and column precedence in OpenGL, DirectX, Numpy, and whatever, paying attention to it in endless constructs.

Even after 25 years in the business, it's still a pain.

Re: PyTorch: Where we are headed and why it looks a lot like Julia (but not exactly)

#180

Post by pjmlp »

rg111 wrote: post #143
stabbles wrote: post #2

What stage of Julia denial is this?

With the slightest hint arising that Julia would be the future of ML and DL, I learned it. But, then what? I could not use it anywhere I worked. The ecosystem was lacking. Julia is good, but for what exactly? People involved with Julia are always big with words, but when will I see it in use somewhere?

You can apply to a job here,

https://juliacomputing.com/case-studies/

Post reply on HN