91–100 of 113 posts
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.)
Moving away from pointers and using a shared pool of handles with integer indexes will introduce a whole new array of issues. A plain int carries no information about the validity of the object behind that handle because they are carried around as copies, not references. I remember debugging a regression with UNIX network sockets where valid connections were being killed, and the bug was only triggered under heavy lo…
> A plain int carries no information about the validity of the object behind that handle because they are carried around as copies, not references. The article suggests a handle containing a "plain int" plus a "unique bit pattern", the latter acting like a watermark which is compared to the one in the private array of the corresponding module, preventing dangling accesses. Apart from rare occasional collisions in the…
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…
Earlier quoted context omitted.
> A plain int carries no information about the validity of the object behind that handle because they are carried around as copies, not references. A pointer is just an integer index to a byte in memory in most computing architectures.
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.
Thinking out loud: Since handles refer to offer rather than absolute addresses, this sort of scheme should allow for "serializing" data by memmapping chunks of memory to disk. Obviously, this scheme wouldn't be useful for cross-platform save files, and might not even translate across builds. Still, as long as you have a robust scheme for invalidating data when a new version is deployed, I could see this being useful…
If you wanted pointers out of it after you loaded it you just had a fix-up phase that swapped the offsets for pointers.
We also used the non pointer mmap version on eMMC platforms for really easy ways to store large data while letting the kernel handle the paging with clean pages.
Also forces you to think about data locality which is a powerful thing.
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 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…
Earlier quoted context omitted.
> 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.
Earlier quoted context omitted.
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 underly…
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…
I dunno... seems like you'd be combining all the hard bits of a nominative type system with all the hard bits of a polymorphic structural type subsystem.