Live data from Hacker News

Redis on the Raspberry Pi: Adventures in unaligned lands

antirez.com

51–60 of 60 posts

Re: Redis on the Raspberry Pi: Adventures in unaligned lands

#51
post #38
post #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…

Hello, please check my two Redis Conf 2017 talks on youtube. There is info about Streams.

Did my enhancement make it into the skip list implementation being used for the STREAM type? I am hoping it would be in place before you publish benchmarks for it.

https://github.com/antirez/redis/pull/3889

Re: Redis on the Raspberry Pi: Adventures in unaligned lands

#52
post #43

Earlier quoted context omitted.

Even today, allowing unaligned accesses is still not free -- there is an implementation cost in transistors and in design complexity. There's a tradeoff here, as usual. There are a lot of places with a CPU architecture where there's a choice of "do we handle this in hardware, at the cost of having to have more hardware, or do we say it's software's job to deal with this, and hardware provides either nothing or just s…

You sound like an architecture person (I'm not, btw), so maybe you can give the lowdown on this. Why registers? I haven't studied the Tomasulo algorithm in any detail, but if you're going to do "register renaming", why have registers at all? You could, for example, treat memory as a if-needed-only backing store, and then add a "commit" instruction that commits memory (takes an address, or a range). Sure you need to m…

Because that would require longer instructions and thus more memory.

Instructions on a CPU are something like to following (this is based on MIPS since x86 is a mess) The first 6 bits are the instruction, the rest is command specific. For add the next 12 would be 4 bits for each of the source registers and then the destination register and then various flags (overflow for example).

If instead they only worked on memory they would have a lot more possible instructions - but there isn't enough room on CPUs to design that many instructions anyway so who cares, followed by the all three memory addresses. This means that every CPU instruction needs to read 3 times as much memory before doing anything. Worse, most of those are pointers: when you compile the code you don't know the location of those address, so in most cases it is read the instruction from the program, then go back to the stack to read the address of the next values, then read those locations. That is a lot of memory access and memory access is expensive. Of course as you can say you can just use caching, but cache is expensive and now you need to add 3 times as much - this is too big for the fast level one cache so now you are expanding level two cache and seeing a lot more cache misses in the level one cache.

The above would all be okay, but it turns out that given enough registers (x86 fails here) in most cases you are operating on the same set of values all the time, (indeed the stack locations each of the above is referring too is probably a small set of variables) so if the compiler is careful it can manage all that. The compiler has better information on when things need to be committed to memory anyway so let it handle that.

Re: Redis on the Raspberry Pi: Adventures in unaligned lands

#53
post #38

Earlier quoted context omitted.

Hello, please check my two Redis Conf 2017 talks on youtube. There is info about Streams.

Did my enhancement make it into the skip list implementation being used for the STREAM type? I am hoping it would be in place before you publish benchmarks for it. https://github.com/antirez/redis/pull/3889

Hello, very interesting! I missed this, just commented on the issue. The Streams are not based on skiplists, but instead will be implemented using http://github.com/antirez/rax

Re: Redis on the Raspberry Pi: Adventures in unaligned lands

#54
post #52

Earlier quoted context omitted.

You sound like an architecture person (I'm not, btw), so maybe you can give the lowdown on this. Why registers? I haven't studied the Tomasulo algorithm in any detail, but if you're going to do "register renaming", why have registers at all? You could, for example, treat memory as a if-needed-only backing store, and then add a "commit" instruction that commits memory (takes an address, or a range). Sure you need to m…

Because that would require longer instructions and thus more memory. Instructions on a CPU are something like to following (this is based on MIPS since x86 is a mess) The first 6 bits are the instruction, the rest is command specific. For add the next 12 would be 4 bits for each of the source registers and then the destination register and then various flags (overflow for example). If instead they only worked on memo…

Not really. The TMS9900 [1] used memory as registers and had a fairly compact instruction set. Yes, it does have registers, but only three (a program counter, a status register, and a pointer to the current "register set" in memory). At the time, it was regarded as a slow machine, probably because of all the memory-to-memory operations.

[1] https://en.wikipedia.org/wiki/Texas_Instruments_TMS9900

Re: Redis on the Raspberry Pi: Adventures in unaligned lands

#55
post #54
post #52

Earlier quoted context omitted.

Because that would require longer instructions and thus more memory. Instructions on a CPU are something like to following (this is based on MIPS since x86 is a mess) The first 6 bits are the instruction, the rest is command specific. For add the next 12 would be 4 bits for each of the source registers and then the destination register and then various flags (overflow for example). If instead they only worked on memo…

Not really. The TMS9900 [1] used memory as registers and had a fairly compact instruction set. Yes, it does have registers, but only three (a program counter, a status register, and a pointer to the current "register set" in memory). At the time, it was regarded as a slow machine, probably because of all the memory-to-memory operations. [1] https://en.wikipedia.org/wiki/Texas_Instruments_TMS9900

Sure, this is one technique. You could also, akin to jump instructions, have a concept of data locality, versus instruction locality. You can do this is a lot of ways without resorting to something like segmentation, which everybody hates. Trivial would be something like a current "data pointer", which would see useful implicit updates, and well as explicit ones (akin to a long jump).

Re: Redis on the Raspberry Pi: Adventures in unaligned lands

#56
post #17
post #16

Earlier quoted context omitted.

Ethernet was invented in 1973 and the first 32-bit processors were available in 1979. While you've got the time machine, can you fix it so that "network byte order" and Intel endianness are the same too?

Or rather keep Intel from munging the order their processors write bytes in.

What?

Re: Redis on the Raspberry Pi: Adventures in unaligned lands

#57
post #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…

I'm pretty sure I saw implementations that used the existing publish subscribe mechanism in Redis to handle it and seemed happy with it. I have no personal experience with it though.

Re: Redis on the Raspberry Pi: Adventures in unaligned lands

#58
post #53

Earlier quoted context omitted.

Did my enhancement make it into the skip list implementation being used for the STREAM type? I am hoping it would be in place before you publish benchmarks for it. https://github.com/antirez/redis/pull/3889

Hello, very interesting! I missed this, just commented on the issue. The Streams are not based on skiplists, but instead will be implemented using http://github.com/antirez/rax

Thanks for having a look! I only read the early proposals for the data structure behind Streams and haven't had a chance to go over the final implementation. I hope to dive into the source this week and make more contributions down the road!

Re: Redis on the Raspberry Pi: Adventures in unaligned lands

#59
post #43

Earlier quoted context omitted.

Even today, allowing unaligned accesses is still not free -- there is an implementation cost in transistors and in design complexity. There's a tradeoff here, as usual. There are a lot of places with a CPU architecture where there's a choice of "do we handle this in hardware, at the cost of having to have more hardware, or do we say it's software's job to deal with this, and hardware provides either nothing or just s…

You sound like an architecture person (I'm not, btw), so maybe you can give the lowdown on this. Why registers? I haven't studied the Tomasulo algorithm in any detail, but if you're going to do "register renaming", why have registers at all? You could, for example, treat memory as a if-needed-only backing store, and then add a "commit" instruction that commits memory (takes an address, or a range). Sure you need to m…

Not all CPUs do register renaming, and almost all architectures will have started out being defined for a CPU which didn't do renaming. Even today, lower end CPUs (think the embedded market) don't do register renaming. If you want your architecture to be able to cover down to the low end then anything that drops the idea of a register file is a non-starter. Also, a register-based architecture is well understood, in terms of how to implement it effectively, how to exploit it in compiler design, and how to hand-code assembly for it when necessary. You need a really strong argument to justify taking the weird and innovative route, usually.

Re: Redis on the Raspberry Pi: Adventures in unaligned lands

#60
post #38
post #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…

Hello, please check my two Redis Conf 2017 talks on youtube. There is info about Streams.

Thanks antirez! This looks exactly like the feature I've been searching for. :)

For posterity, here's the referenced videos:

General overview: https://youtu.be/U7J33pd3hLU?t=23m54s

Implementation details: https://youtu.be/Wzy8dIjsY6Y

Post reply on HN