Seastar: C++ framework for high-performance servers • Hacker News Board

Re: Seastar: C++ framework for high-performance servers

#11

Post by seastarer » Sun, Apr 26, 2015, 1:52 PM UTC

vinceyuan wrote: post #9

"Applications using Seastar can run on Linux or OSv." Will Seastar support OS X? If No, developer using Mac has to install Linux VM to development.

In posix mode, seastar uses the host's TCP stack (instead of the internal super-fast stack). This is useful for development. While we haven't ported it to osx, it should be fairly easy as the code is portable.

Note you'll need gcc 4.9 or later.

Re: Seastar: C++ framework for high-performance servers

#12

Post by seastarer » Sun, Apr 26, 2015, 1:58 PM UTC

virtuallynathan wrote: post #8

Hmmm... wonder if this could go even faster using Cluster-on-Die mode in the new E5-2600v3 CPUs (It splits each CPU into 2 NUMA nodes). Its also worth noting that the fastest memory configuration is 4x16GB DDR4-2133 DIMMs. Gets you the lowest latency and highest bandwidth according to Intel. Another note, I see the CPU in the writeup reports as "cpu MHz: 1199.953" - have you turned off C-States?

Do you have a link to this cluster-on-die mode?

Re: Seastar: C++ framework for high-performance servers

#13

Post by virtuallynathan » Sun, Apr 26, 2015, 2:06 PM UTC

seastarer wrote: post #12

virtuallynathan wrote: post #8

Hmmm... wonder if this could go even faster using Cluster-on-Die mode in the new E5-2600v3 CPUs (It splits each CPU into 2 NUMA nodes). Its also worth noting that the fastest memory configuration is 4x16GB DDR4-2133 DIMMs. Gets you the lowest latency and highest bandwidth according to Intel. Another note, I see the CPU in the writeup reports as "cpu MHz: 1199.953" - have you turned off C-States?

Do you have a link to this cluster-on-die mode?

This document from Intel covers CoD mode (Pg. 28) and optimal DIMM sizes (Pg. 37), etc. https://drive.google.com/file/d/0B21tKtZ3UOQNdWtJZW9XekFCZ3M...

You should also disable C-States (e.g. lock to C0) - https://rhsummit.files.wordpress.com/2013/06/shak-jeder-summ... covers the performance impact of CPU states.

Re: Seastar: C++ framework for high-performance servers

#14

Post by seastarer » Sun, Apr 26, 2015, 2:11 PM UTC

virtuallynathan wrote: post #13

seastarer wrote: post #12

Earlier quoted context omitted.

Do you have a link to this cluster-on-die mode?

This document from Intel covers CoD mode (Pg. 28) and optimal DIMM sizes (Pg. 37), etc. https://drive.google.com/file/d/0B21tKtZ3UOQNdWtJZW9XekFCZ3M... You should also disable C-States (e.g. lock to C0) - https://rhsummit.files.wordpress.com/2013/06/shak-jeder-summ... covers the performance impact of CPU states.

Thanks. We "disable" C-states by polling -- the cpu never goes idle. This is partly because dpdk doesn't support interrupts, and partly because using interrupts is a major performance hit. We have plans to improve this, but nothing committed yet.

Re: Seastar: C++ framework for high-performance servers

#15

Post by rbf_ » Sun, Apr 26, 2015, 2:41 PM UTC

They mention that this is using a polling architecture so each core is using 100% cpu even when idle. I've worked on high performance systems architected around polling before, but assumed that would be prohibitively costly these days now that cpu's have really advanced power management capabilities. Is polling architecture still viable for large scale cloud computing given costs of energy consumption? Years ago cpu's used a flat amount of power regardless of cpu utilization but now those extra cycles cost watts and of course money.

Re: Seastar: C++ framework for high-performance servers

#16

Post by rbf_ » Sun, Apr 26, 2015, 2:47 PM UTC

rbf_ wrote: post #15

They mention that this is using a polling architecture so each core is using 100% cpu even when idle. I've worked on high performance systems architected around polling before, but assumed that would be prohibitively costly these days now that cpu's have really advanced power management capabilities. Is polling architecture still viable for large scale cloud computing given costs of energy consumption? Years ago cpu'…

That little embedded user space tcp/ip stack is really neat.

Re: Seastar: C++ framework for high-performance servers

#17

Post by ComputerGuru » Sun, Apr 26, 2015, 3:06 PM UTC

DPDK supports FreeBSD, I wonder if Seastar runs on that?

Re: Seastar: C++ framework for high-performance servers

#18

Post by seastarer » Sun, Apr 26, 2015, 4:15 PM UTC

ComputerGuru wrote: post #17

DPDK supports FreeBSD, I wonder if Seastar runs on that?

It ought to. There may be a minor porting effort involved. Note you need very recent gcc.

Re: Seastar: C++ framework for high-performance servers

#19

Post by seastarer » Sun, Apr 26, 2015, 4:23 PM UTC

rbf_ wrote: post #15

They mention that this is using a polling architecture so each core is using 100% cpu even when idle. I've worked on high performance systems architected around polling before, but assumed that would be prohibitively costly these days now that cpu's have really advanced power management capabilities. Is polling architecture still viable for large scale cloud computing given costs of energy consumption? Years ago cpu'…

We plan to reduce power usage on low load eventually.

Re: Seastar: C++ framework for high-performance servers

#20

Post by shawn-furyan » Sun, Apr 26, 2015, 5:00 PM UTC

rbf_ wrote: post #15

They mention that this is using a polling architecture so each core is using 100% cpu even when idle. I've worked on high performance systems architected around polling before, but assumed that would be prohibitively costly these days now that cpu's have really advanced power management capabilities. Is polling architecture still viable for large scale cloud computing given costs of energy consumption? Years ago cpu'…

Perhaps such a server could be integrated in a way such that it spins up during high load scenarios and back down when the load is no longer sufficient to keep it saturated? If that were possible, then overall efficiency could still be higher than using only servers with better idle power usage characteristics since it could potentially save you from having to deploy n times as many normal servers.