wondering what kind of performance overhead it is going to cause by letting the kernel to handle unaligned access vs. fixing the software to actually always use aligned access?
Redis on the Raspberry Pi: Adventures in unaligned lands
31–40 of 60 posts
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#32I'm probably the only weirdo that thinks this, but if you support byte-addressing you'd better as well be happy with byte-alignment. Atomics being the only place where it's reasonable to be different.
Which brings me to padding. I wonder what percentage of memory of the average 64-bit user's system is padding? I'm afraid of the answer. The heroes of yesteryear could've coded miracles in the ignored spaces in our data.
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#33I'm probably the only weirdo that thinks this, but if you support byte-addressing you'd better as well be happy with byte-alignment. Atomics being the only place where it's reasonable to be different. Which brings me to padding. I wonder what percentage of memory of the average 64-bit user's system is padding? I'm afraid of the answer. The heroes of yesteryear could've coded miracles in the ignored spaces in our data…
> if you support byte-addressing you'd better as well be happy with byte-alignment
All ARM processors do this. The concept is called "natural alignment" and it's pretty common on non-x86. See e.g. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... . The problem here is that a lot of code written for x86 wants more than that, e.g. byte addressing for non-byte-wide values.
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#34Earlier quoted context omitted.
PowerPC (and POWER) has reasonable hardware support for unaligned memory access, at least for 32-bit data, and if the data is in the data cache. Depending on the processor, the exceptions that reach the OS can be more or less frequent. ARM v6-A and later (except for some microcontrollers, like Cortex M0/R0, that don't support hardware unaligned access at all, triggering a exception) is similar to the Intel x86 case (…
I would say that ARM v6 and later is a major step forward, but is v8 that really seems to be similar to Intel finally. The v6 was able to deal only with single fetch/store unaligned instructions, but things like accessing a double or multiple words with the same instruction would raise an exception.
Accessing unaligned 64 bit data in 32 bit ARM mode can generate exceptions, even in ARM v8 CPUs when running code in 32 bit mode. Full unaligned memory access for 16/32/64/128 bits is only guaranteed in AArch64 mode, if I recall correctly.
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#35I'm probably the only weirdo that thinks this, but if you support byte-addressing you'd better as well be happy with byte-alignment. Atomics being the only place where it's reasonable to be different. Which brings me to padding. I wonder what percentage of memory of the average 64-bit user's system is padding? I'm afraid of the answer. The heroes of yesteryear could've coded miracles in the ignored spaces in our data…
> if you support byte-addressing you'd better as well be happy with byte-alignment All ARM processors do this. The concept is called "natural alignment" and it's pretty common on non-x86. See e.g. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.... . The problem here is that a lot of code written for x86 wants more than that, e.g. byte addressing for non-byte-wide values.
I understand. What I mean is that if your word-size is not your addressing-size, you'd better not have a concept of mis-aligned accesses. It's trouble you brought on all by yourself.
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#36> Redis is adding a “Stream” data type that is specifically suited for streams of data and time series storage, at this point the specification is near complete and work to implement it will start in the next weeks.
This sounds like it could be really exciting. Is there anywhere I can find out more?
Specifically, I've been struggling to find an appropriate backend for HTTP Server-Sent Events, could this feature help with that?
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#37Earlier quoted context omitted.
I would say that ARM v6 and later is a major step forward, but is v8 that really seems to be similar to Intel finally. The v6 was able to deal only with single fetch/store unaligned instructions, but things like accessing a double or multiple words with the same instruction would raise an exception.
Accessing unaligned 64 bit data in 32 bit ARM mode can generate exceptions, even in ARM v8 CPUs when running code in 32 bit mode. Full unaligned memory access for 16/32/64/128 bits is only guaranteed in AArch64 mode, if I recall correctly.
Yes, I think you are right.
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#38> Redis is adding a “Stream” data type that is specifically suited for streams of data and time series storage, at this point the specification is near complete and work to implement it will start in the next weeks. This sounds like it could be really exciting. Is there anywhere I can find out more? Specifically, I've been struggling to find an appropriate backend for HTTP Server-Sent Events, could this feature help…
Hello, please check my two Redis Conf 2017 talks on youtube. There is info about Streams.
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#39Earlier quoted context omitted.
I would say that ARM v6 and later is a major step forward, but is v8 that really seems to be similar to Intel finally. The v6 was able to deal only with single fetch/store unaligned instructions, but things like accessing a double or multiple words with the same instruction would raise an exception.
Accessing unaligned 64 bit data in 32 bit ARM mode can generate exceptions, even in ARM v8 CPUs when running code in 32 bit mode. Full unaligned memory access for 16/32/64/128 bits is only guaranteed in AArch64 mode, if I recall correctly.
For 64-bit ARM (AArch64), load-exclusive/store-exclusive and load-acquire/store-release require aligned addresses. (Seems reasonable to me, trying to handle atomic accesses to aligned data is no fun). You also get a fault for any kind of unaligned access to Device memory, but you're not going to have that unless you're the kernel, and unaligned accesses to hardware registers are definitely not going to work out very well...
(The rules are all fairly clearly documented in the Architecture Reference Manual.)
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#40I'm probably the only weirdo that thinks this, but if you support byte-addressing you'd better as well be happy with byte-alignment. Atomics being the only place where it's reasonable to be different. Which brings me to padding. I wonder what percentage of memory of the average 64-bit user's system is padding? I'm afraid of the answer. The heroes of yesteryear could've coded miracles in the ignored spaces in our data…
Alignment requirements are and have historically been very common -- you can see them on the PDP-11, the 680x0, and so on. It's only because a few very popular architectures like x86 have had very loose or no alignment requirements that we've ended up with a lot of code that assumes there is no alignment requirement, and this has dragged other architectures down the "we need to support this" path. If your architecture faults on misaligned accesses it's really not hard to deal with -- you have to be doing something a bit odd to even run into the problem usually.