I don't want to say you should never do this. But if you aren't writing a compiler or an embedded system, you should never do this.
Dynamic language runtimes really like this. It gives you type information without dereferencing the pointer.
Storing data in pointers
31–40 of 71 posts
Re: Storing data in pointers
#32I don't want to say you should never do this. But if you aren't writing a compiler or an embedded system, you should never do this.
Any graph-heavy application constrained by memory potentially gain a lot from those kind of optimizations.
Re: Storing data in pointers
#33"I think it's quite well known that on a 64-bit system, the maximum bit-width
of a virtual address is somewhat lower (commonly 48-bits)." might actually be a perfect example of the Average Framiliarity xkcd[0]. It's perfectly fine to write it that way and the article obviously knows its intended audience. But I'm wondering what percentage of readers here actually knew this beforehand. (I learned it only pretty recently myself. And yes, I should have known this sooner, but ... didn't.)
Re: Storing data in pointers
#34The alpha only accessed 8-byte aligned mem addresses (originally anyway). The bottom 3 bits were ignored (masked out) on lookups, per the spec, to allow users to stuff juicy extra info into these.
Do you have a reference on that? This summary of the Alpha AXP https://danluu.com/dick-sites-alpha-axp-architecture.pdf > states "Normal load or store instructions that specify an unaligned address take a precise data alignment trap to PALcode (which may do the access using two aligned accesses or report a fatal error, depending on the operating system design)"
> Do you have a reference on that?
Yeah, my totally infallible memory.
Thanks for the PDF, nice when somebody provides more than the minimum information. Okay, from the same doc:
The integer load and store quadword unaligned
(LDQ_U, STQ_U) instructions ignore the low three
bits of the byte address and always transfer an
aligned quadword
(edit: oh, you're the author? Didn't realise. Good stuff)
Re: Storing data in pointers
#35"I think it's quite well known that on a 64-bit system, the maximum bit-width of a virtual address is somewhat lower (commonly 48-bits)." might actually be a perfect example of the Average Framiliarity xkcd[0]. It's perfectly fine to write it that way and the article obviously knows its intended audience. But I'm wondering what percentage of readers here actually knew this beforehand. (I learned it only pretty recent…
Article author here. Thanks for calling that out - the intent wasn't to make readers who might not have been aware feel bad. It really came from my worry about being seen to write about something that is trivial and everyone knows already!
Perhaps I'd be better just dropping "I think it's quite well known that"?
Re: Storing data in pointers
#36"I think it's quite well known that on a 64-bit system, the maximum bit-width of a virtual address is somewhat lower (commonly 48-bits)." might actually be a perfect example of the Average Framiliarity xkcd[0]. It's perfectly fine to write it that way and the article obviously knows its intended audience. But I'm wondering what percentage of readers here actually knew this beforehand. (I learned it only pretty recent…
Article author here. Thanks for calling that out - the intent wasn't to make readers who might not have been aware feel bad. It really came from my worry about being seen to write about something that is trivial and everyone knows already! Perhaps I'd be better just dropping "I think it's quite well known that"?
There might be (future) 64 bit systems for which it doesn't hold. So maybe replace "well known" by "widely assumed".
Re: Storing data in pointers
#37"I think it's quite well known that on a 64-bit system, the maximum bit-width of a virtual address is somewhat lower (commonly 48-bits)." might actually be a perfect example of the Average Framiliarity xkcd[0]. It's perfectly fine to write it that way and the article obviously knows its intended audience. But I'm wondering what percentage of readers here actually knew this beforehand. (I learned it only pretty recent…
Article author here. Thanks for calling that out - the intent wasn't to make readers who might not have been aware feel bad. It really came from my worry about being seen to write about something that is trivial and everyone knows already! Perhaps I'd be better just dropping "I think it's quite well known that"?
Hey! First of all: don't worry, it didn't make me feel bad–don't know about others though, of course. And I really meant what I said: I think you knew your (originally) intended audience, and there, the percentage of people is almost certainly quite a lot higher than among general HN readership. I just really like that comic and immediately had to think of it when I read that sentence. (And it's only made funnier by your intention, it really shows how true to life the comic actually is!)
But I think there is a good, general argument to be made against these kinds of sentences. I don't think anyone would ever blame you for writing about a well known thing, while at the same time there is a chance of needlessly making people feel bad.
BUT I also think that with the right "mindset", these kinds of sentences can be a good indicator to readers about what is considered essential, common knowledge among a certain group of people.
So ... I don't think you need to remove it, but wouldn't say it's bad if you did. Sorry for the long winded way of saying basically nothing.
Cool article btw.!
Re: Storing data in pointers
#38Earlier quoted context omitted.
Article author here. Thanks for calling that out - the intent wasn't to make readers who might not have been aware feel bad. It really came from my worry about being seen to write about something that is trivial and everyone knows already! Perhaps I'd be better just dropping "I think it's quite well known that"?
Hey! First of all: don't worry, it didn't make me feel bad–don't know about others though, of course. And I really meant what I said: I think you knew your (originally) intended audience, and there, the percentage of people is almost certainly quite a lot higher than among general HN readership. I just really like that comic and immediately had to think of it when I read that sentence. (And it's only made funnier by…
I've tweaked the wording - thanks again!
Re: Storing data in pointers
#39Earlier quoted context omitted.
It is also very useful for some lockfree algorithms, e.g. to fit a pointer and a sequence number within a 64-bit value.
You should be very careful when doing that. It may be rare in practice, but it's surprisingly easy to trigger ABA issues with only a 16-bit sequence number.
Don't you need 65k threads all contending on the same state for that to happen? Even if your process does have 65k threads, you'd need a pretty large critical section for all of them to be preempted in an unlucky point.
That said, it's better to rely on RCU/hazptr to solve ABA issues, but the extra bits are still useful to store state that can be CAS'd together with the pointer.
Re: Storing data in pointers
#40There's also the Rust library smartstring which allows creating short strings without heap allocations: a Rust string consists of three values (pointer, capacity, length), so 24B on a 64bit architecture. With one byte used as tag this leaves 23 bytes for storing the string in the same space.