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

51–60 of 113 posts

Re: Handles Are the Better Pointers (2018)

#51

Post by benibela »

codr7 wrote: post #35
asdfasgasdgasdg wrote: post #26

Earlier quoted context omitted.

Weak_ptr in C++ only applies to shared_ptr, which is not used for most C++ pointers. Because of the atomic ops done on each copy, in performance sensitive contexts people aren't going to be using it.

Been there, done that. I was writing an interpreter using shared ptrs all over the place. Performance was fine until I linked pthreads, at which point it took a nosedive forcing me to refactor the entire project. No one really tells you this. People will say don't use shared ptrs because they're slow, which is far from the whole truth. They're pretty darn fast as long as you don't enable threading.

>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

Re: Handles Are the Better Pointers (2018)

#52

Post by svrb »

jerf wrote: post #47
epistasis wrote: post #42

Earlier quoted context omitted.

Everything I read these days seems to trend towards columnar stores... I write a mixture of R, Python, C and C++, in that order of prevalence, and mostly for data intensive tasks. After nearly two decades of unlearning loops and implementing instead with FP idioms, vectorization, and matrix multiplies to take advantage of R's strengths, I often have trouble recreating R's performance when I first reimplement in C or…

In my Perfect Programming Language That Doesn't Have To Deal With The Problems Of Actually Existing, serialization of data structures into memory is explicitly defined in the language, just as one would define a JSON or Protobuf serialization. One could define a "Point3{x,y,z}", and hypothetically define one array of them in the conventional manner, define another array as a columnar serialization, and potentially ev…

Sign me up! I'm constantly defining `XYZ` and `PackedXYZ` for memory-bound problems and I have often though it would be nice to be able to do this (in a more generic way than mere bitfields). It never occurred to me that it could be extended to column stores though.

Re: Handles Are the Better Pointers (2018)

#53

Post by gumby »

jagger27 wrote: post #5
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…

> you can stripe the data for one object into multiple arrays and use the same handle to index each of them which can improve locality. I wish programming languages made it easy to structure arrays of objects like this. I think Johnathan Blows’s JAI has some kind of transparent support for SoA.

It’s trivial to do this in C++ and often the caller doesn’t even realize.

Re: Handles Are the Better Pointers (2018)

#55

Post by zero_iq »

jerf wrote: post #47
epistasis wrote: post #42

Earlier quoted context omitted.

Everything I read these days seems to trend towards columnar stores... I write a mixture of R, Python, C and C++, in that order of prevalence, and mostly for data intensive tasks. After nearly two decades of unlearning loops and implementing instead with FP idioms, vectorization, and matrix multiplies to take advantage of R's strengths, I often have trouble recreating R's performance when I first reimplement in C or…

In my Perfect Programming Language That Doesn't Have To Deal With The Problems Of Actually Existing, serialization of data structures into memory is explicitly defined in the language, just as one would define a JSON or Protobuf serialization. One could define a "Point3{x,y,z}", and hypothetically define one array of them in the conventional manner, define another array as a columnar serialization, and potentially ev…

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.

Re: Handles Are the Better Pointers (2018)

#57

Post by throwaway894345 »

epistasis wrote: post #42
twoodfin wrote: post #7

There should be a minor law in the spirit of Greenspun’s tenth rule: Every sufficiently performance-sensitive system eventually grows some version of a slab allocator[1]. There’s really no substitute for packing fixed-sized objects together in N big array chunks. If you can operate in a particular context (or entirely) with N=1, you can substitute handles for pointers. For any reasonable # of objects, those handles c…

Everything I read these days seems to trend towards columnar stores... I write a mixture of R, Python, C and C++, in that order of prevalence, and mostly for data intensive tasks. After nearly two decades of unlearning loops and implementing instead with FP idioms, vectorization, and matrix multiplies to take advantage of R's strengths, I often have trouble recreating R's performance when I first reimplement in C or…

Typically functional programming isn’t considered to be CPU friendly. Specifically typical functional programming allocates memory all over the heap, especially given the prevalence of things like linked lists and so on. This obviously makes for crumby cache performance and memory pressure. I’m not sure in what sense FP lends itself to columnar data structures, but those would obviously have still better cache and vectorization properties. I’d be curious to learn more!

Re: Handles Are the Better Pointers (2018)

#58

Post by andi999 »

zero_iq wrote: post #55
jerf wrote: post #47

Earlier quoted context omitted.

In my Perfect Programming Language That Doesn't Have To Deal With The Problems Of Actually Existing, serialization of data structures into memory is explicitly defined in the language, just as one would define a JSON or Protobuf serialization. One could define a "Point3{x,y,z}", and hypothetically define one array of them in the conventional manner, define another array as a columnar serialization, and potentially ev…

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.

There is no Jai.

Re: Handles Are the Better Pointers (2018)

#59

Post by clucas »

zero_iq wrote: post #55
jerf wrote: post #47

Earlier quoted context omitted.

In my Perfect Programming Language That Doesn't Have To Deal With The Problems Of Actually Existing, serialization of data structures into memory is explicitly defined in the language, just as one would define a JSON or Protobuf serialization. One could define a "Point3{x,y,z}", and hypothetically define one array of them in the conventional manner, define another array as a columnar serialization, and potentially ev…

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.

Re: Handles Are the Better Pointers (2018)

#60

Post by thechao »

jerf wrote: post #47
epistasis wrote: post #42

Earlier quoted context omitted.

Everything I read these days seems to trend towards columnar stores... I write a mixture of R, Python, C and C++, in that order of prevalence, and mostly for data intensive tasks. After nearly two decades of unlearning loops and implementing instead with FP idioms, vectorization, and matrix multiplies to take advantage of R's strengths, I often have trouble recreating R's performance when I first reimplement in C or…

In my Perfect Programming Language That Doesn't Have To Deal With The Problems Of Actually Existing, serialization of data structures into memory is explicitly defined in the language, just as one would define a JSON or Protobuf serialization. One could define a "Point3{x,y,z}", and hypothetically define one array of them in the conventional manner, define another array as a columnar serialization, and potentially ev…

I was privy to a fairly high-wattage conversation between Walid Taha, Jeremy Siek, Todd Veldhuizen, et al, where they discussed this issue at length. They were concerned that languages almost universally equate data types with data structures. Their opinion (drunkenly expressed) was that the program semantics should be based on both. The wrinkle was was happened if you wanted to expose transformations of the underlying structure against the type when trying to say something reasonable about escape hatches.

If I had a PPLTDHTWTPOAE (?) it'd have this capability for sure.

Post reply on HN