Live data from Hacker News

Writing high-performance servers in modern C++

medium.com

31–40 of 77 posts

Re: Writing high-performance servers in modern C++

#32
Any classical logic is possible, because C++ is a Turing-complete language.

That said, of course, how much you can actually do and how fast you can do it depends a lot on the hardware you have available. Not every computer can run fast, high-quality graphics, no matter what language you coded in.

THAT said, C++ is considered a relatively high-performance language and is often used for things like advanced game graphics.

Re: Writing high-performance servers in modern C++

#33

Earlier quoted context omitted.

Modern C++ is indeed pretty productive. It's the tooling and compile times that hold it back.

Perhaps you mean link time? If you're spending a lot of time compiling you are probably suffering from other problems. Most of C++'s issues with compilation come from needing to re-compile entire .cpp files because of a change in a depending .h file. If you properly forward your class declarations instead of including a header in a .h file, don't do template meta meta magic, and think about physical design a bit, you…

You can usually get a noticeable speedup using unity builds, even when using something like Incredibuild. That suggests that more source files is not the answer. (I am not going to speculate as to why things are this way; it simply appears to be the case.) I'm not sure it makes a great deal of sense to separate compilation time from link time anyway (and you should also consider device reboot or program startup time as well). It all adds up to the same thing: shameful turnaround times.

This has been a problem on every C++ project I've worked on over the past 15 years, and it only seems to be getting worse. And scaled up by increasing team size, that makes it even more of a serious problem.

I hope your parting shot was intended to be that we shouldn't have to worry about this today, i.e., that we should be able to expect more from our tools, and that the current tools are shit. Because we absolutely should worry about it! This is people's time we're talking about. That isn't any less valuable than it used to be.

Re: Writing high-performance servers in modern C++

#37
post #22

I don't understand the point of saying something like: > "I show how to build a modern C++ high-performance, asynchronous echo server that can be written with just 48 lines of code." The fact that it is 48 lines of code is almost meaningless. If the framework was a different design it could be done in 1 line of C++ code or 1 line of COBOL. Given the right library/framework, any application can be done with 1 line of…

I agree that a more fitting line would have been, "I show how to build a modern C++ high-performance, asynchronous echo server using Facebook's Wangle (which comes out to be only 48 lines of code).

However the TITLE OF THE ARTICLE is "Writing modern C++ servers using Wangle." Furthermore, the author states that he's using that framework almost immediately after the statement you quoted, so I really see nothing to complain about. It would be more of an issue if the author led with a huge introductory paragraph or click-baity title that failed to mention the library she or he is using.

Knowing how many lines it took for the author to implement the server in the Wangle framework is very relevant to the reader.

Re: Writing high-performance servers in modern C++

#40

A lot of people state that Python/PHP/Ruby/Javascript on the dynamic language side and Java and other JVM languages on the statically typed side and much quicker to develop than C++, but being a very experienced Java programmer and a decent Javascript programmer I find that I can program just as fast with C++ as long as you use the right choices of libraries and use C++11 or greater. With libraries like Boost, fbfoll…

For network-facing software, though, the memory safety problem is a huge one. It's one you just don't have with Python, PHP, Ruby, JavaScript, and Java. And I don't see any solution to it in the near future.
Post reply on HN