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

61–70 of 99 posts

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

#61

Post by minihoster »

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?

> 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 - 1] with length (m - n) or [n, m] with length (m - n + 1). Unless you're doing a bunch of pointer arithmetic type stuff, I find the symmetry of a inclusive-inclusive interval to be a better default.

As a final rebuttal I offer: range(n - 1, -1, -1)

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

#62

Post by vchuravy »

electroly wrote: post #41
vchuravy wrote: post #39

Earlier quoted context omitted.

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

My point is if you set JULIA_CPU_TARGET during the docker build process, you will get relocatable binaries that are multi-versioned and will work on other micro-architecture? It's not just for PackageCompiler, but also for Julia's native code cache.

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

#63

Post by galleywest200 »

badlibrarian wrote: post #26
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?

Versus Python, it seems to fork into the "thinkers" vs "doers" camp. Julia provides a level of abstraction that some people find comforting. I thought I could use it as a sort of open source Matlab for a lot of thinky, 1-based index code I had lying around. It didn't meet my needs. And "spend half an hour waiting for a Jupyter notebook to boot up" is real. Great for some but it's not compatible with the way I work. E…

You should try Pluto.jl over Jupyter for Julia notebooks. It runs all sorts of compilations in the background, as well as handles state much better for Julia.

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

#65

Post by Twisol »

juleiie wrote: post #64

Interesting name. Strange feeling to use language/tech named same as you for some reason and this is a name that isn’t even niche or quirky but like second or third most popular It’s like calling a framework Mike

I have a friend who named their custom-built languages "Monica" and "Joe". It's surprisingly common for homegrown languages, I think.

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

#66

Post by [deleted] »

vchuravy wrote: post #62
electroly wrote: post #41

Earlier quoted context omitted.

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

My point is if you set JULIA_CPU_TARGET during the docker build process, you will get relocatable binaries that are multi-versioned and will work on other micro-architecture? It's not just for PackageCompiler, but also for Julia's native code cache.

[deleted]

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

#67

Post by electroly »

vchuravy wrote: post #62
electroly wrote: post #41

Earlier quoted context omitted.

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

My point is if you set JULIA_CPU_TARGET during the docker build process, you will get relocatable binaries that are multi-versioned and will work on other micro-architecture? It's not just for PackageCompiler, but also for Julia's native code cache.

That was the very first thing I tried, and I couldn't get it to work, but I'm sure I am doing something wrong. Everything seemed great at build time, and then it just precompiles again at runtime, without anything saying why it decided to do that. I'll give it another shot if you say it should be working. The PackageCompiler step is the longest part; if that can be removed, it'll make a big difference. I'd rather be wrong and have this working than the other way around :) I'll report back with what I find.

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

#68

Post by markkitti »

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…

The 0 or 1 based indexing is actually a very superficial debate for people not very familiar with Julia. Note that 1-based indexing is a standard library feature not inherent to the Julia language itself.

The real indexing issue is whether arbitrary-base abstraction is too easily available.

    # Correct, Vector is 1-based
    function mysum(v::Vector{T}) where {T
Basically, the concrete `Vector` type is 1-based. However, `AbstractVector` is could have an arbitrary first index. OffsetArrays.jl is a non-standard package that provides the ability to create arrays with indexes that can start at an arbitrary point including 0.

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

#69

Post by banku_brougham »

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…

>It really isn't.

They way people reveal themselves is a pattern worthy of taking note.

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

#70

Post by fc417fc802 »

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.

Presumably inertia and ecosystem size (but that's a follow on of inertia). When Julia came out Python already had traction for ~most things.

Keep in mind that it went with 1 based indexes to make the switch easy for Matlab types. I'm not sure if that was a good or bad move for the long term. I'm sure it got some people to move who otherwise wouldn't have but conversely there are also people like me who rejected it outright as a result (after suffering at the hands of 1 based indexing in Matlab I will never touch those again if I have any say in the matter).

I've considered switching to it a few times since seeing that they added variable indexes but Python works well enough. Honestly if I were going to the trouble of switching I'd much rather use Common Lisp or R5RS. The nearest miss for me is probably Chicken, where you can seamlessly inline C code but (fatally) not C++ templates.

If I ever encounter "Chicken, except Rust" I will probably switch to that for most things.

Post reply on HN