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

261–270 of 291 posts

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

#261

Post by ChrisRackauckas »

cookieater wrote: post #234
ChrisRackauckas wrote: post #227

Earlier quoted context omitted.

>Go beats Julia in parts where python is not good at. I have not seen good results from differential equation solvers in Go.

I don't think you ever will unless Go >2.0 is a completely different language.

Yup exactly. I hate these super general statements like "better ecosystem". These blanket statements obviously make no sense since you can pull out 20,000 counter examples off the top of your head. Instead of "Go beats Julia in parts where python is not good at", name the one example where this might be true, maybe possibly, if there is one (is there is one?) to have a concrete discussion on. The internet and its vacuous statements are better for comedic value than discussion. We're at least on the same page.

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

#262

Post by zigzag312 »

t0mas88 wrote: post #213
xvilka wrote: post #104

Earlier quoted context omitted.

Choice between Java and native languages (for the backend at least) is obvious due to the performance concerns. Same with Python/Julia.

For Java that's mostly a myth. Modern Java isn't measurably slower than C++ in many cases and faster in some.

What about memory usage?

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

#263

Post by Sukera »

humanrebar wrote: post #201
pilooch wrote: post #182

Loving pytorch but the reasoning remains strange to my ears: Python at all cost, not Julia, because of the ecosystem, well OK. But all bullet points are about things that are easily done right now with libtorch (pytorch underlying C++ core code), and the hassle is... Python. Well rational conclusion would be, just do everything in C++, and bind to Python. Make C++ first citizen here, since in all cases it'll be neede…

I happen to know that pytorch is a pain to maintain in packaging systems. It has a complex build system, many non-python dependencies, and massive build times. I don't know how this factors into the dissatisfaction with a C++ implementation, but I wouldn't be surprised if it were a factor. In other words, python binary wheels are harder to maintain than source-only python packages. And pytorch uses more than a few. I…

> The main pain point is probably the lack of standard, multi-environment packaging solutions for natively compiled code.

Are you talking about something like BinaryBuilder.jl[1], which provides native binaries as julia-callable wrappers?

--

[1] https://binarybuilder.org

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

#264

Post by lukego »

ChrisRackauckas wrote: post #195
freemint wrote: post #190

Earlier quoted context omitted.

Running Revise in production sounds unwise (sorry for the pun). Also you can very much not redefine functions on the fly due to world age (assuming the caller doesn't pay for invoke-latest).

You're not doing interactive development on production. Production is the case where you just build a system image and deploy it without compile times. This is done all of the time, for example with Pumas.

This is a binary view of development-verses-production. I appreciate languages that treat this as a continuum and let me make my own trade-offs.

Common Lisp, Smalltalk, and Erlang all treat the process as running indefinitely. This gives those languages a certain something special.

I was hoping to find the same thing in Julia. It's not there. It seems like a significant missed opportunity to me. These dismissive comments make it sound like you guys might not know what you are missing.

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

#265

Post by amkkma »

Daishiman wrote: post #259
nextos wrote: post #128

Earlier quoted context omitted.

In the long run I think moving to Julia would make a lot of sense. I have used MATLAB, R, Python and Julia extensively for doing all sorts of data related things during the last 20 years. Julia is incredibly easy to work with, very elegant and really efficient. R and Python have always felt clumsy in some ways, and hard to write really performant code, even if you are more proficient in Python! As a seasoned Lisper a…

But Julia doesn't have a good story for anything else besides that. You can take a Python web server process, have a request call a task that uses NumPy and OpenCV and scikit-learn, get that back, and you're done, all in the same language. Julia's community does not seem to have aspirations beyond high-performance math code, which is great for its use, but I'm not going to learn Julia just for that when I can impleme…

That's just not true.

https://github.com/GenieFramework/Genie.jl https://github.com/JuliaWeb/HTTP.jl https://www.youtube.com/watch?v=xsxJt4prFG4

And with upcoming improvements to binary size and structured concurrency (it already does go-like lightweight threads) it will get even better.

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

#266

Post by ChrisRackauckas »

lukego wrote: post #264
ChrisRackauckas wrote: post #195

Earlier quoted context omitted.

You're not doing interactive development on production. Production is the case where you just build a system image and deploy it without compile times. This is done all of the time, for example with Pumas.

This is a binary view of development-verses-production. I appreciate languages that treat this as a continuum and let me make my own trade-offs. Common Lisp, Smalltalk, and Erlang all treat the process as running indefinitely. This gives those languages a certain something special. I was hoping to find the same thing in Julia. It's not there. It seems like a significant missed opportunity to me. These dismissive comm…

We legally cannot do things like say live code change the production system underlying the analysis of ongoing clinical trials without going through the whole software development lifecycle required by the FDA (I.e. the Pumas example again), so even if it did exist all a lot of the production systems we're running legally couldn't use it. But also, you can do it with Revise+RuntimeGeneratedFunctions, obviously that solves the mentioned world age issue so I don't see what the fuss is all about? I don't see how offering a solution is dismissive?

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

#267

Post by [deleted] »

dash2 wrote: post #170
JuettnerDistrib wrote: post #166

Earlier quoted context omitted.

You mean, the little ant on the floor? I barfed at 1-based indexing for about a week, but now it is as natural as anything. I would compare 0-based and 1-based indexing with whether you put semicolons at the end of each line or not. Either way doesn't really change the feel (semantics) of the language. Also, fortan is 1-based, iirc, and a lot of numerical code is in fortan. Oh, and many many beginning programmers and…

The reason beginners have a hard time with 0 based indexing is that humans count from 1 . Seriously, I've spent weeks trying to tell people "yeah, we want rows 4 and 5, so that's, uh, rows 3 and 4..." and they think it's nuts, and I now think they're right.

[deleted]

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

#268

Post by joconde »

forrestthewoods wrote: post #114
faizshah wrote: post #77

Earlier quoted context omitted.

I have had the opposite experience with python, the more I use it and learn the standard library and ecosystem the more I love it. What exactly makes you think its a bad language? For me I think the packaging ecosystem is bad, we need one package management tool like poetry built in. We need a built in typing system like typescript. Lastly we need to remove the GIL. I’m pretty sure all of these are currently being ad…

I'd be moderately happy with Python if it had full static typing, improved error handling, fixed packaging, fixed deployment, and removed the GIL. I like to think that containers only exist because deploying a Python application is so %^#(&*# complicated that the easiest way to do is to deploy an entire runtime image. It's an absolute nightmare and travesty. So bad. So very very bad. https://xkcd.com/1987/ I'm not op…

> Oh, and I think the standard library API design is pretty poor. Filesystem has caused me immense pain and suffering. Runtime errors are the worst.

Do you mean os.path, pathlib.Path, or something else? I use pathlib.Path all the time and never get filesystem errors anymore, it's really practical.

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

#269

Post by d0mine »

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?

Python threads are built on top of "real" preemptive OS threads. The presence of the GIL does not change that.

GIL can be released and it is released e.g., for IO, during heavy computations in C extensions--Python program can utilize multiple CPU cores.

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

#270

Post by d0mine »

dgfitz wrote: post #109
queuebert wrote: post #107

Earlier quoted context omitted.

Python is the middle manager of languages. It sucks at everything, but always knows a guy.

I saw a quote once that stuck with me: python is the second best language for everything, first at nothing.

What are the best languages for "executable pseudocode" or "glue language" roles?
Post reply on HN