One observation: If you're often waking up around 3am, it is a strong indicator for histamine/MCAS issues. This is fairly new research, so most people dont know about it, I haven't had a single doctor yet who was familiar with this.
The mechanism: mast cells (the immune cells that release histamine among other things) have their own circadian clock. The CLOCK gene controls their IgE receptor expression in a time-of-day manner, and both plasma histamine and tryptase peak during the night. In healthy people this is fine. In MCAS or histamine intolerance, this nightly mediator release is excessive, and it happens right in the window where cortisol (which normally suppresses histamine release) bottoms out around 2-4am. Histamine is itself a wake-promoting neurotransmitter, so you get woken up, often by something minor like a noise, reflux, or a temperature shift that wouldn't otherwise register.
Signs it might be worth looking into: 3am waking with a racing heart, sweating, flushing, itching, or reflux/throat tightness.
A good in-depth resource: https://health.programmerlife.org/en/
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
Well I'm a bit of an AMD "fanboy" and really dislike NVIDIA's vendor lock in.
I'm not sure what you mean by dynamic dispatch across GPU backends - nothing should be dynamic there and most easier primitives map quite nicely between vendors (e.g. local memory, work groups etc).
To be honest, the BVH/TLAS has been pretty simple in comparison to the wavefront infrastructure. We haven't done anything fancy yet, but the performance is still really good. I'm sure there are still lots of things we can do to improve performance, but right now I've concentrated on getting something usable out.
Right now, we're mostly matching pbrt-v4 performance, but I couldn't compare to their NVIDIA only GPU acceleration without an NVIDIA gpu. I can just say that the performance is MUCH better than what I initially aimed for and it feels equally usable as some of the state of the art renderers I've been using. A 1:1 comparison is still missing though, since it's not easy to do a good comparison without comparing apples to oranges (already mapping materials and light types from one render to another is not trivial).
To be fair I was suprised too. But I made a relatively simple straight port from the AMD rays sdk plus some input from the pbrt-v4 CPU bvh code and it just worked relatively well out of the box...
This is the main intersection function which is quite simple: https://github.com/JuliaGeometry/Raycore.jl/blob/sd/multityp...
I'm not even using local memory, since it was already fast enough ;)
But I think we can still do quite a lot, large parts of the construction code are still very messy, and I want to polish and modularize the code over time.
I've done lots of manually refactoring of the initial Prototype in Trace.jl (by Anton Smirnov, who I think ported an earlier version of the pbrt book).
This helped familiarizing myself with the math and infrastructure and the general problems a raytracer faces and lay the ground work for the general architecture and what to pay attention to for fast GPU execution. One key insight was, that its possible to not need to have an UberMaterial, but instead use a MultiTypeSet for storing different materials and lights, which allows fast and concretely typed iterations.
Then I found that pbrt moved away from the initial design and I used claude code to port large parts of the new C++ code to Julia. This lead to a pretty bad port and I had lots of back and forth to fix bugs, improve the GPU acceleration, make the code more concise and "Julian" and correct the AIs mistakes and bogus design decisions ;) This polish isn't really over yet, but it works well enough and is fast enough for a beta release!
What prediction? Maybe I need to rephrase what I said: My prediction is, that if Julia ever wants to have a shot at replacing Python, it absolutely has to solve the first time to first x problem!
That's what I mean by shipping fully ahead of time compiled binaries and interpreting more glue code - which both have the potential to solve the first time to x problem.
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 correctness issues compared to other languages I've been using. I think Yuri also has been using lots of packages which haven't been very mature. How on earth can you compare a 10 years old library with lots of maintainers with packages created in one year by one person? That's at least what Yuri's critic boils down to me.
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."
I think the hype has slowed down, but all growth statistics haven't.
Personally, I think Julia is the only language where I can implement something like Makie without running into a maintenance nightmare, and with Julia GPU programming is actually fun and high level and composes well, which I miss in most other languages.
So, I dont really care about it replacing python or not.
I do think for replacing python Julia will need to solve compilation latency, shipping AOT binaries and maybe interpret more of the glue code, which currently introduces quite a lot of compilation overhead without much gains in terms of performance.
Don't quote me on this, but I think there is a "playsinline" / "webkit-playsinline" attribute for the video element you need to add to avoid that, + if it's autoplay you need to set "muted" too. I've also had this happen and I think both/either of those solved it last time.
The mechanism: mast cells (the immune cells that release histamine among other things) have their own circadian clock. The CLOCK gene controls their IgE receptor expression in a time-of-day manner, and both plasma histamine and tryptase peak during the night. In healthy people this is fine. In MCAS or histamine intolerance, this nightly mediator release is excessive, and it happens right in the window where cortisol (which normally suppresses histamine release) bottoms out around 2-4am. Histamine is itself a wake-promoting neurotransmitter, so you get woken up, often by something minor like a noise, reflux, or a temperature shift that wouldn't otherwise register. Signs it might be worth looking into: 3am waking with a racing heart, sweating, flushing, itching, or reflux/throat tightness. A good in-depth resource: https://health.programmerlife.org/en/