5 ms·

... and now you have to synchronize access to your handle table, grow it to meet demand -- let me tell you, that is a fun thing to do when there are thousands o

by kabdib 8y ago

... and now you have to synchronize access to your handle table, grow it to meet demand -- let me tell you, that is a fun thing to do when there are thousands of things in flight, all expecting high performance -- and so on. And what NUMA node was that big global array on? Hmmm, I guess you could partition it, but it's kind of awkward and you have to recompute the geometry on every launch and where did you stash that information? TLS? The natural thing for a context type is something that can be used to directly refer to any object. In today's common architectures this is a pointer. Context APIs that don't support "intptr" or something like it are broken.

jstimpfle 8y ago
I don't disagree. I might be in the minority but personally I don't do OS threads as far as possible. They are hard. (And I don't do fibers, either, if I have a choice). But if you do threads, then you could still put that "handle table" into TLS, couldn't you?
jstimpfle 8y ago
> The natural thing for a context type is something that can be used to directly refer to any object. In today's common architectures this is a pointer. Context APIs that don't support "intptr" or something like it are broken. I want to note the huge disadvantage of using pointers, which is that they aren't mathematical identities, but physical identities. It's place vs value. If you use pointers you are absolutely required to have stable addresses, which means you cannot treat data as what it is: information - and you cannot copy it, move it, duplicate and modify it and such. Because the best handle to it that you have is the memory address where it's supposed to live. You cannot even have parallel arrays (which give modularity) but will end up with god objects amassing unwashed unsorted unrelated incoherent junk data because that's the best to get from an address to actual data. While there are valid uses for pointers (and I don't claim to have any relevant experience with threaded applications), today's popular idea that "something that can be used to refer to any object" is best implemented by a pointer is what really leads to terrible, unmaintainable software.
- shawnz 8y ago
  Why are stable addresses a problem when you have virtual memory? And even if you didn't, couldn't you just use pointers to pointers?
  - jstimpfle 8y ago
    It's an idea I've had for a long time for my applications where (almost) all dynamically are global arrays. 64-bit application have a huge address space and I could simply place each array in a huge subsequence of this address apce. When an array needs to grow I simply mmap() more memory at the end, so I never have to move memory, and all pointers stay valid. I try to avoid pointers to pointers because of the redirection. They are not really solving a problem but only delaying it, at the cost of performance. But first and foremost the biggest problem with pointer is the identity thing. Using a pointer to access various kinds of information either requires that all this information is clumped together (loss of modularity) or at least that we maintain additional lookup structures that bind the disparate information together through indirection (loss of performance, more memory use, more code, and still some loss of modularity).
    - shawnz 8y ago
      > I try to avoid pointers to pointers because of the redirection. They are not really solving a problem but only delaying it, at the cost of performance. Passing an array index and doing an array lookup is also a form of indirection. How is that any different than passing a pointer and doing a pointer dereference? Either way you are not passing the value itself, you are passing a value that represents some kind of memory offset where the real data is stored. It's just that with the array approach, it is a relative offset rather than an absolute one. > Using a pointer to access various kinds of information either requires that all this information is clumped together (loss of modularity) Why does putting all the information together imply a loss of modularity? You could have structs inside structs, defined in separate files, and there would still be no need to dereference twice. Their values will just be stored as part of the enclosing struct's values automatically. You could even reference the specific sub-structs with pointers if you want to keep your modules unaware of the enclosing struct type. Example: https://onlinegdb.com/BJLxqWhuV https://onlinegdb.com/BJLxqWhuV

by kabdib 8y ago

jstimpfle 8y ago

I don't disagree. I might be in the minority but personally I don't do OS threads as far as possible. They are hard. (And I don't do fibers, either, if I have a choice). But if you do threads, then you could still put that "handle table" into TLS, couldn't you?

jstimpfle 8y ago

> The natural thing for a context type is something that can be used to directly refer to any object. In today's common architectures this is a pointer. Context APIs that don't support "intptr" or something like it are broken. I want to note the huge disadvantage of using pointers, which is that they aren't mathematical identities, but physical identities. It's place vs value. If you use pointers you are absolutely required to have stable addresses, which means you cannot treat data as what it is: information - and you cannot copy it, move it, duplicate and modify it and such. Because the best handle to it that you have is the memory address where it's supposed to live. You cannot even have parallel arrays (which give modularity) but will end up with god objects amassing unwashed unsorted unrelated incoherent junk data because that's the best to get from an address to actual data. While there are valid uses for pointers (and I don't claim to have any relevant experience with threaded applications), today's popular idea that "something that can be used to refer to any object" is best implemented by a pointer is what really leads to terrible, unmaintainable software.

shawnz 8y ago
Why are stable addresses a problem when you have virtual memory? And even if you didn't, couldn't you just use pointers to pointers?
- jstimpfle 8y ago
  It's an idea I've had for a long time for my applications where (almost) all dynamically are global arrays. 64-bit application have a huge address space and I could simply place each array in a huge subsequence of this address apce. When an array needs to grow I simply mmap() more memory at the end, so I never have to move memory, and all pointers stay valid. I try to avoid pointers to pointers because of the redirection. They are not really solving a problem but only delaying it, at the cost of performance. But first and foremost the biggest problem with pointer is the identity thing. Using a pointer to access various kinds of information either requires that all this information is clumped together (loss of modularity) or at least that we maintain additional lookup structures that bind the disparate information together through indirection (loss of performance, more memory use, more code, and still some loss of modularity).
  - shawnz 8y ago
    > I try to avoid pointers to pointers because of the redirection. They are not really solving a problem but only delaying it, at the cost of performance. Passing an array index and doing an array lookup is also a form of indirection. How is that any different than passing a pointer and doing a pointer dereference? Either way you are not passing the value itself, you are passing a value that represents some kind of memory offset where the real data is stored. It's just that with the array approach, it is a relative offset rather than an absolute one. > Using a pointer to access various kinds of information either requires that all this information is clumped together (loss of modularity) Why does putting all the information together imply a loss of modularity? You could have structs inside structs, defined in separate files, and there would still be no need to dereference twice. Their values will just be stored as part of the enclosing struct's values automatically. You could even reference the specific sub-structs with pointers if you want to keep your modules unaware of the enclosing struct type. Example: https://onlinegdb.com/BJLxqWhuV https://onlinegdb.com/BJLxqWhuV