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

71–80 of 99 posts

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

#71

Post by fc417fc802 »

leephillips wrote: post #32
bouchard wrote: post #27

Earlier quoted context omitted.

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

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…

> Aside from the fact that 1-based indexing is better for scientific code

I find it to be substantially worse. It's fine as long as you don't manipulate the indicies. But as soon as you start doing math on them 1 based becomes a headache (at least IME).

Meanwhile all you get in exchange (at least as far as I can tell) is ease of speaking about them in natural language. But I'm not usually conversing about indicies.

Concise range notations are a mixed bag. There's pros and cons to either scheme there as far as the syntax goes.

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

#72

Post by mathisfun123 »

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.

i hope you realize this is purely because julia uses LLVM and LLVM has backends for those targets (noticeably absent are GPUs which do not have LLVM backends). any other language which uses LLVM could do the same exact same thing (and would be hampered in the exact same way).

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

#73

Post by mathisfun123 »

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.

https://yuri.is/not-julia/

> My conclusion after using Julia for many years is that there are too many correctness and composability bugs throughout the ecosystem to justify using it in just about any context where correctness matters.

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

#74

Post by pjmlp »

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.

https://juliahub.com/case-studies

Most "Python" applications are actually bindings to C, C++ and Fortran code doing the real work.

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

#75

Post by Certhas »

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…

Fully agreed. I first struggled when switching from python to Julia, then ended up finding it slightly better for my use cases (which includes teaching scientists who are not programmers). But it's simply not a big deal either way. I am also reminded of the significant whitespace objections to python in the old days, before python took over everything...

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

#76

Post by Certhas »

minihoster wrote: post #61
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?

> arr[n..=m] so you just need to overload the syntax of intervals even more to make it work > arr[0..m], arr[m..] now `m` refers to different things depending on which side of the interval it's on. less characters doesn't mean nicer I get it though, I was skeptical about 1-based indexing when I started Julia. By the nature of indices vs length there will always be an off-by-one problem: either you have elements [n, m…

Your second point is the main argument for me personally. Numbers in brackets always mean the same thing: the ordinal number of the references object in an ordered collection. In 0 based indexing you can think of the number as refering to the space between the referenced objects. But that is simply an additional mental image on top of the original one.

As a neat bonus, in Julia 1:5 is just the iterator for the numbers 1 to 5. So slicing is typically not some special syntax either. It all works rather nicely.

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

#78

Post by Certhas »

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?

So if I have a row of 5 apples, I can say "take the second and third apple" or I can say "take the apples between one apple length and three apple lengths from the start".

Which is more natural? The ruler is exactly the right mental image if an array to you is a partitioned region of memory starting at a specific pointer location. If an array to you is an ordered collection of objects, you would never invent 0-based indexing or inclusive-exclusive slicing.

Either way, it's not a big deal. I have lived in both worlds, I have come to think Julia is a bit more natural and easier to teach. But it ls really the silliest bike shedding complaint, given that the language has considerable real trade offs.

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

#79

Post by jakobnissen »

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?

Nope. Funnily enough no one can agree on why - if you ask five people, you get six answers.

My own take is that Julia didn’t since the two language problem as much as was defeated by it.

Julia didn’t attract the high-level Python data science crowd because of Julia’s latency issue, lack of package ecosystem, and the inconveniences that a high performance compiled language incurs, such as having parametric containers.

The research software engineer crowds didn’t buy in because Julia has no interfaces or automatically checkable behavior, poor static tooling, imprecise semantics which is hard to build abstraction on, and a complex performance model that makes it hard to ensure speed, and is hard to deploy.

So, where they tried to make a language that can span the gap, they succeeded in making a language that works for neither, and which no-one wants.

I like the language. But after having used it for eight years, I find it increasingly hard to argue against the point that it’s better to choose Rust for software engineering and Python for scripting.

Edit: I should say: I used it for eight years because it IS fine for my specific niche: High performance research software engineering. Where I care neither about the convenience of Python, nor need to write truly robust and maintainable code. Where my choice of language was personal and I didn’t need to convince a team of coworkers.

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

#80

Post by Staross »

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?

I think there's quite a bit of "quiet work" going on that isn't very visible. Personally I've been happily using Julia for work everyday for years. When the language was younger there was "big" updates that were news worthy, now that slowed down, but it seems there's a decent number of people using the language for serious work that is just a bit too specialised for general interest. E.g. in recent registered packages there's a simulation of earth, a method to analyse EEG recording, or a method to measure loudness.

https://github.com/NumericalEarth/NumericalEarth.jl

https://github.com/Marco-Congedo/Xloreta.jl

https://github.com/slink/ZwickerLoudness.jl

Post reply on HN