4 ms·

I'd love to get in to a part of the industry where people care about stuff like this (purely for selfish reasons... web development is fun too but the barrier t

I'd love to get in to a part of the industry where people care about stuff like this (purely for selfish reasons... web development is fun too but the barrier to entry is a lot lower). Can anyone comment on the number and quality of "hard core" C++ jobs and what you think the trajectory will be like? Right now I use C++ almost exclusively at work but the code/concepts involved aren't too difficult.

jandrewrogers 14y ago
C++ is increasingly used for high-performance and massively parallel systems. While I used to work on systems primarily written in Java (large-scale analytics and databases) everything new is being done in C++, especially any kind of high-end compute environments. C++ has a few very real advantages on modern architectures and when tackling modern problems. With C++11, it is also a pretty decent programming language in terms of expressiveness. C++ has two big advantages over alternatives like Java: very low and deterministic processing latency (important for real-time) and very efficient memory model (important for throughput). These are really both about memory, and C++ gives you detailed control in a way few other languages do. As to why this is important, memory performance has been scaling more slowly than many other aspects of computing architecture such that it is the bottleneck for a growing number of applications. C++ allows you to be very efficient with the memory architecture without much effort. If your application is fundamentally bound by memory performance, competent C++ can get you 2-10x returns on performance in real systems relative to languages like Java. (For some other tight-loop, CPU-bound codes, not so much.) I'm pretty bull-ish on C++11. It is not so much that I am a fan of the language but that I am a fan of what it can do in terms of performance for databases and large-scale systems. Most of the high-scale and high-performance development going forward seems to be targeted at C++ these days. That was not always the case but the requirements of modern applications are somewhat forcing that choice.
- qznc 14y ago
  If you want parallel/concurrent programming there are better languages than C++. However, additional requirements (real-time, performance, size, ...) make C++ desirable again, since C++ tries very hard to avoid tradeoffs in these terms.
- tmurray 14y ago
  do you think we'll see a lot of HPC apps using C++11 for parallelism within a node, or will they stick to MPI for that? most of the apps I've seen are MPI only or OpenMP + MPI--I'm not convinced that C++11 will be very relevant to them because of the minor overhead of MPI within a node (and the productivity savings of having only one API for parallelism).
  - jandrewrogers 14y ago
    MPI is messaging interface rather than a parallelism API. Even in C++ most of the parallelism constructs are a strawman because many high-performance computing codes are written as single-threaded processes locked to individual cores and communicating over a messaging interface of some type. The parallelism is implemented at a higher level than either the messaging interface or the code. Many supercomputing platforms support MPI but not all of them do. The practice of a single process locked to each core communicating over a messaging interface has trickled down to more generic massively distributed systems work because it has very good properties on modern hardware. You end up doing a fair amount of functional programming in this model because multiple tasks are managed via coroutines and other lightweight event models. This architecture is very easy to scale out because it treats every core -- on the same chip, same motherboard, or same network -- as a remote resource that has to be messaged. MPI has one significant problem for massively parallel systems in that it has tended to be brittle when failures occur, and on sufficiently large systems failures are a routine problem. There are ways to work around it but it is not the most resilient basis for communication in extremely large systems. At the high-end of HPC MPI and similar interfaces are commonly used but for many of the next generation non-HPC systems operating on a similar scale they are using custom network processing engines built on top of IP that give more fine-grained control over network behaviors and semantics. This is not faster than MPI and often slower, and tends to be a bit more complex but it allows more robustness and resilience to be built in at a lower level. MPI was designed for a set of assumptions that work for many classic supercomputing applications but which don't match many current use cases.
    - tmurray 14y ago
      any chance you can comment on the fault tolerance proposal in MPI 3? also, do you have any examples of custom network engines on top of IP?
maximilianburke 14y ago
My work in concurrency with C++ has been from the AAA games angle. I have found that it's a field where knowledge of parallel programming is incredibly valuable but few people end up putting the effort in to make their code take advantage of the hardware. People who are interested in parallel programming are a rare asset to have. At least within my company we haven't used much in the way of parallel programming languages like OpenCL/CUDA/Cilk, preferring instead to use a task based concurrency library not entirely unlike Intel's TBB, but more cross platform. There's more investigation into GPGPU happening these days -- I'm curious to see if it'll pan out for more than just rendering applications. I'm also curious to see if the other (physics/audio/animation) areas can pull GPU time away from the rendering guys :) The trajectory in this field is predictable. You get a hardware platform, have 5-7 years to figure out how to use it, and once you finally have it figured out something entirely different comes along.
trekkin 14y ago
I can't comment on wider industry trends, but I know for sure that some companies (specifically in NYC) pay decent money ($150k+) to people who do this stuff. And they can't find enough developers at this salary level (maybe they could if they paid more)
- infinite8s 14y ago
  The problem is that people with this level of skill can make much more in the finance industry.
tseabrooks 14y ago
Embedded development on a lot of consumer electronics devices are mostly in C++ these days. Some of the UI elements are changing to HTML5 UIs without a real browser (wired directly into C++ methods talking to HW through "magic"). Admittedly, a lot of these jobs are oversees. However, I believe the amazon and MS consumer electronics groups are still in the US and I know for a fact that until this year all of the Toshiba TV firmwares were being done in the US. However, my experience in the CE industry has been that we aren't worried about massively performant parallelism, just "moderately performant" parallelism. I want to say that as of a few years ago Toshiba TVs had something like 10-30 threads running at all times in parallel.
alecco 14y ago
Data processing, but it's not perfect. Most of the work is for questionable clients: creepy user-tracking (anti-privacy), financial powerhouses, three letter government agencies.
malkia 14y ago
Video games for example - runtime, tools, etc. We had to optimize our tool pipeline to parallelize things like dxt compression, vertex welding, mip-map creation, filters, etc. as part of the pipeline. Since there were other restrictions, that we couldn't not safely run two or more assets to be converted at the same time, we chose data parallelize (where possible) the actual asset convertion. OpenMP was used for that and helped a lot (VS2008, then VS2010). Since the process was reading, process (data parallelization), writing - and reading was much bigger than writing (you read big model, animation, or texture files, and write ~8x smaller), it was "parallelized" by prefetching files in the file cache reading them in a second thread in advance. Allowing only one writer to the HDD turned out to be beneficial (for cases like RAID SSD you can do multiple writers efficiently but this is rather pricey).

jandrewrogers 14y ago

C++ is increasingly used for high-performance and massively parallel systems. While I used to work on systems primarily written in Java (large-scale analytics and databases) everything new is being done in C++, especially any kind of high-end compute environments. C++ has a few very real advantages on modern architectures and when tackling modern problems. With C++11, it is also a pretty decent programming language in terms of expressiveness. C++ has two big advantages over alternatives like Java: very low and deterministic processing latency (important for real-time) and very efficient memory model (important for throughput). These are really both about memory, and C++ gives you detailed control in a way few other languages do. As to why this is important, memory performance has been scaling more slowly than many other aspects of computing architecture such that it is the bottleneck for a growing number of applications. C++ allows you to be very efficient with the memory architecture without much effort. If your application is fundamentally bound by memory performance, competent C++ can get you 2-10x returns on performance in real systems relative to languages like Java. (For some other tight-loop, CPU-bound codes, not so much.) I'm pretty bull-ish on C++11. It is not so much that I am a fan of the language but that I am a fan of what it can do in terms of performance for databases and large-scale systems. Most of the high-scale and high-performance development going forward seems to be targeted at C++ these days. That was not always the case but the requirements of modern applications are somewhat forcing that choice.

qznc 14y ago
If you want parallel/concurrent programming there are better languages than C++. However, additional requirements (real-time, performance, size, ...) make C++ desirable again, since C++ tries very hard to avoid tradeoffs in these terms.
tmurray 14y ago
do you think we'll see a lot of HPC apps using C++11 for parallelism within a node, or will they stick to MPI for that? most of the apps I've seen are MPI only or OpenMP + MPI--I'm not convinced that C++11 will be very relevant to them because of the minor overhead of MPI within a node (and the productivity savings of having only one API for parallelism).
- jandrewrogers 14y ago
  MPI is messaging interface rather than a parallelism API. Even in C++ most of the parallelism constructs are a strawman because many high-performance computing codes are written as single-threaded processes locked to individual cores and communicating over a messaging interface of some type. The parallelism is implemented at a higher level than either the messaging interface or the code. Many supercomputing platforms support MPI but not all of them do. The practice of a single process locked to each core communicating over a messaging interface has trickled down to more generic massively distributed systems work because it has very good properties on modern hardware. You end up doing a fair amount of functional programming in this model because multiple tasks are managed via coroutines and other lightweight event models. This architecture is very easy to scale out because it treats every core -- on the same chip, same motherboard, or same network -- as a remote resource that has to be messaged. MPI has one significant problem for massively parallel systems in that it has tended to be brittle when failures occur, and on sufficiently large systems failures are a routine problem. There are ways to work around it but it is not the most resilient basis for communication in extremely large systems. At the high-end of HPC MPI and similar interfaces are commonly used but for many of the next generation non-HPC systems operating on a similar scale they are using custom network processing engines built on top of IP that give more fine-grained control over network behaviors and semantics. This is not faster than MPI and often slower, and tends to be a bit more complex but it allows more robustness and resilience to be built in at a lower level. MPI was designed for a set of assumptions that work for many classic supercomputing applications but which don't match many current use cases.
  - tmurray 14y ago
    any chance you can comment on the fault tolerance proposal in MPI 3? also, do you have any examples of custom network engines on top of IP?

maximilianburke 14y ago

My work in concurrency with C++ has been from the AAA games angle. I have found that it's a field where knowledge of parallel programming is incredibly valuable but few people end up putting the effort in to make their code take advantage of the hardware. People who are interested in parallel programming are a rare asset to have. At least within my company we haven't used much in the way of parallel programming languages like OpenCL/CUDA/Cilk, preferring instead to use a task based concurrency library not entirely unlike Intel's TBB, but more cross platform. There's more investigation into GPGPU happening these days -- I'm curious to see if it'll pan out for more than just rendering applications. I'm also curious to see if the other (physics/audio/animation) areas can pull GPU time away from the rendering guys :) The trajectory in this field is predictable. You get a hardware platform, have 5-7 years to figure out how to use it, and once you finally have it figured out something entirely different comes along.

trekkin 14y ago

I can't comment on wider industry trends, but I know for sure that some companies (specifically in NYC) pay decent money ($150k+) to people who do this stuff. And they can't find enough developers at this salary level (maybe they could if they paid more)

infinite8s 14y ago
The problem is that people with this level of skill can make much more in the finance industry.

tseabrooks 14y ago

Embedded development on a lot of consumer electronics devices are mostly in C++ these days. Some of the UI elements are changing to HTML5 UIs without a real browser (wired directly into C++ methods talking to HW through "magic"). Admittedly, a lot of these jobs are oversees. However, I believe the amazon and MS consumer electronics groups are still in the US and I know for a fact that until this year all of the Toshiba TV firmwares were being done in the US. However, my experience in the CE industry has been that we aren't worried about massively performant parallelism, just "moderately performant" parallelism. I want to say that as of a few years ago Toshiba TVs had something like 10-30 threads running at all times in parallel.

alecco 14y ago

Data processing, but it's not perfect. Most of the work is for questionable clients: creepy user-tracking (anti-privacy), financial powerhouses, three letter government agencies.

malkia 14y ago

Video games for example - runtime, tools, etc. We had to optimize our tool pipeline to parallelize things like dxt compression, vertex welding, mip-map creation, filters, etc. as part of the pipeline. Since there were other restrictions, that we couldn't not safely run two or more assets to be converted at the same time, we chose data parallelize (where possible) the actual asset convertion. OpenMP was used for that and helped a lot (VS2008, then VS2010). Since the process was reading, process (data parallelization), writing - and reading was much bigger than writing (you read big model, animation, or texture files, and write ~8x smaller), it was "parallelized" by prefetching files in the file cache reading them in a second thread in advance. Allowing only one writer to the HDD turned out to be beneficial (for cases like RAID SSD you can do multiple writers efficiently but this is rather pricey).