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

Show HN: A physically-based GPU ray tracer written in Julia

makie.org

Post reply on HN
Print view View original

41–50 of 99 posts

Re: Show HN: A physically-based GPU ray tracer written in Julia

#41

Post by electroly »

vchuravy wrote: post #39
electroly wrote: post #24

Earlier quoted context omitted.

I don't know about everyone else, but slow Julia compilation continues to cause me ongoing suffering to this day. I don't think they're ever going to "fix" this. On a standard GitHub Actions Windows worker, installing the public Julia packages I use, precompiling, and compiling the sysimage takes over an hour . That's not an exaggeration. I had to juice the worker up to a custom 4x sized worker to get the wall clock…

I am very interested in improving the user-experience around precompilation and performance, may I ask why you are creating a sysimage from scratch? > I would opt into prebuilt x86_64 generic binaries if Julia had them The environment varial JULIA_CPU_TARGET [1] is what you are looking for, it controls what micro-architecture Julia emits for and supports multi-versioning. As an example Julia is built with [2]: generi…

I have a monorepo full of Julia analysis scripts written by different people. I want to run them in a Docker container on ephemeral Linux EC2 instances and on user Windows workstations. I don't want to sit through precompilation of all dependencies whenever a new machine runs a particular version of the Julia project for the first time because it takes a truly remarkable amount of time. For the ephemeral Linux instances running Julia in Docker, that happens on every run. Precompiling at Docker build time doesn't help you; it precompiles everything again when you run that container on a different host computer. R and Python don't work like this; if you install everything during the Docker image build, they will not suddenly trigger a lengthy recompilation when run on a different host machine.

I am intimately familiar with JULIA_CPU_TARGET; it's part of configuring PackageCompiler and I had to spend a fair amount of time figuring it out. Mine is [0]. It's not related to what I was discussing there. I am looking for Julia to operate a package manager service like R's CRAN/Posit PPM or Python's PyPI/Conda that distributes compiled binaries for supported platforms. JuliaHub only distributes source code.

[0] generic;skylake-avx512,clone_all;cascadelake,clone_all;icelake-server,clone_all;sapphirerapids,clone_all;znver4,clone_all;znver2,clone_all

Re: Show HN: A physically-based GPU ray tracer written in Julia

#42

Post by leephillips »

Rijanhastwoears wrote: post #40
NoboruWataya wrote: post #8

I don't hear nearly as much about Julia as I used to. A few years ago the view was that it was about to replace Python as the language of choice for data science. Seems like that didn't happen?

Julia is great ... if you are willing to work with the Goldilocks zone it provides. I think what happened is this: Julia got advertised as "Python syntax, C speed" but in practice it turns out to really be "Python syntax, 50% of C speed if you were willing to avoid some semi-well-documented gotchas, where avoiding said gotchas will take some non-trivial effort". Again, great if you are willing to work with it. I am n…

Polyglot Jet Finding:

https://arxiv.org/abs/2309.17309

This paper in experimental high-energy physics is a good example of why Julia is popular for scientific calculations.

It shows that #julialang is over 100 times faster than Python and even faster than C++.

Re: Show HN: A physically-based GPU ray tracer written in Julia

#44

Post by the__alchemist »

The molecule and MD trajectory renders look great and an easy API! I have been doing this in rust, but it's a full program vs something scriptable like this. The images and animations on this page also look a hell of a lot better than what I cobbled together in WGPU.

Re: Show HN: A physically-based GPU ray tracer written in Julia

#45

Post by simondanisch »

Rijanhastwoears wrote: post #40
NoboruWataya wrote: post #8

I don't hear nearly as much about Julia as I used to. A few years ago the view was that it was about to replace Python as the language of choice for data science. Seems like that didn't happen?

Julia is great ... if you are willing to work with the Goldilocks zone it provides. I think what happened is this: Julia got advertised as "Python syntax, C speed" but in practice it turns out to really be "Python syntax, 50% of C speed if you were willing to avoid some semi-well-documented gotchas, where avoiding said gotchas will take some non-trivial effort". Again, great if you are willing to work with it. I am n…

well I've been reaching 100% of c Speed Most of the time which feels like an easy effort... I guess it depends on the problem a bit and how used you're to writing optimized, clean Julia code

Re: Show HN: A physically-based GPU ray tracer written in Julia

#46

Post by Rijanhastwoears »

leephillips wrote: post #42
Rijanhastwoears wrote: post #40

Earlier quoted context omitted.

Julia is great ... if you are willing to work with the Goldilocks zone it provides. I think what happened is this: Julia got advertised as "Python syntax, C speed" but in practice it turns out to really be "Python syntax, 50% of C speed if you were willing to avoid some semi-well-documented gotchas, where avoiding said gotchas will take some non-trivial effort". Again, great if you are willing to work with it. I am n…

Polyglot Jet Finding: https://arxiv.org/abs/2309.17309 This paper in experimental high-energy physics is a good example of why Julia is popular for scientific calculations. It shows that #julialang is over 100 times faster than Python and even faster than C++.

So, my original comment really boils down to the idea that "public perception has nothing to do with objective stats". To which your response is ... citing a paper at me.

To reiterate, citing studies that show that smoking causes cancer in chain smokers does ... nothing. You are citing studies, but I am not the chain smoker; I am just the guy talking about chain smokers.

One more time, I wish we lived in a world where public perception was swayed by objective studies, but we don't.

Julia is fast, yes, but when a university sys-admin rolls their eyes at hearing its name, you have lost the battle for well and good.

Re: Show HN: A physically-based GPU ray tracer written in Julia

#47

Post by ssivark »

NoboruWataya wrote: post #8

I don't hear nearly as much about Julia as I used to. A few years ago the view was that it was about to replace Python as the language of choice for data science. Seems like that didn't happen?

Ugh, this almost feels like flame-bait. This question invariably leads to a lot of bike-shedding around comments from people who feel strongly about some choices in the Julia language (1-based indexing and what not), and the fact that Julia is still not as polished as some other languages in certain aspects of developer experience.

"Data science" is an extremely broad term, so YMMV. That said, since you asked, Julia has absolutely replaced Python for me. I don't have anything new to add on the benefits of Julia; it's all been said before elsewhere. It's just a question of exactly what kind of stuff you want to do. Most of my recent work is math/algorithms flavored, and Python would be annoyingly verbose/inexpressive while also being substantially slower. Julia also tends to have many more high-quality packages of this kind that I can quickly use / build on.

Re: Show HN: A physically-based GPU ray tracer written in Julia

#48

Post by Certhas »

IshKebab wrote: post #35
leephillips wrote: post #32

Earlier quoted context omitted.

Aside from the fact that 1-based indexing is better for scientific code (see Fortran), I don’t think that it matters very often. I don’t think that any Julia program I’ve ever written would need to change if Julia adopted 0-based tomorrow. You don’t typically write C-style loops in Julia; you use array functions and operators, and if you need to iterate you write `for i in array ...`. If you really need the first or…

> the fact that 1-based indexing is better for scientific code (see Fortran) It really isn't. "Scientific code" isn't some separate thing. The only way it can help is if you're trying to write code that matches equations in a paper that uses 1-based indexing. But that very minor advantage doesn't outweigh the disadvantages by a wide margin. Lean doesn't make this silly mistake. > If you really need the first or last…

What if I want the nth element up to the math element? arr[n:m]. And if I want to split the array into two parts, one until the nth element and the other from the m+1st element arr[1:m] and arr[(m+1):end]. Julia matches how people speak about arrays, including C programmers in their comments. Arrays are (conceptually) not pointer arithmetic. Also for your usecase typically you would just use a 2d array and write a[n,:].

Re: Show HN: A physically-based GPU ray tracer written in Julia

#49

Post by Certhas »

simondanisch wrote: post #17
IshKebab wrote: post #14

Earlier quoted context omitted.

IMO it just had too many rough edges. Very slow compilation, correctness issues ( https://yuri.is/not-julia/ ), kinda janky tooling (not nearly as bad as pip tbf). Even basic language mistakes like implicit variable declaration and 1-based indexing (in 2012??). Yes 1-based indexing is a mistake. It leads to significantly less elegant code - especially for generic code - and is no harder to understand than 1-based ind…

lol. There's not much to fight since its a very personal problem how you want to write code. It's evident that all the capable programmers in the Julia community, have found satisfactory ways to get around it, so if you haven't yet, I don't see how that's a Julia problem ;) I can only say I haven't had a single problem with one based indexing in 12 years of developing Julia code. I also haven't run into many correctn…

I disagree. Julia has correctnes issues because it chose maximum composability over specifying interfaces explicitly. And those are not just in immature packages but also in complex packages. Compared to other languages, Julia has no facilities to help structure large complex code bases. And this also leads to bad error messages and bad documentation.

Recently we got the public keyword, but even the PR there says:

"NOTE: This PR is not a complete solution to the "public interfaces are typically not well specified in Julia" problem. We would need to implement much than this to get to that point. Work on that problem is ongoing in Base and packages and contributions are welcome."

Re: Show HN: A physically-based GPU ray tracer written in Julia

#50

Post by IshKebab »

Certhas wrote: post #48
IshKebab wrote: post #35

Earlier quoted context omitted.

> the fact that 1-based indexing is better for scientific code (see Fortran) It really isn't. "Scientific code" isn't some separate thing. The only way it can help is if you're trying to write code that matches equations in a paper that uses 1-based indexing. But that very minor advantage doesn't outweigh the disadvantages by a wide margin. Lean doesn't make this silly mistake. > If you really need the first or last…

What if I want the nth element up to the math element? arr[n:m]. And if I want to split the array into two parts, one until the nth element and the other from the m+1st element arr[1:m] and arr[(m+1):end]. Julia matches how people speak about arrays, including C programmers in their comments. Arrays are (conceptually) not pointer arithmetic. Also for your usecase typically you would just use a 2d array and write a[n,…

> arr[n:m]

arr[n..=m]

> arr[1:m] and arr[(m+1):end]

arr[0..m], arr[m..]

Much nicer.

> Arrays are (conceptually) not pointer arithmetic.

Look at a ruler. Does it start at 1?

Post reply on HN