Live data from Hacker News

Understanding the Odin programming language

odinbook.com

101–110 of 163 posts

Re: Understanding the Odin programming language

#101
post #85

Earlier quoted context omitted.

What "work" do we do needlessly? It's a pointer bump. With reclamation being no work. Comparatively a malloc call will have to do extra work to defragment. Also, a stack is not a separate hardware element of the RAM, it's not faster than a sufficiently hot part of the heap - it just so happens that the current stack frame is pretty likely to be in cache.

> What "work" do we do needlessly? It's a pointer bump Any work here was needless. There was no need to do work.

On the allocation happy path there is literally less work in case of Java. Like at least try to get what I'm saying and argue with that - I'm not saying that Java is faster or whatever, but that it has chosen different tradeoffs, and "stack vs heap" is an oversimplified model that doesn't help us understand the real performance impacts.

A pointer bump is a pointer bump, vs a malloc call that will try to find place, do some housekeeping, etc. And your Vec will need at least a single allocation, the backing buffer is not on the stack.

Re: Understanding the Odin programming language

#103

Earlier quoted context omitted.

Apparently you're the school of dismissive person who can't even be bothered to look up their technical achievements.

Confusing achievements in one area for evidence in another is literally an appeal to authority fallacy.

You must mean confusing achievements in the area of creating large maintainable and performant systems on the one hand, with achievements in the area of creating large maintainable and performant systems on the other hand?

And let me incude Ryan Fleury here who graduated from Casey-school with honors, he is maybe the most impressive programmer I know. His work on the raddebugger is outstanding.

Re: Understanding the Odin programming language

#104
post #27

Earlier quoted context omitted.

> My angle is systems programming, and there, it absolutely matter. If you are performance sensitive, then you try to avoid crossing the user-space -> kernel boundary more than you have to. Eg, ask for lots of memory, manage with arenas. This gives the misleading impression that ordinary memory allocators are materially different from arena allocators. They aren't. Both types of allocators first ask for a big block o…

Agreed. IME the main reason to choose arena allocators is for correctness, not speed. They make similar time/space tradeoffs to garbage collectors in that they grant higher allocation throughput in exchange for more memory usage. The perf argument against RAII is very abstract and is less "RAII causes bad performance" and more "the kind of design that leads you to reach for RAII is the kind of design that's bad for p…

> the main reason to choose arena allocators is for correctness, not speed. They make similar time/space tradeoffs to garbage collectors in that they grant higher allocation throughput in exchange for more memory usage.

I'm not quite sure, do you mean arenas are slower, and use more memory, compared to standard vector-style allocation (which does a lot of copying, iterator invalidation, and wastes like 0.25x memory on the average), or compared to individual malloc/free (which does a lot of book-keeping work and wastes book-keeping memory)?

Re: Understanding the Odin programming language

#105
post #61

Earlier quoted context omitted.

Well, Minecraft sold far more and it's a scratch built 3d engine isn't it? Popularity is certainly not a technical achievement.

Minecraft doesn't use an off the shelf engine, but I wouldn't really call Minecraft scratch built. It's built on top of LWJGL. Popularity isn't a technical achievement in itself. But what is a technical achievement is that he built a visually impressive 3d engine that worked well enough for over a million people to buy it at a time when almost no one else was doing this. Minecraft was released nearly 10 years earlier…

Only because there are no native OpenGL bindings for Java from Khronos, hence LWJGL.

Re: Understanding the Odin programming language

#106

Earlier quoted context omitted.

I didn't say they don't know it.

As opposed to using C, Rust, or something else (Jon eventually made Jai but Casey still uses C++). Obviously they don't outright hate it.

See my history regarding my point of view on C or Go.

Yet if my job requires to use C or Go, I like my paychecks, have bills to pay and being proud doesn't pay bills.

Same thing with them, having to use C++ at work, doesn't mean they are big fans of it, indeed the very reason Jai exists is for Jonathan Blow never to use C++ again on his projects.

Re: Understanding the Odin programming language

#107

I've been using Odin for about 6 months now, and to be honest, it's hard to find fault with it. I've used it for STM32 microcontroller firmware, web and desktop applications, and all are performant and compile quickly. My one issue is (and I'm fully aware it will never happen) I do wish there was some sort of first-class solution to inheritance. I've grown to love procedural programming, but some problems really are…

Personally, I have a certain Turbo Pascal feeling while playing around with it, yep I am aware of the influences.

Re: Understanding the Odin programming language

#109

Earlier quoted context omitted.

So, assembly?

That would be less efficient

There are already plenty of PLDI and SIGPLAN talks on LLM => Assembly, with some guardrails for determinism, instead of having a "classical" language as translation layer.

Re: Understanding the Odin programming language

#110
post #25

Earlier quoted context omitted.

Casey Muratori and Jon Blow have pushed this concept frequently. They largely don't deeply elaborate, which is sad because I am a professional game developer who is interested in precisely presented knowledge so I can apply it to my work. My interpretation is that games want to allocate large pools of resources, like GPU buffers, cpu memory, etc, and reuse that memory over and over. Ie: Reinitialize it. In my experie…

> Casey Muratori and Jon Blow have pushed this concept frequently Ah... The school of what I like to call "maximum opinions and minimal evidence". Aggressive arrogant dismissal of anything except their exact view (and for Muratori, you're also "woke" for good measure), coupled with a complete lack of _hard evidence_ to back up their views. In that regard, they're not unlike "investment advice" instagram influencers.

"Aggressive arrogant dismissal of anything except their exact view"

Man, if only someone around here had even if just an inch of self-awareness...

Post reply on HN