Earlier quoted context omitted.
Only because there are no native OpenGL bindings for Java from Khronos, hence LWJGL.
I don't have any experience with Java game development, but I was under the impression that LWJGL provided more than just OpenGL bindings.
Understanding the Odin programming language
131–140 of 163 posts
Re: Understanding the Odin programming language
#132Earlier quoted context omitted.
> You bringing up something unrelated doesn't mean anything just because you keep bringing it up. It's NOT unrelated. It is a real world demonstration of the simplicity possible by custom modeling of allocation and lifetime concerns instead of buying into a fixed scheme set by a language. > There is one singular question and you seem to think it's absurd to answer it and not veer off into a hundred different directio…
It's NOT unrelated. It is a real world demonstration of the simplicity possible by custom modeling of allocation and lifetime concerns instead of buying into a fixed scheme set by a language. No, it's claiming that because someone can do something that there must not be a better way to do it. Games were written in assembly, that doesn't mean that's the best way to do it. I've been arguing all day You've been avoiding…
I can NOT demonstrate it in a tiny godbolt because the effects I am talking about don't apply on a micro-scale.
I CAN demonstrate it with actual source code, but you are unwilling to look it up. You are disagreeing without making the tiniest effort. Not being willing to make an effort by itself is fine. But you're being contrarian in the worst and laziest way.
Do you not understand the concept that I can't explain the world to you from the ground up? You say no to everything without trying to understand it. Your "rebuttals" indicate you're not willing to follow me in the slightest and you reject even the most common lore (for example the thing about C++ class features (destructors, methods...) leading to exposure of internals in public headers, leading to every TU including the world). Or you are intentionally trolling me. You are being uncooperative and you're the single worst interaction I've had on this platform. Now please get off my lawn.
Re: Understanding the Odin programming language
#133Earlier quoted context omitted.
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
#134Earlier quoted context omitted.
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.
Sorry are we referring to the efficiency of generating programs (i.e. optimizing LLM software development) or the efficiency of the output (i.e. optimizing software through the generation of assembly)?
"Programming Language Design and Implementation in the Era of Machine Learning"
Re: Understanding the Odin programming language
#135Earlier quoted context omitted.
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, d…
> On the allocation happy path there is literally less work in case of Java Doing more allocations isn't "less work". No matter how many times you mumble "But it's just a pointer bump" the alternative was no work . > it has chosen different tradeoffs Sure, it's easier to implement this, the New Jersey style. But that's not a benefit to anybody else, so if you're not Sun Microsystems (which you aren't, Sun no longer e…
Re: Understanding the Odin programming language
#136Earlier quoted context omitted.
Memory is memory, stack is not a unique hardware element. It just tends to be hot, but so can certain part of "the heap". Of course this is a toy example, but were the compiler not smart enough (it is surely smart enough in this case) then the "too simple rust" version may actually be slower - it would allocate a Vec on the stack, but only a length, capacity and a pointer is stored there, the actual backing array is…
What tialaramex is saying is that, in the Java code, there will be a separate allocation for every `a_goose` that gets added to the ArrayList, whereas the Rust code only has a single allocation for the backing storage for the Vec (not counting the resizes that occur as the ArrayList/Vec grows (both cases have ways to preallocate the proper size to avoid any resizes)). The context of this subthread is just to explain…
The two are apples and oranges and it makes no sense to compare them -- the latter is severalfold cheaper. Of course this comes at a price (read/write barriers, complex runtime, etc).
> The context of this subthread is just to explain why someone who has Java experience might be prone to overcorrection when it comes to avoiding heap allocations
That's what I don't really understand: if anything, someone with Java experience should be prone to avoid heap allocation in something like Rust as it is more expensive on almost every other platform. This is what I'm talking about, and apparently I wasn't clear.
Re: Understanding the Odin programming language
#137Earlier quoted context omitted.
It's NOT unrelated. It is a real world demonstration of the simplicity possible by custom modeling of allocation and lifetime concerns instead of buying into a fixed scheme set by a language. No, it's claiming that because someone can do something that there must not be a better way to do it. Games were written in assembly, that doesn't mean that's the best way to do it. I've been arguing all day You've been avoiding…
> If you can't demonstrate it with actual source code then you just have claims and no evidence. I can NOT demonstrate it in a tiny godbolt because the effects I am talking about don't apply on a micro-scale. I CAN demonstrate it with actual source code, but you are unwilling to look it up. You are disagreeing without making the tiniest effort. Not being willing to make an effort by itself is fine. But you're being c…
I could tell it was all going to go this way from the second comment, I'm always fascinated by people with rock solid beliefs that can't explain them in any way.
I can NOT demonstrate it in a tiny godbolt because the effects I am talking about don't apply on a micro-scale.
They do because it's just automatic resources within a scope.
I CAN demonstrate it with actual source code, but you are unwilling to look it up.
Why don't you link something besides a name of a big C project and explain it. The idea that someone making a project in C somehow means other features and tools are terrible isn't even logic. That would mean that one project in a language from the 70s would negate every garbage collected and dynamically typed scripting language. It makes no sense in any way. It's like saying because someone road a bike 20 miles cars are terrible.
Do you not understand the concept that I can't explain the world to you from the ground up?
You don't seem to be able to explain anything at all.
You say no to everything without trying to understand it.
You don't give any explanations, they are just claims, do you understand that? Do you know what evidence is? It's the thing you say you can't provide.
You think that somehow something simple like automatically running a function you have to run anyway is a problem, it's nonsense.
By your own logic the fact that https://github.com/chromium/chromium has 1.7 million commits to your project's 4,385 means that modern C++ is more than 380 times as effective.
for example the thing about C++ class features (destructors, methods...) leading to exposure of internals in public headers
That's a matter of dependencies and doesn't have anything to do with destructors.
you're the single worst interaction I've had on this platform.
Now we're to the "I don't like how you're saying it" part of the no evidence playbook. This happens when someone can't admit that they don't have any information and they can't believe that people won't accept them repeating claims as evidence.
Your own project has plenty of the bugs that destructors and contained memory allocation avoid. Raw heap allocations, raw mem copies etc.
https://github.com/EpicGames/raddebugger/issues/855
Here's a complex memory cleanup race condition that's 'solved' with a sleep function. https://github.com/EpicGames/raddebugger/issues/735
even the most common lore
I think it's time to admit to yourself that you have accepted some internet youtuber personalities as a religious belief and that you haven't questioned these beliefs with thoughts that go beyond the claims of the cult.
Re: Understanding the Odin programming language
#138Earlier quoted context omitted.
> If you can't demonstrate it with actual source code then you just have claims and no evidence. I can NOT demonstrate it in a tiny godbolt because the effects I am talking about don't apply on a micro-scale. I CAN demonstrate it with actual source code, but you are unwilling to look it up. You are disagreeing without making the tiniest effort. Not being willing to make an effort by itself is fine. But you're being c…
To recap, there are all sort of detrimental effects to just freeing memory when a variable goes out of scope, but they can't be explained or demonstrated in any way. I could tell it was all going to go this way from the second comment, I'm always fascinated by people with rock solid beliefs that can't explain them in any way. I can NOT demonstrate it in a tiny godbolt because the effects I am talking about don't appl…
First, tone it down a little please, would you? It's not "my project", what is wrong with you?
> ... has plenty of the bugs that destructors and contained memory allocation avoid. Raw heap allocations, raw mem copies etc. https://github.com/EpicGames/raddebugger/issues/735 . Here's a complex memory cleanup race condition that's 'solved' with a sleep function. https://github.com/EpicGames/raddebugger/issues/855
Now you've provided two links and they contain little evidence to back up your claims. Linking issue 735 suggests that you've misunderstood the part about a "Sleep", which evidences either your lack of capacity to grok the context of the issue, or evidences your unhealthy adversarial stance (I strongly suspect the latter).
> You don't give any explanations, they are just claims, do you understand that? Do you know what evidence is? It's the thing you say you can't provide.
You haven't been able to take the most obvious uncontentious claim from me. But if I'm not explaining as you say, what are YOU doing?
Are you seriously too stubborn to accept that exposing a destructor (or any other method) in a header file requires exposing the class's definition (private method declarations including signatures, include internally used headers for internally used data structures, which again have methods, which have dependencies...) in C++? And when any of those not-real-dependencies changes, you have to rebuild everything needlessly? Are you somehow mentally unable to see how long compile times can subtly degrade a project over time?
Because I didn't need any youtuber personality to find that out for myself. And for some humility, the fact that I was able to see that suggests it's not particularly hard to find out.
> Why don't you link something besides a name of a big C project and explain it. The idea that someone making a project in C somehow means other features and tools are terrible isn't even logic. That would mean that one project in a language from the 70s would negate every garbage collected and dynamically typed scripting language.
And also I didn't claim it, you fantasized it and I can't help but ridicule you for having such wild ideas. To make such claims you would actually have a closer look at a project.
> By your own logic the fact that https://github.com/chromium/chromium has 1.7 million commits to your project's 4,385 means that modern C++ is more than 380 times as effective.
How is that by my own logic? But please accept that this is the work of mainly 1-2 persons, and compare _hours_ of build time (35 MLOC) to 3 seconds of build time (300K LOC).
> You think that somehow something simple like automatically running a function you have to run anyway is a problem, it's nonsense.
You are misrepresenting what I've said so badly it's not funny anymore. I've said multiple times that maybe this function shouldn't even exist. And even if the function has to exist, maybe it shouldn't be coupled so hard, at a language level, with the actual state & logic definitions. I did provide reasons why I've perceived the coupling to be an architectural problem.
I would be very open to a discussion when this can or can not be a serious problem and what are possible tradeoffs and points in the design space. It wouldn't make me feel bad and wouldn't take away from my claim that there is actual evidence for the issues being discussed. But with a person like you, that's not possible.
> That's a matter of dependencies and doesn't have anything to do with destructors.
I've explained multiple times why I think it does. If you want a destructor declared in C++, you have to give the full class definition.
> Now we're to the "I don't like how you're saying it" part of the no evidence playbook. This happens when someone can't admit that they don't have any information and they can't believe that people won't accept them repeating claims as evidence.
No, it happens when I can't believe how you haven't managed to stop talking down on me instead of making an effort to be anything other than an annoying adversary. That's all.
> I think it's time to admit to yourself that you have accepted some internet youtuber personalities as a religious belief and that you haven't questioned these beliefs with thoughts that go beyond the claims of the cult.
I think it's time for you to shut up. You are providing zero evidence for your baseless (even counter-factual) accusations towards myself. What you say makes ZERO sense.
Re: Understanding the Odin programming language
#139Earlier quoted context omitted.
Sorry are we referring to the efficiency of generating programs (i.e. optimizing LLM software development) or the efficiency of the output (i.e. optimizing software through the generation of assembly)?
We are referring to not having to use 3GL languages as intermediate step for LLMs to generate native code. "Programming Language Design and Implementation in the Era of Machine Learning" https://www.youtube.com/watch?v=Fc3cW0nqAQ0
Completely understandable why this would be valuable research though. Will be interesting to see how it evolves.
Re: Understanding the Odin programming language
#140Earlier quoted context omitted.
To recap, there are all sort of detrimental effects to just freeing memory when a variable goes out of scope, but they can't be explained or demonstrated in any way. I could tell it was all going to go this way from the second comment, I'm always fascinated by people with rock solid beliefs that can't explain them in any way. I can NOT demonstrate it in a tiny godbolt because the effects I am talking about don't appl…
> Your own project First, tone it down a little please, would you? It's not "my project", what is wrong with you? > ... has plenty of the bugs that destructors and contained memory allocation avoid. Raw heap allocations, raw mem copies etc. https://github.com/EpicGames/raddebugger/issues/735 . Here's a complex memory cleanup race condition that's 'solved' with a sleep function. https://github.com/EpicGames/raddebugge…
I think it's time for you to shut up
you fantasized it
your lack of capacity to grok the context of the issue
Now we're firmly into the insults phase. You can just admit that you don't know about something or that you don't have evidence, or you can ask questions, but resorting to insults instead of just saying "I don't know" or "I haven't considered that" or "I'm fine with what I'm using so I haven't worried about what other people are doing" is unfortunate.
you've misunderstood the part about a "Sleep"
I repeated what was in the comments. This is another example of claims without evidence, you realize that right? You didn't explain it and how I was wrong, you just said "no, nu uh".
3 seconds of build time
Are you talking about build times now? What happened to all the stuff about being terrible for the APIs and so toxic for the whole system that you can't write anything in godbolt?
how you haven't managed to stop talking down on me
Now it's time to play both sides and fling insults but pretend that me asking for evidence is talking down to you.
I've explained multiple times why I think it does. If you want a destructor declared in C++, you have to give the full class definition.
Finally an explanation of some sort. Too bad this isn't true. Do you know that the implementation can be in a compilation unit just like C?
you are providing zero evidence for your baseless (even counter-factual) accusations towards myself. What you say makes ZERO sense.
You believe things without evidence and you have said where they come from. Then when asked for evidence you grasp at anything from insults to completely unrelated things like a single program that you like which demonstrates nothing. Those are the actual facts.