6 ms·

Not an easy read for C++ fans like me, especially since it is coming from Bartosz Milewski. I did try out several other languages and I keep coming back to C++

by CCs 13y ago

Not an easy read for C++ fans like me, especially since it is coming from Bartosz Milewski. I did try out several other languages and I keep coming back to C++11 for anything that requires scalability and raw performance, like APIs. The same basic server that gets 400 req/sec when implemented in C# ASP.NET achieves 7900 req/sec using C++. So far I could not find a programming language that does not have similar (or worse) scissors. It's more like "pick your poison" type of choice. After I learned Scala, my C++ code started to look like functional programming. According to Bartosz that's a good thing, and I did not have to dive into Haskell (yet). :)

wheaties 13y ago
I went C++ -> Python -> Scala. Still do Python. Don't do C++ anymore for the same exact reasons he mentions. The guy is a C++ hero and to hear him say those things means a lot. I encourage you to keep playing around with Scala. Have fund with the Actor model. Enjoy GC.
- chetanahuja 13y ago
  "Enjoy GC." Can't tell whether joking or serious. I guess my bitter laugh covers both cases.
  - AsymetricCom 13y ago
    "Enjoy GC" "Enjoy living on a boat" "Enjoy waking up at 2AM" and other ways being not free is freeing.
  - jerf 13y ago
    It's easier to start from a GC'ed language, and use escape hatches when you need them, then to start without GC and then realize that your program has become a mess because you don't have it. Many GC'ed languages have such escape hatches. Those that don't, well, don't start writing performance-critical code in them would be my recommendation. And also, do not miss his point about reference counting just being a form of GC. "Manual memory management" isn't really a thing that exists, there's a whole suite of memory management techniques and alternatives, and it's easy with something like "C++ with ref counting" to actually be experiencing the worst of all worlds (all the work of "manual" memory management with all the disadvantages of GC) if you don't deeply understand what's really going on with your memory.
    - chetanahuja 13y ago
      Funny you mention the "worst of all worlds scenario" because that's exactly what I was thinking about your advice to start with a GC'd language and then escape for performance critical (which usually means huge heaps btw) parts. This plan combines you all the flexibility, predictability and reliable latency of managed VM systems combined with all the safety guarantees of a manual memory managed system.
      - jerf 13y ago
        Read my whole first sentence again. Carefully. I think it does not say what you think it says. Furthermore, I still don't think you got the point that there is no royal road to perfect memory management. You can't just say the words "manual memory management" and pretend you've solved the problem, or indeed, that you've said anything at all. Many of the same "manual memory management" techniques that you might use are still readily available in "garbage collected" languages. It's not a boolean, it's a rich space. And thus, I stand by my first sentence.
- CCs 13y ago
  We're in production with Scala since 2010 and for that use case it worked out pretty good. Not enjoying the GC at all, it is by far the biggest issue. Also keeping an eye on Go and D, but not yet committed.
- lttlrck 13y ago
  Learning how to manage memory is a tiny fraction of the work involved in writing complex applications, and it's done upfront. Not having to worry about it would only give a proportionally tiny increase in 'enjoyment'.
16s 13y ago
It's still my favorite language. I do respect his thoughts, but when I have systems programming to do, I'll take C++ over anything else any day, warts and all.
jaggederest 13y ago
How many of your applications are actually getting 7900 requests per second though? Optimize for effectiveness, not speed.
- jaytaylor 13y ago
  Furthermore, how optimized was the C#.NET version? C# will even let you drop into C++ if you want..I have a feeling the C# version may not have been tuned effectively.
  - MichaelGG 13y ago
    Yeah I'd guess perhaps it was part of the framework. The CLR's unfortunate use of UCS-2 (2-byte per char) can really hurt in a string processing system. You can easily go from C# to native and back, so who knows. Also, "help from Microsoft" can range widely.
- CCs 13y ago
  7900 req/sec is on my laptop, first try without optimization - and we will need a lot more. I know Disqus can serve up to 1M/server and they try to patch the Linux kernel to reach 2M. (Not exactly apples to apples since I use SQL transactions, but in the ballpark.) The .NET never went over 440 request/sec on the server, not even with help from Microsoft. That means either C++ or using 2000 servers instead of the current 400 servers for every major deployment (hospital).
  - jaggederest 13y ago
    You're seriously serving a billion requests a day? And you're writing new software which is expected to go from zero to a billion requests, full stop? And you're not expecting anything to change between beginning development and production? And, once the software is in production, it's not going to change at all? I seriously doubt that all of those things are true - in which case you'd probably be better off using a different language. In my experience, it's much, much cheaper to run 2000 servers ($10m capital cost? something like that?) than double the number of software engineers you've got ($Xm a year, continuously?), and doubling the number of software engineers isn't a linear scaling.
adamnemecek 13y ago
Let's hope that Rust takes off.
- kibwen 13y ago
  Indeed, this is exactly the niche that Rust is targeting: C++ performance without C++'s pitfalls. But it'll likely still be quite a while before it's battle-tested enough for everyday use.
Dewie 13y ago
> So far I could not find a programming language that does not have similar (or worse) scissors. It's more like "pick your poison" type of choice. Ada? I've heard that it is very big on safety, and that it is in the C ballpark efficiency-wise.
- CCs 13y ago
  Is there any company / product that uses it? (serious question) I heard good things about many other "nice" languages, just nobody saw them in the wild, actually doing something useful...
  - Dewie 13y ago
    From what I've read it's mostly used in safety-critical applications. The kind where if something is amiss, your plane crashes. It's niche, but it is actually in use. It's not a toy or academic-only programming language, like you seem to be alluding to. http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html
MichaelGG 13y ago
With C#, did you try using manual memory management? I wrote a rather high-performance (50K requests/sec, 550K ops/sec) daemon in F#. The big trick was to use my own mem management when it makes sense. I had a ~1GB managed heap, and 12+GB unmanaged. For instance, you can stack-allocate many objects in C# (strings and arrays, for instance), if you're willing to give up the safety (and if C++ is an option, then you are willing). You can manually heap-alloc managed objects, too, although it gets tricky if they are nested objects. After all, the JIT is just taking pointers to objects and doing stuff with them - it doesn't care where the memory came from (just remember the GC won't scan your manually allocated stuff). The CLR (unlike the JVM) has native capabilities built right into it. People should take more advantage of such things instead of only trying fully safe C# and then deciding to dump it all for no safety.
- barrkel 13y ago
  I'm in violent agreement. To avoid the costs of serialization and deserialization on a per-request basis, I built a little object system that stored all its instance data in a byte array. All internal references were offsets from the start of the array, but what made it fast was that I could read and write in it using raw pointers. I then recycled the byte arrays to avoid GC pressure, as many were just over the edge of the large object heap, only collectable with gen2 scans. I had a version working with manually allocated buffers, but it wasn't any faster - GC overhead was only 2% or so.
  - CCs 13y ago
    How CLR ninja skills are better than C++ ninja skills? Both might kill average developers. The named C# implementation came from .NET experts and an army of consultants from Microsoft. The final advice was "yes, C# is easier to develop, but it comes with a price - just pay the price and drop in some additional servers".
    - mwcampbell 13y ago
      The crucial difference is that C# is memory-safe by default, and for most code, this is fine. As another commenter said, manual memory management is available as an escape hatch from the garbage collector if you need it. To extend the Edward Scissorhands analogy, with C#, you can use scissors when you need them, but with C++, your hands are scissors, so you'd better be careful all the time.
zurn 13y ago
We've come pretty far if without blinking it can be said that 8000 API calls per second is fast and you can get there only by using a language like C++, in 2013...

by CCs 13y ago

wheaties 13y ago

I went C++ -> Python -> Scala. Still do Python. Don't do C++ anymore for the same exact reasons he mentions. The guy is a C++ hero and to hear him say those things means a lot. I encourage you to keep playing around with Scala. Have fund with the Actor model. Enjoy GC.

chetanahuja 13y ago
"Enjoy GC." Can't tell whether joking or serious. I guess my bitter laugh covers both cases.
- AsymetricCom 13y ago
  "Enjoy GC" "Enjoy living on a boat" "Enjoy waking up at 2AM" and other ways being not free is freeing.
- jerf 13y ago
  It's easier to start from a GC'ed language, and use escape hatches when you need them, then to start without GC and then realize that your program has become a mess because you don't have it. Many GC'ed languages have such escape hatches. Those that don't, well, don't start writing performance-critical code in them would be my recommendation. And also, do not miss his point about reference counting just being a form of GC. "Manual memory management" isn't really a thing that exists, there's a whole suite of memory management techniques and alternatives, and it's easy with something like "C++ with ref counting" to actually be experiencing the worst of all worlds (all the work of "manual" memory management with all the disadvantages of GC) if you don't deeply understand what's really going on with your memory.
  - chetanahuja 13y ago
    Funny you mention the "worst of all worlds scenario" because that's exactly what I was thinking about your advice to start with a GC'd language and then escape for performance critical (which usually means huge heaps btw) parts. This plan combines you all the flexibility, predictability and reliable latency of managed VM systems combined with all the safety guarantees of a manual memory managed system.
    - jerf 13y ago
      Read my whole first sentence again. Carefully. I think it does not say what you think it says. Furthermore, I still don't think you got the point that there is no royal road to perfect memory management. You can't just say the words "manual memory management" and pretend you've solved the problem, or indeed, that you've said anything at all. Many of the same "manual memory management" techniques that you might use are still readily available in "garbage collected" languages. It's not a boolean, it's a rich space. And thus, I stand by my first sentence.
CCs 13y ago
We're in production with Scala since 2010 and for that use case it worked out pretty good. Not enjoying the GC at all, it is by far the biggest issue. Also keeping an eye on Go and D, but not yet committed.
lttlrck 13y ago
Learning how to manage memory is a tiny fraction of the work involved in writing complex applications, and it's done upfront. Not having to worry about it would only give a proportionally tiny increase in 'enjoyment'.

16s 13y ago

It's still my favorite language. I do respect his thoughts, but when I have systems programming to do, I'll take C++ over anything else any day, warts and all.

jaggederest 13y ago

How many of your applications are actually getting 7900 requests per second though? Optimize for effectiveness, not speed.

jaytaylor 13y ago
Furthermore, how optimized was the C#.NET version? C# will even let you drop into C++ if you want..I have a feeling the C# version may not have been tuned effectively.
- MichaelGG 13y ago
  Yeah I'd guess perhaps it was part of the framework. The CLR's unfortunate use of UCS-2 (2-byte per char) can really hurt in a string processing system. You can easily go from C# to native and back, so who knows. Also, "help from Microsoft" can range widely.
CCs 13y ago
7900 req/sec is on my laptop, first try without optimization - and we will need a lot more. I know Disqus can serve up to 1M/server and they try to patch the Linux kernel to reach 2M. (Not exactly apples to apples since I use SQL transactions, but in the ballpark.) The .NET never went over 440 request/sec on the server, not even with help from Microsoft. That means either C++ or using 2000 servers instead of the current 400 servers for every major deployment (hospital).
- jaggederest 13y ago
  You're seriously serving a billion requests a day? And you're writing new software which is expected to go from zero to a billion requests, full stop? And you're not expecting anything to change between beginning development and production? And, once the software is in production, it's not going to change at all? I seriously doubt that all of those things are true - in which case you'd probably be better off using a different language. In my experience, it's much, much cheaper to run 2000 servers ($10m capital cost? something like that?) than double the number of software engineers you've got ($Xm a year, continuously?), and doubling the number of software engineers isn't a linear scaling.

adamnemecek 13y ago

Let's hope that Rust takes off.

kibwen 13y ago
Indeed, this is exactly the niche that Rust is targeting: C++ performance without C++'s pitfalls. But it'll likely still be quite a while before it's battle-tested enough for everyday use.

Dewie 13y ago

> So far I could not find a programming language that does not have similar (or worse) scissors. It's more like "pick your poison" type of choice. Ada? I've heard that it is very big on safety, and that it is in the C ballpark efficiency-wise.

CCs 13y ago
Is there any company / product that uses it? (serious question) I heard good things about many other "nice" languages, just nobody saw them in the wild, actually doing something useful...
- Dewie 13y ago
  From what I've read it's mostly used in safety-critical applications. The kind where if something is amiss, your plane crashes. It's niche, but it is actually in use. It's not a toy or academic-only programming language, like you seem to be alluding to. http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html

MichaelGG 13y ago

With C#, did you try using manual memory management? I wrote a rather high-performance (50K requests/sec, 550K ops/sec) daemon in F#. The big trick was to use my own mem management when it makes sense. I had a ~1GB managed heap, and 12+GB unmanaged. For instance, you can stack-allocate many objects in C# (strings and arrays, for instance), if you're willing to give up the safety (and if C++ is an option, then you are willing). You can manually heap-alloc managed objects, too, although it gets tricky if they are nested objects. After all, the JIT is just taking pointers to objects and doing stuff with them - it doesn't care where the memory came from (just remember the GC won't scan your manually allocated stuff). The CLR (unlike the JVM) has native capabilities built right into it. People should take more advantage of such things instead of only trying fully safe C# and then deciding to dump it all for no safety.

barrkel 13y ago
I'm in violent agreement. To avoid the costs of serialization and deserialization on a per-request basis, I built a little object system that stored all its instance data in a byte array. All internal references were offsets from the start of the array, but what made it fast was that I could read and write in it using raw pointers. I then recycled the byte arrays to avoid GC pressure, as many were just over the edge of the large object heap, only collectable with gen2 scans. I had a version working with manually allocated buffers, but it wasn't any faster - GC overhead was only 2% or so.
- CCs 13y ago
  How CLR ninja skills are better than C++ ninja skills? Both might kill average developers. The named C# implementation came from .NET experts and an army of consultants from Microsoft. The final advice was "yes, C# is easier to develop, but it comes with a price - just pay the price and drop in some additional servers".
  - mwcampbell 13y ago
    The crucial difference is that C# is memory-safe by default, and for most code, this is fine. As another commenter said, manual memory management is available as an escape hatch from the garbage collector if you need it. To extend the Edward Scissorhands analogy, with C#, you can use scissors when you need them, but with C++, your hands are scissors, so you'd better be careful all the time.

zurn 13y ago

We've come pretty far if without blinking it can be said that 8000 API calls per second is fast and you can get there only by using a language like C++, in 2013...