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

51–60 of 99 posts

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

#51

Post by TimorousBestie »

IshKebab wrote: post #14
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?

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…

Analogous to “time to first plot”, Julia metacommentary now has time to first “Why I no longer. . .” repost.

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

#52

Post by jampekka »

zamalek wrote: post #43

> Cross-vendor GPU support: A single codebase runs on AMD, NVIDIA, and CPU via KernelAbstractions.jl This is why I wish Julia were the language for ML and sci comp in general, but Python is sucking all of the air out of the room.

Maybe because Python can reasonably used to make actual applications instead of just notebooks or REPL sessions.

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

#53

Post by yellowapple »

jampekka wrote: post #52
zamalek wrote: post #43

> Cross-vendor GPU support: A single codebase runs on AMD, NVIDIA, and CPU via KernelAbstractions.jl This is why I wish Julia were the language for ML and sci comp in general, but Python is sucking all of the air out of the room.

Maybe because Python can reasonably used to make actual applications instead of just notebooks or REPL sessions.

What's stopping Julia from being reasonably usable to make actual applications? It's been awhile since I've touched it, but I ain't seeing a whole lot in the way of obstacles there — just less inertia.

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

#54

Post by postflopclarity »

TimorousBestie wrote: post #51
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…

Analogous to “time to first plot”, Julia metacommentary now has time to first “Why I no longer. . .” repost.

I'm even sympathetic to some of the concerns. I say that as someone deeply embedded in the Julia community. but seeing this same repost over and over for years honestly starts to get pretty frustrating.

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

#55

Post by qsi »

bouchard wrote: post #27
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…

> 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 indexing for people capable of programming. Some would argue that 0-based indexing is significantly less elegant for numerical/scientific code, but that depends on whether they come from a MATLAB/Fortran or Python/C(++) background. A decision was made to target t…

Heh. I grew up writing C code and had real trouble adapting to Matlab's 1-based indexing. Much later I tried Python and was constantly confused by 0-based indexing.

I don't think one is better than the other but my mind is currently wired to see indexing with base 1.

Then there's Option Base 1 in VBA if you don't like the default behavior. Perfect for creating subtle off-by-one bugs.

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

#56

Post by mbauman »

IshKebab wrote: post #50
Certhas wrote: post #48

Earlier quoted context omitted.

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?

This is such a classic example of online discourse in general. There are two options, and folks tribally cling to one or the other without realizing that both are legitimate and well-suited for different situations.

Yes, of course distances are measured starting from 0. But we count discrete things starting at 1. You can do mental gymnastics to enumerate from zero and many programmers are (unfortunately IMO) taught to do so. It's a hard thing to learn that way, so for the folks that have done so, it often becomes a point of pride and a shibboleth.

As a classic example, a four story building has four floors. But you only need to go up three flights to get to the top. You can legitimately call the top floor either 3 or 4, and folks are similarly tribal about their own cultural norms around this one, too.

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

#57

Post by zamalek »

yellowapple wrote: post #53
jampekka wrote: post #52

Earlier quoted context omitted.

Maybe because Python can reasonably used to make actual applications instead of just notebooks or REPL sessions.

What's stopping Julia from being reasonably usable to make actual applications? It's been awhile since I've touched it, but I ain't seeing a whole lot in the way of obstacles there — just less inertia.

It's actually better suited IMO, being a compiled language. I'm not sure how anyone could consider the current train wreck of getting python code just to run "actual applications." uv is great and all, but many of these "actual applications" don't use it.

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

#58

Post by IshKebab »

mbauman wrote: post #56
IshKebab wrote: post #50

Earlier quoted context omitted.

> 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?

This is such a classic example of online discourse in general. There are two options, and folks tribally cling to one or the other without realizing that both are legitimate and well-suited for different situations. Yes, of course distances are measured starting from 0. But we count discrete things starting at 1. You can do mental gymnastics to enumerate from zero and many programmers are (unfortunately IMO) taught t…

> There are two options, and folks tribally cling to one or the other without realizing that both are legitimate and well-suited for different situations.

No I disagree entirely. One is simply better.

> It's a hard thing to learn that way, so for the folks that have done so, it often becomes a point of pride and a shibboleth.

It is not hard. It's not better because it's hard-won knowledge. It's better because it leads to simpler, more elegant code. Simple as.

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

#59

Post by mr_octopus »

krastanov wrote: post #4

As an aside, it is really interesting to see a computational package that, while supporting multiple GPU vendors, was first vetted on AMD, not NVidia. It is encouraging to see ROCM finally shaking off its reputation for poor support.

The vendor-agnostic GPU approach via KernelAbstractions is great to see. The Vulkan compute path is underrated for this — it runs on AMD, NVIDIA, and Intel without needing ROCm or CUDA, just whatever driver ships with the GPU.

Re: the compilation latency discussion — it's a real tension. JIT gives you expressiveness but kills startup. AOT gives you instant start but limits flexibility. Interesting that most GPU languages went JIT when the GPU itself runs pre-compiled SPIR-V/PTX anyway.

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

#60

Post by mbauman »

IshKebab wrote: post #58
mbauman wrote: post #56

Earlier quoted context omitted.

This is such a classic example of online discourse in general. There are two options, and folks tribally cling to one or the other without realizing that both are legitimate and well-suited for different situations. Yes, of course distances are measured starting from 0. But we count discrete things starting at 1. You can do mental gymnastics to enumerate from zero and many programmers are (unfortunately IMO) taught t…

> There are two options, and folks tribally cling to one or the other without realizing that both are legitimate and well-suited for different situations. No I disagree entirely. One is simply better. > It's a hard thing to learn that way, so for the folks that have done so, it often becomes a point of pride and a shibboleth. It is not hard. It's not better because it's hard-won knowledge. It's better because it lead…

Thanks for proving my point perfectly.
Post reply on HN