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

Handles Are the Better Pointers (2018)

floooh.github.com

Post reply on HN
Print view View original

101–110 of 113 posts

Re: Handles Are the Better Pointers (2018)

#101

Post by [deleted] »

andolanra wrote: post #94
kazinator wrote: post #89

Earlier quoted context omitted.

Ah, but that pointer doesn't get re-used on you until you free it, and for that there are strategies like refcounting and GC. Integers in a small array will get re-used; they have to.

You should probably read the whole article, because it describes strategies for dealing with exactly this problem in the section under Memory safety considerations and then again in the update at the end. The short form is: if you have a bounded size on your array, then you will often have unused bits in your index pointer; you can use these to store a "generation counter", which needs to match the slot. You can now…

[deleted]

Re: Handles Are the Better Pointers (2018)

#102

Post by throwaway17_17 »

thechao wrote: post #100
jerf wrote: post #74

Earlier quoted context omitted.

Yes, as I was typing this up I began to realize that's where I was really going. Essentially turning an entire struct of, say, { int A; string B; Thingy C } into only a set of promises about being able to get an int, a string, a Thingy, etc., and promises around being able to set them (let's just do a struct for now, no methods or hiding), and then decoupling the type , being the set of promises being made, from the…

In a language like Haskell, you'd parameterize every function by both the "data type" and the "data structure": monomorphization will happily emit ABI-compatible functions. I think a more interesting case is how you'd do this without a monomorphization explosion. It seems like being able to describe both subtyping and substructuring relationship ( a la C's structure prefix ABI convention) would keep things mostly in…

I am sure I am missing something, but this thread of comments really got me thinking. I started thinking this was a use case for existential types, but I’m not sure it’s immediately applicable. Then went down a research paper rabbit hole and google binge looking at various ideas. Now I’m sitting here thinking (and I doubt this scotch is making it clearer) that this is sort of like Haskell’s type classes being seen as the ‘Data Type’ level and regular type constructors being seen as the ‘Data Structure’ level. Obviously a language would need to incorporate the class syntax as a less separate construct than it is in Haskell, but I can’t shake the feeling this almost captures the thrust of the concept.

Re: Handles Are the Better Pointers (2018)

#103

Post by andi999 »

jacobush wrote: post #86
andi999 wrote: post #58

Earlier quoted context omitted.

There is no Jai.

There Is Only IBM And AT&T And Exxon?

Could you explain? What I meant, I believe Jai is vaporware and gets too much attention. I mean Jai sound exciting until you find out that the download link is missing.

Re: Handles Are the Better Pointers (2018)

#104

Post by asveikau »

cpr wrote: post #33

Perhaps they should ask the old MacOS toolbox Handle users what they think. (Pretty painful trade-off in the long run, is what I think, having lived through that.)

I think it would be much easier to pull off and work with now than then. The c++ world now has raii and smart pointers, so locking and unlocking could be something the compiler does for you based on scope, all using a pointer syntax.

Re: Handles Are the Better Pointers (2018)

#105

Post by DougBTX »

bluetomcat wrote: post #41
DougBTX wrote: post #39

Earlier quoted context omitted.

That's probably not a bad way to think about it - in an application that large, dealing with lots of data, needing high performance, it is effectively an application-specific database.

On the other hand, think about the improved cache footprint from using 2-byte object handles rather than full-size 8-byte pointers. If the "user code" keeps a lot of those handles in sequential structs, that is a huge win.

Oh, sorry, I didn't mean to be disparaging. What I meant was that if the application needs to handle lots of in-memory data, then thinking of it as an in-memory database seems like a great idea. The ECS architecture seems to be pulling in ideas from column oriented databases, there are probably lots of ideas like that which could be repurposed. (Of course there is the other side of that, which is if you can avoid storing lots of data in-memory at all, possibly using an off-the-shelf relational database, then that's a great approach too.)

Re: Handles Are the Better Pointers (2018)

#106

Post by renox »

zoomablemind wrote: post #80
bluetomcat wrote: post #50

Earlier quoted context omitted.

The "generation counter" suggested in the article has nothing to do with delayed release, as far as I understand. It is used as a strategy to avoid returning colliding handles close in the time domain, reducing the chances for a collision of the "unique bit pattern", which would allow non-detectable dangling access conditions.

> ... non-detectable dangling access conditions. My understanding is that the dangling access conditions potentially arise due to the delayed release of deleted handles. ["... Instead the rendering system would only mark the resource object for destruction when the user code requests its destruction, but the actual destruction happens at a later time when the GPU no longer uses the resource."]

Not necessarily, there's also the "use after free" error, which can happen everywhere..

Re: Handles Are the Better Pointers (2018)

#107

Post by benibela »

muth02446 wrote: post #3

I am surprised that not every large project uses this technique. If you are running on a 64bit system, the use of 32bit handles instead of pointer results in huge memory savings. You can also put the start addressed of the arrays (the handles are indexing into) anywhere in virtual memory and grow them as needed. Finally you can stripe the data for one object into multiple arrays and use the same handle to index each…

Until you get too many objects. That can happy quickly nowadays

Re: Handles Are the Better Pointers (2018)

#108

Post by zero_iq »

andi999 wrote: post #103
jacobush wrote: post #86

Earlier quoted context omitted.

There Is Only IBM And AT&T And Exxon?

Could you explain? What I meant, I believe Jai is vaporware and gets too much attention. I mean Jai sound exciting until you find out that the download link is missing.

It's still under development, with no public release, but I think it's a bit unfair to call it vapourware, since he has produced plenty of material that demonstrates he has a working compiler and has clearly spent a great deal of time developing it, not just talking about it.

Whether it gets too much attention is debatable. He has some good ideas, imo, worth exploring, although I don't agree with all of his opinions. He has a prominent enough profile that it will likely inspire others to incorporate features from Jai if they are seen to be desirable, even if Jai is not ultimately released. (Personally, I think it will eventually.)

Re: Handles Are the Better Pointers (2018)

#109

Post by epistasis »

clucas wrote: post #59
zero_iq wrote: post #55

Earlier quoted context omitted.

Jonathan Blow's new language, Jai, has some control over layout allowing easy switching between array of structs and struct of arrays without having to change the accessing code.

Here is the demo video of the stuff zero_iq is talking about: https://www.youtube.com/watch?v=ZHqFrNyLlpA Basically right on point with what the GP is saying.

That video briefly mentions the CppCon 2014 talk by Mike Afton, "Data-oriented Design and C++". The talk was great, pretty much lined up with how I think of modern systems (treat RAM like disk: seeks take a long time, but streams will likely be able to maximize CPU usage)

But the questions at the end, and the resistance to these basic ideas, roughly "what about platform portability, programmer productivity, etc."; these questions were a bit shocking to me. Is this not a C++ conference? This was six years ago, so perhaps the machine constraints were not as well known back then, but it really shows how strongly the community culture will influence a language and its capabilities.

Re: Handles Are the Better Pointers (2018)

#110

Post by benibela »

asdfasgasdgasdg wrote: post #68
benibela wrote: post #51

Earlier quoted context omitted.

>I was writing an interpreter using shared ptrs all over the place. I am doing that :/ In Object Pascal it is the standard memory management way. All strings and arrays are reference counted, and so I use it for all my own data structures as well I have not even added threading and I doubt I will, but the reference counting is already the slowest part Not sure what the alternative is

You can avoid reference counting overhead by using handles as described in this article. Each object in a slab would have just one reference, and you handles would be indexes into an array of them. Now, after you do that you will be on be hook for making sure you don't accidentally deallocate any of the objects that is currently in use. And it's not guaranteed to be faster. But it is one way to get around this issue.

I do not understand how this would help

It would still need reference counting on the handles to know when the handle is not used anymore and the element in the array can be reused

Without reusing handles it would surely run out of memory. Unless a full GC is used

Post reply on HN