Live data from Hacker News

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

makie.org

91–99 of 99 posts

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

#91
post #74

Earlier quoted context omitted.

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.

And it ... works?

Use C, C++ or Fortran for the heavy lifting, and Python for UI/business logic/non-high perf stuff for rapid app development.

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

#93
There was a meta article a few days back, but HN should do something to rescue ShowHN posts that are neither AIslop nor humanslop because people here seem to report them by default.

They were paid to do this cool thing and possibly to post it here as well but if you dislike "capitalist pigs", maybe you shouldn't browse yc.

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

#94

That post is 10 years old, stale, with all issues resolved and more. Waving around an outdated blogpost as if it would automatically invalidate everything is just silly at this point.

This was supposed to be under a different post. Not the main article. Whops.

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

#95

Earlier quoted context omitted.

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

That's part of the answer, but there's a bit more to it IMO. The syntax is a bit weird; python, swift, rust, and zig feel more parsimonious. I absolutely love multimethods, but I think the language would have been better served by non-symmetric multimethods (rather than the symmetric multimethods which are used). The reason is that symmetric multimethods require a PHD-level compiler implementation. That, in turn, mea…

> The syntax is a bit weird

In what way? It's more-or-less the same syntax as Ruby and Elixir, just with different keywords. Like as much as I love Zig, Zig's syntax is way weirder than Julia's IMO (and none of 'em hold a candle to the weirdness of, say, Erlang or Haskell or Forth or Lisp).

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

#96

Earlier quoted context omitted.

That's part of the answer, but there's a bit more to it IMO. The syntax is a bit weird; python, swift, rust, and zig feel more parsimonious. I absolutely love multimethods, but I think the language would have been better served by non-symmetric multimethods (rather than the symmetric multimethods which are used). The reason is that symmetric multimethods require a PHD-level compiler implementation. That, in turn, mea…

> The syntax is a bit weird In what way? It's more-or-less the same syntax as Ruby and Elixir, just with different keywords. Like as much as I love Zig, Zig's syntax is way weirder than Julia's IMO (and none of 'em hold a candle to the weirdness of, say, Erlang or Haskell or Forth or Lisp).

First, let's distinguish between two types of syntactic constructs: null and left denominations. (Terminology borrowed from Pratt parsers.) Null denominations can exist on their own, left denominations can't -- they are inherently chained (eg arithmetic expressions, statements in a block, or elements of a tuple), and allow a succinct, infix notation for variable-length constructs (no lispy parentheses hell).

Second, null denominations usually introduce names -- whether for variables, types, functions, lifetimes, macros, etc. One exception to this are free-standing value expressions (a bit weird; less so when they're the last expression in a block indicating the value returned by it). Another other exception would be directive type constructs - eg directives to import names from another module, directives to give hints to the compiler, etc. The last two exceptions are the most common ones: variable assignment and function invocation.

The golden rule of good language design, as I see it, is this: null denominations must begin with a fixed and unique token. The only permissible exceptions should be for assignment and function invocation; exceptions which exist because those use-cases appear so often in a typical program that requiring a prefix would be insufferable.

Julia breaks this rule for global variables. (Fair enough, Python also commits this error, but it's a mistake and a source of bugs!) But wait, Julia also has "const" and "local" binding constructs, where it follows the golden rule -- but now your syntax isn't consistent. So now you need to keep in your head these nuances -- and know the difference between a soft and hard scope -- when you want to write a function which modifies a function using macrology.

(As a point of taste on the choice of prefix token: introduction of variables through "local" is just as weird as C++'s "auto" -- and at least Bjarne Stroustroup had an excuse for that choice. Anyone who introduces a global variable in a local scope should be punished imho, so there's no need to say "this is a local variable", it's obvious from the fact that the name is introduced inside a function. Instead, my personal preference is to introduce constants through "let", and variables through "var". The former is well-known to anyone numerate, and the latter is ubiquitous in software engineering. Both read well; they're as close as possible as you can get to constructs in English.)

Julia breaks the golden rule again with its succinct, Mathematica-style notation for function definition. I get that it wants to appeal to Mathematica users, but Python already proved you don't need to do that. This is a programming language; brainy types, like mathematicians and physicists, aren't going to be flummoxed by an unfamiliar notation for function definition, or irritated by having to type a few extra characters.

I mention macrology; it's not just that. Let's say you want write a syntax highlighter -- you need to take into account all that weirdness. If null denominations have a fixed & unique prefix, parsing is easy-peasy. Want to add a capability to "inline" HTML code within Julia, react-style? You're going to run into similar issues. And so on...

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

#97
post #74

Earlier quoted context omitted.

https://juliahub.com/case-studies Most "Python" applications are actually bindings to C, C++ and Fortran code doing the real work.

And it ... works? Use C, C++ or Fortran for the heavy lifting, and Python for UI/business logic/non-high perf stuff for rapid app development.

> And it ... works?

It gets the job done, but the existence of Cython, Numba, Pythran, PyPy and many, many, others are indication that this isn't a global optimum.

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

#98

Earlier quoted context omitted.

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.

It worked! I was able to drop the Windows install on a standard GitHub Actions worker from 1 hour to 27 minutes. Here's what worked: ARG JULIA_CPU_TARGET="generic;skylake-avx512,clone_all;cascadelake,clone_all;icelake-server,clone_all;sapphirerapids,clone_all;znver4,clone_all;znver2,clone_all" ARG JULIA_PROJECT=[...] ENV JULIA_PROJECT=[...] RUN julia -e "using Pkg; Pkg.activate(\"[...]\"); Pkg.instantiate(); Pkg.prec…

... Actually, this only worked for Linux. My Windows container is back to precompiling every time, again, and Windows was the slow one that I wanted to fix in the first place. I had to revert this. Back to the drawing board. I wish Julia would print some diagnostics about why it decided to precompile again.

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

#99

Earlier quoted context omitted.

It worked! I was able to drop the Windows install on a standard GitHub Actions worker from 1 hour to 27 minutes. Here's what worked: ARG JULIA_CPU_TARGET="generic;skylake-avx512,clone_all;cascadelake,clone_all;icelake-server,clone_all;sapphirerapids,clone_all;znver4,clone_all;znver2,clone_all" ARG JULIA_PROJECT=[...] ENV JULIA_PROJECT=[...] RUN julia -e "using Pkg; Pkg.activate(\"[...]\"); Pkg.instantiate(); Pkg.prec…

... Actually, this only worked for Linux. My Windows container is back to precompiling every time, again, and Windows was the slow one that I wanted to fix in the first place. I had to revert this. Back to the drawing board. I wish Julia would print some diagnostics about why it decided to precompile again.

I think I finally nailed it? I needed to update JULIA_DEPOT_PATH since I was relocating the cache files. I knew that and was already doing it, but I didn't do it right: I needed a trailing semicolon so it would have an empty entry at the end! The documentation talks about this but I didn't understand it at the time: https://docs.julialang.org/en/v1/manual/environment-variable...
Post reply on HN