simondanisch

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/

Me too, 20 years without a single ear infection and without a single day without ear plugs

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

We are working on surface support in Makie to some degree: https://github.com/MakieOrg/Makie.jl/pull/5516 If we get funding, we may also support stuff like NURBS. Obviously, once that gets merged, we do want to also add Raytracing support for it ;)

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.

It's definitely an architectural problem as well. I do wonder if we could extend that though, without too much trouble for the general architecture - after all, the material does not necessarily need to represent all the outside materials and instead the ray only needs to be able to go from one medium to another. I'm happy to chat about possible extensions in that direction, although to be fair I wont have much time in the next weeks to sit down on anything like this. But, I do really hope that this can become a playground for ray tracing experiments in general!

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).

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!

Ah sorry :D

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.

Sorry, I was on my phone. This doesn't seem to be a problem of the description language, but rather how the integrator and materials work internally, so this works the same way in Julia currently. I do think though, that its more approachable to add experimental features like this in the Julia version. Would certainly be an interesting project! I do want to over time get further away from the pbrt-v4 architecture and get to something much more modular and easy to extend. I feel like the overlaps resolve should happen at scene creation time, to not have an expensive priority stack at raytracing time - then it would be just a matter of better tracking the media at boundary crossing. But haven't really thought this through of course ;)

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.

well, I do hate vendor lock in with a passion ;) But yeah, a lot did happen, this likely wouldn't have been possible one or two years ago!

Ugh, yeah I had some super weird bugs like this in safari, still haven't found the source :(

Nope, we made a complete high level Julia interface and I plan to have the Makie API be the main user facing scene description, which can be more descriptive than pbrt I think!

I'm excited to announce Raycore.jl, a high-performance ray-triangle intersection engine with BVH acceleration for both CPU and GPU execution in Julia.

Raycore will power a new raytracing backend for Makie, bringing photorealistic rendering to the ecosystem. We factored out the Ray intersection engine since it can be used in many different areas, so we're very curious to see what the community will create with it and how far we can push the performance over the years. The package includes interactive tutorials covering everything from basics to advanced GPU optimization.

Bonito has been on a journey from being a pretty neglected prototype to something offering similar functionality to established libraries like Shiny/Dash/Streamlit. Read more in the blogpost :)

We're excited to feature some great packages utilizing Makie.jl. From intuitive GUIs and robotic visualizations to interactive apps and dynamic simulation displays, these examples show the wide range of visualizations Makie can bring to any project.

New version and announcements for Makie.jl, Julia's main plotting library.

Apple is a very aggressive and ruthless company... Just look at their lobby activities, how they go against the right to repair and how they generally try to ruthlessly lock you into their ecosystem... So this seems to be pretty much on character for me

How the hell is this not the top post?!

If this wasn't their bread and butter and not an example they picked themselves, it would indeed not be fair... But they chose this example specifically and said this is how you get state of the art performance with Mojo, so...

This is using BenchmarkTools which does most of these things ;) And the numbers are very nicely reproducable. But yes, those benchmarks are hard to compare, especially if they dont run on the same machine! But, there is absolutely no reason to believe that Julia can't get optimal performance on a given hardware knowing Julia's compiler and architecture...This is much more a benchmark of Mojo, which hasn't been proven in that regard.

improving Julia's interpreter and code caching should get you pretty close to that dream language! and it's already a great, existing language with a nice ecosystem :)

We're not using diffing! Diffing has a pretty big overhead for calculating the shadow dom and going through all values and seeing if they're the same, which can be very expensive for huge plots. We use signals that get wired through from the user up to the gpu, so if the user changes something, it gets immediately and directly changed on the gpu too! that's very different from diffing and much faster.. We're surely also not the only ones doing something like that, but Alex is referring to the whole package of Makie offering the ui, performance, simplicity and visuals to do this easily

Polishing the Docs will be a big thing we want to do with better funding :) Improving APIs and recipes is the other big thing planned for this year.

Makie is almost 100% written in Julia and a pretty big library by now... So not so great ^^ But Julia 1.9 now supports caching binary and we also worked a lot on improving compile times, so after `precompiling` Makie (which, admittedly takes a while), time to first plot can be under a second:

julia> @time using GLMakie

  4.954254 seconds (9.99 M allocations: 617.151 MiB, 7.81% gc time, 0.58% compilation time: 39% of which was recompilation)

  0.780343 seconds (672.09 k allocations: 51.171 MiB, 2.08% gc time, 63.66% compilation time)

Makie is a modern plotting library for Julia. It is easy to use, fast and powerful. Packed with features, it is a general-purpose tool that makes as few compromises for specialized use cases as possible.

Try it out today: install Julia and https://julialang.org/downloads and in the Julia REPL run:

]add GLMakie

using GLMakie

scatter(1:4)

Using: https://github.com/facebookresearch/segment-anything/ https://github.com/MakieOrg/Tyler.jl https://docs.makie.org/