Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jai Language Primer

github.com

Post reply on HN
Print view View original

91–100 of 102 posts

Re: Jai Language Primer

#91

Post by CyberDildonics »

pandaman wrote: post #65
autoreleasepool wrote: post #64

Earlier quoted context omitted.

If you're using C++ you're still using default destructors even if you don't write them. In C, you at least get deterministic destruction for variables and structures on the stack. This isn't something you really opt out. It's there by default. The parent was wrong about vector though, it won't safely free elements that do not have their own destructors to clean up their own resources. Another good reason to use RAII…

Default destructors are fine since they don't produce any code as long as you don't have any real destruction going on. >There's zero overhead and you guarantee to be covered in the edge cases where you do end up needing deallocation. If you suddenly find yourself in a position when you need deallocation for something that is not supposed to be dislocated then I'd rather have it fail with as much noise as possible th…

> If you suddenly find yourself in a position when you need deallocation for something that is not supposed to be dislocated then I'd rather have it fail with as much noise as possible than have it covered. E.g. I prefer game crashing on out of memory rather soon than going on with thrashing the heap till it crashes 8 hours into the soak test due to the heap fragmentation.

How would this be different?

> I don't know anybody who would agree with this.

It isn't really something to agree on, in one scenario you have options for automation but don't give up anything, in the other scenario you have no ability to use ownership or scope semantics whether you want to or not.

Re: Jai Language Primer

#92

Post by CyberDildonics »

pandaman wrote: post #68
gregstula wrote: post #66

Earlier quoted context omitted.

> I don't know anybody who would agree with this. std::array is better than int arr[ARR_SIZE] I don't know how you could disagree with that after looking at the facts. From what you're saying here, there seems to be a culture that favors "old school" C programming in games, but the reasons behind it seem like nothing more than a fear of the unknown. I don't mean to be disrespectful, it just seems like nothing but stu…

>std::array is better than int arr[ARR_SIZE] I don't know how you could disagree with that... What is the alignment of your std::array? What is the memory type (e.g. can the GPU read from it at all? Can it write? What are cache policies?). The alternative though is not a C array, it's an explicit memory mapping. >Can you be clear about why this is bad? Useless code at best (if your game runs properly it will never be…

Disregarding the fact that std::array is allocated on the stack, you do realize that running under a debug mode means that there can be bounds checking assertions built into containers like this, not to mention iteration of the elements instead of iteration of the indices (which guarantees not going out of bounds) ?

Re: Jai Language Primer

#93

Post by CyberDildonics »

greggman wrote: post #89
gregstula wrote: post #87

Earlier quoted context omitted.

> Unreal's game-level memory management system uses reflection to implement garbage collection. Yep. Game-level garbage collected C++. Which is exactly what I said, I just a didn't mention GC on C++ to avoid obscuring my point. I promise you the code at the game-engine-level is manually memory managed C++

You do realize that reference counting is considered a form of garbage collection right? https://en.wikipedia.org/wiki/Garbage_collection_(computer_s... BTW: I've written 6 engines for AAA games. 3 of them used reference counting. AAA C++ games use garbage collection all the time. Maybe yours didn't. Mine did. Unreal does. So does Unity

That's like saying World of Warcarft uses garbage collection because it uses Lua. The higher level language on top of an engine isn't what was being talked about since Minecraft was written completely in Java and thus dealt with the garbage collector at every level.

Re: Jai Language Primer

#94

Post by pandaman »

CyberDildonics wrote: post #91
pandaman wrote: post #65

Earlier quoted context omitted.

Default destructors are fine since they don't produce any code as long as you don't have any real destruction going on. >There's zero overhead and you guarantee to be covered in the edge cases where you do end up needing deallocation. If you suddenly find yourself in a position when you need deallocation for something that is not supposed to be dislocated then I'd rather have it fail with as much noise as possible th…

> If you suddenly find yourself in a position when you need deallocation for something that is not supposed to be dislocated then I'd rather have it fail with as much noise as possible than have it covered. E.g. I prefer game crashing on out of memory rather soon than going on with thrashing the heap till it crashes 8 hours into the soak test due to the heap fragmentation. How would this be different? > I don't know…

>How would this be different?

In one case it takes 1-15 minutes to reproduce, in other - 8 hours.

>It isn't really something to agree on, in one scenario you have options for automation but don't give up anything, in the other scenario you have no ability to use ownership or scope semantics whether you want to or not.

Judging by your previous question I figure you don't ship games, do you?

Re: Jai Language Primer

#95

Post by pandaman »

CyberDildonics wrote: post #92
pandaman wrote: post #68

Earlier quoted context omitted.

>std::array is better than int arr[ARR_SIZE] I don't know how you could disagree with that... What is the alignment of your std::array? What is the memory type (e.g. can the GPU read from it at all? Can it write? What are cache policies?). The alternative though is not a C array, it's an explicit memory mapping. >Can you be clear about why this is bad? Useless code at best (if your game runs properly it will never be…

Disregarding the fact that std::array is allocated on the stack, you do realize that running under a debug mode means that there can be bounds checking assertions built into containers like this, not to mention iteration of the elements instead of iteration of the indices (which guarantees not going out of bounds) ?

std::array is not necessarily allocated on the stack, it's only allocated on the stack when it's a local variable. So I realize what it is and what it does. Do you realize that you have little control over where its memory goes and there are very different types of memory available to games? Do you know what is memory alignment? Do you realize you cannot grow/shrink it? Do you realize you can still do bounds checks if you need them?

Re: Jai Language Primer

#96

Post by CyberDildonics »

pandaman wrote: post #95
CyberDildonics wrote: post #92

Earlier quoted context omitted.

Disregarding the fact that std::array is allocated on the stack, you do realize that running under a debug mode means that there can be bounds checking assertions built into containers like this, not to mention iteration of the elements instead of iteration of the indices (which guarantees not going out of bounds) ?

std::array is not necessarily allocated on the stack, it's only allocated on the stack when it's a local variable. So I realize what it is and what it does. Do you realize that you have little control over where its memory goes and there are very different types of memory available to games? Do you know what is memory alignment? Do you realize you cannot grow/shrink it? Do you realize you can still do bounds checks i…

If you need to grow or shrink it use a vector. If you need different types of memory or aligned memory, make an allocator and use that. Many people do, it is a very common use of allocators. Even if you don't want to use the STL you can encapsulate all of these things for reuse and modularity.

I'm not exactly sure why you think these things aren't achievable in C++ (and because they are achievable they are relatively straightforward to wrap in a way that they can be made generic while hiding the complexity so you can be done with it). I've even made variadic templates that fuse memory allocations together like Jai's proposed feature.

I've seen people who know C and seem forever hung up on it. It isn't really rationale these days now that there are C++11 compilers that are so mature. It's almost as if there are people who work in a constantly advancing field but don't want to learn anything new.

Re: Jai Language Primer

#97

Post by CyberDildonics »

pandaman wrote: post #94
CyberDildonics wrote: post #91

Earlier quoted context omitted.

> If you suddenly find yourself in a position when you need deallocation for something that is not supposed to be dislocated then I'd rather have it fail with as much noise as possible than have it covered. E.g. I prefer game crashing on out of memory rather soon than going on with thrashing the heap till it crashes 8 hours into the soak test due to the heap fragmentation. How would this be different? > I don't know…

>How would this be different? In one case it takes 1-15 minutes to reproduce, in other - 8 hours. >It isn't really something to agree on, in one scenario you have options for automation but don't give up anything, in the other scenario you have no ability to use ownership or scope semantics whether you want to or not. Judging by your previous question I figure you don't ship games, do you?

I meant how would the error somehow happen more slowly using an STL data structure than in C?

> I figure you don't ship games, do you

No, I only write them, I've found it's a lot easier to let someone else handle the distribution.

Re: Jai Language Primer

#98

Post by pandaman »

CyberDildonics wrote: post #97
pandaman wrote: post #94

Earlier quoted context omitted.

>How would this be different? In one case it takes 1-15 minutes to reproduce, in other - 8 hours. >It isn't really something to agree on, in one scenario you have options for automation but don't give up anything, in the other scenario you have no ability to use ownership or scope semantics whether you want to or not. Judging by your previous question I figure you don't ship games, do you?

I meant how would the error somehow happen more slowly using an STL data structure than in C? > I figure you don't ship games, do you No, I only write them, I've found it's a lot easier to let someone else handle the distribution.

>I meant how would the error somehow happen more slowly using an STL data structure than in C?

That I don't know. As I said, I was only talking about deallocation of arrays that were not supposed to be deallocated.

Re: Jai Language Primer

#99

Post by pandaman »

CyberDildonics wrote: post #96
pandaman wrote: post #95

Earlier quoted context omitted.

std::array is not necessarily allocated on the stack, it's only allocated on the stack when it's a local variable. So I realize what it is and what it does. Do you realize that you have little control over where its memory goes and there are very different types of memory available to games? Do you know what is memory alignment? Do you realize you cannot grow/shrink it? Do you realize you can still do bounds checks i…

If you need to grow or shrink it use a vector. If you need different types of memory or aligned memory, make an allocator and use that. Many people do, it is a very common use of allocators. Even if you don't want to use the STL you can encapsulate all of these things for reuse and modularity. I'm not exactly sure why you think these things aren't achievable in C++ (and because they are achievable they are relatively…

>If you need to grow or shrink it use a vector.

Thank you for the advise but what if I want to shrink one array that takes 200 MB of memory by 10MB and give it to another array that takes 50 MB of memory on a system with only 256 MB of memory?

> If you need different types of memory or aligned memory, make an allocator and use that.

std::array does not have allocators.

>I'm not exactly sure why you think these things aren't achievable in C++

I have no idea why you think so. I only used C++, assembly and various shader languages in every game I worked on. I did some C in drivers but I don't think it's a good language for games.

Re: Jai Language Primer

#100

Post by CyberDildonics »

pandaman wrote: post #99
CyberDildonics wrote: post #96

Earlier quoted context omitted.

If you need to grow or shrink it use a vector. If you need different types of memory or aligned memory, make an allocator and use that. Many people do, it is a very common use of allocators. Even if you don't want to use the STL you can encapsulate all of these things for reuse and modularity. I'm not exactly sure why you think these things aren't achievable in C++ (and because they are achievable they are relatively…

>If you need to grow or shrink it use a vector. Thank you for the advise but what if I want to shrink one array that takes 200 MB of memory by 10MB and give it to another array that takes 50 MB of memory on a system with only 256 MB of memory? > If you need different types of memory or aligned memory, make an allocator and use that. std::array does not have allocators. >I'm not exactly sure why you think these things…

I've lost track of your point all together, are you still trying to say there is utility in raw arrays?

You can't possibly think memory allocation problems that are solved by custom allocators can be dismissed because std::array doesn't take an allocator when that it integral to the entire reason it exists. Are you trying to say that not only do you want aligned static memory but that there is nothing that exists that helps over a raw C array?

Post reply on HN