> 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.
Redis on the Raspberry Pi: Adventures in unaligned lands
51–60 of 60 posts
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#52Earlier 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…
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
#53Earlier 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
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#54Earlier 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…
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#55Earlier 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
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#56Earlier 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.
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#57> 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…
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#58Earlier 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
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#59Earlier 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…
Re: Redis on the Raspberry Pi: Adventures in unaligned lands
#60> 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.
For posterity, here's the referenced videos:
General overview: https://youtu.be/U7J33pd3hLU?t=23m54s
Implementation details: https://youtu.be/Wzy8dIjsY6Y