Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In-memory key-value store in C, Go and Python

darkcoding.net

Post reply on HN
Print view View original

51–58 of 58 posts

Re: In-memory key-value store in C, Go and Python

#51

Post by enneff »

apaprocki wrote: post #35

Not everyone has this problem, but Go only works on a portion of platform configurations that are available in the real world. C and Python, OTOH, are available pretty much anywhere. Redis builds on say, Solaris, with no problem because the project is written in C and it is trivial to add the needed calls. A KV store written in Go can't support Solaris because Go itself would need to support Solaris first. Years of t…

gccgo does support Solaris, and should support any operating system that uses ELF binaries.

The gc Go compiler currently supports FreeBSD, Linux, Mac OS X, and Windows. That's at least 95% of the servers out there (probably more). There is code to support NetBSD, OpenBSD, and Plan 9, but we have held off polishing it for Go 1.

Re: In-memory key-value store in C, Go and Python

#52

Post by apaprocki »

enneff wrote: post #51
apaprocki wrote: post #35

Not everyone has this problem, but Go only works on a portion of platform configurations that are available in the real world. C and Python, OTOH, are available pretty much anywhere. Redis builds on say, Solaris, with no problem because the project is written in C and it is trivial to add the needed calls. A KV store written in Go can't support Solaris because Go itself would need to support Solaris first. Years of t…

gccgo does support Solaris, and should support any operating system that uses ELF binaries. The gc Go compiler currently supports FreeBSD, Linux, Mac OS X, and Windows. That's at least 95% of the servers out there (probably more). There is code to support NetBSD, OpenBSD, and Plan 9, but we have held off polishing it for Go 1.

Is it a huge amount of work to support non-ELF formats? I haven't looked at the code, but I guess it is not using bfd? AIX uses XCOFF, not ELF. I'd be interested in finding out what it would take to add support.

Re: In-memory key-value store in C, Go and Python

#53

Post by caf »

spullara wrote: post #8

Are we seriously discussing a benchmark that only runs 1000 operations? I don't even understand how it could take 20s to complete in any language on the server side and be correct code. Implement the Redis protocol and use the included redis-benchmark to test your server. On a decent Mac you should be able to hit 500k/s with pipelining and 25k/s without it.

The slowness actually appears to be down to his client implementation - see the comment by Clément Stenac on the original post.

Re: In-memory key-value store in C, Go and Python

#54

Post by enneff »

apaprocki wrote: post #52
enneff wrote: post #51

Earlier quoted context omitted.

gccgo does support Solaris, and should support any operating system that uses ELF binaries. The gc Go compiler currently supports FreeBSD, Linux, Mac OS X, and Windows. That's at least 95% of the servers out there (probably more). There is code to support NetBSD, OpenBSD, and Plan 9, but we have held off polishing it for Go 1.

Is it a huge amount of work to support non-ELF formats? I haven't looked at the code, but I guess it is not using bfd? AIX uses XCOFF, not ELF. I'd be interested in finding out what it would take to add support.

Gold is an ELF linker. I don't think it was designed to support other object formats, so it's non-trivial at the least.

Re: In-memory key-value store in C, Go and Python

#55

Post by 4ad »

enneff wrote: post #54
apaprocki wrote: post #52

Earlier quoted context omitted.

Is it a huge amount of work to support non-ELF formats? I haven't looked at the code, but I guess it is not using bfd? AIX uses XCOFF, not ELF. I'd be interested in finding out what it would take to add support.

Gold is an ELF linker. I don't think it was designed to support other object formats, so it's non-trivial at the least.

gccgo works without gold, albeit not as well, some people have tried it even on Irix. iant told me even Windows might work as is, though nobody tried. In any case, it should be very easy to make Windows work as well.

Re: In-memory key-value store in C, Go and Python

#56

Post by graham_king_3 »

codeape wrote: post #31
caf wrote: post #20

Earlier quoted context omitted.

Yes, the explanation given does not seem to pass the sniff test. If all the wall-time is being taken in recv(), there's no reason why using epoll() would be any improvement.

The reason the python version is slow is (I believe) that the code is very inefficient. It uses socket.sendall() instead of sockfile.write/flush. Using sockfile.write/flush speeds it up from 50 requests/second to 7k requests/second on my machine.

I'm the author of the original post. The difference has nothing to do with epoll, these comments are correct. Thanks particularly to codeape for his pull request which made me realise this. Sorry everyone. I will fix the post.

Reducing the number of send calls, in both the C and Python versions, makes them enormously faster. Go is already batching up the writes, hence the apparent speed advantage.

If you strace the client, you see that the "get" case was replying with two send calls, one for the "VALUE" line, another with the value and "END". All the time is consumed with the client waiting to receive that second message. Depending on the client, and I tried a bunch of ways, it's either in 'poll' (pylibmc), 'futex' (Go), or 'recv' (basic python socket). That second receive is about two orders of magnitude slower than the previous recv.

Why does reading that second line take so much longer?

There's more detail here: https://github.com/grahamking/Key-Value-Polyglot/pull/5#issu...

Re: In-memory key-value store in C, Go and Python

#57

Post by caf »

graham_king_3 wrote: post #56
codeape wrote: post #31

Earlier quoted context omitted.

The reason the python version is slow is (I believe) that the code is very inefficient. It uses socket.sendall() instead of sockfile.write/flush. Using sockfile.write/flush speeds it up from 50 requests/second to 7k requests/second on my machine.

I'm the author of the original post. The difference has nothing to do with epoll, these comments are correct. Thanks particularly to codeape for his pull request which made me realise this. Sorry everyone. I will fix the post. Reducing the number of send calls, in both the C and Python versions, makes them enormously faster. Go is already batching up the writes, hence the apparent speed advantage. If you strace the c…

It could be the Nagle algorithm - setting the TCP_NODELAY socket option on the sender would be one way to test.

Re: In-memory key-value store in C, Go and Python

#58

Post by graham_king_3 »

caf wrote: post #57
graham_king_3 wrote: post #56

Earlier quoted context omitted.

I'm the author of the original post. The difference has nothing to do with epoll, these comments are correct. Thanks particularly to codeape for his pull request which made me realise this. Sorry everyone. I will fix the post. Reducing the number of send calls, in both the C and Python versions, makes them enormously faster. Go is already batching up the writes, hence the apparent speed advantage. If you strace the c…

It could be the Nagle algorithm - setting the TCP_NODELAY socket option on the sender would be one way to test.

Yes, thank you! Adding this line to the two-writes Python version (memg-slow.py on github) makes it about as fast as the single write version (memg.py on github):

sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)

It's an interaction between delayed ACKS and the Nagle algorithm, mentioned on the Nagle algorithm wikipedia page.

I'm learning a lot this week. Thanks again.

Post reply on HN