• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering.
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Coming soon.
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models.

Bringing C++ to the 21st Century

ExSan

ExSan

Active Member
"Bringing C++ to the 21st Century"
21st century is gonna be plenty of multicore CPUs,
which CPU is good enough for a Quant -I mean for a C/C++ programmer (Python included)-, in term of Cores? 4, 8, 10?
 
Last edited:
Daniel Duffy

Daniel Duffy

C++ author, trainer
PPL and TBB

C++Concurrency is not there yet. It is too low-level for typical quant expertise level for parallel applications (IMO it is for experts),

PPL and TBB give you ready-to-run parallel patterns.

Parallel Patterns Library (PPL)
 
Last edited:
pingu

pingu

Well-Known Member
Daniel Duffy said:
PPL and TBB

C++Concurrency is not there yet.
Click to expand...
I don't think that's correct.

"fork" has been around for ages. The same applies OpenMP and MPI as well. These are well understood technologies. I have used OpenMP and it's very easy to use for certain tasks.

Python uses the multiprocessing package to achieve parallelism. It basically let the OS spawn processes for you. There are other packages that wrap multiprocessing (e.g. joblib) to make it even easier.

Another package that is starting to make inroads is dask. It makes use of multiple cores or even multiple nodes in a cluster relatively easy. I have used it as well with great success.
 
Daniel Duffy

Daniel Duffy

C++ author, trainer
You did not agree with C++Concurrency is not there yet (which is fair enough) but you did not tell me why. Your answers were non-C++ related, yes? Am I missing something?(?)

Sure, fork is just a general concept. It won't help when designing large systems. And there is a difference between low-level heavyweight thread and lightweight tasks.

I am saying that the average quant will find C++ threads a challenge.

I spent some time on all this stuff.
That PPL link is the state-of-art.

I have used OpenMP and it's very easy to use for certain tasks.
For the low-hanging fruit it's excellent. But OMP 2.0 is not scalable.

I do not think/sure traditional OOP and multi stuff are compatible. You need top-down task decomposition.

I see that dask uses a task graph. Like PPL.
 
Last edited:
pingu

pingu

Well-Known Member
Daniel Duffy said:
You did not agree with C++Concurrency is not there yet (which is fair enough) but you did not tell me why. Your answers were non-C++ related, yes? Am I missing something?(?)
Click to expand...
No, these are C++ related. Making use of multiple cores/multiple CPUs comes down to the compiler and the OS. OpenMP, MPI and fork are facilities that have been around for a while and are well understood. There is great support for these in modern C++ compilers on a single machine. If you are looking to scale to multiple nodes things are a little different. The OP mentioned multiple cores.

Also, how you achieve parallelism could be another point. You can use different processes or different threads. For different processes the solutions are well understood and the OS will take care of orchestrating the work for you. If we are talking about multiple threads, things are sort of easy if there isn't any modification of shared resources. Now, if you want to use multiple threads with shared resources and allow them to be modified, you are opening a can of worms that can unravel pretty quickly.

I know you mention TBB and PPL. These are fairly recent libraries. The facilities I mentioned predate those. Also, I think pthreads have been around since the 90s.

Don't get get me wrong. The newer facilities make parallel programming easier but the problems and solutions for parallelization are well understood and solutions have existed for years. This is nothing new.
 
Last edited:
Daniel Duffy

Daniel Duffy

C++ author, trainer
pingu said:
I rather stay away from .Net :)...
Click to expand...
Any particular reasons apart from the fact what some people call the Evil Empire?
and Excel is so easy in .NET


You can call C# from native C++
And we can wrap legacy C++ and offer it to C# developers.

The glue C++ <-> C++/CLI <-> C#
 
pingu

pingu

Well-Known Member
Daniel Duffy said:
Any particular reasons apart from the fact what some people call the Evil Empire?
and Excel is so easy in .NET


You can call C# from native C++
And we can wrap legacy C++ and offer it to C# developers.

The glue C++ <-> C++/CLI <-> C#
Click to expand...
I have been bitten by Windows too many times in the past. Things might be different now but I am so comfortable with UNIX platforms that I have no reason to go back. Nothing in particular against C# but the ecosystem around the OS.
 
Daniel Duffy

Daniel Duffy

C++ author, trainer
pingu said:
I have been bitten by Windows too many times in the past. Things might be different now but I am so comfortable with UNIX platforms that I have no reason to go back. Nothing in particular against C# but the ecosystem around the OS.
Click to expand...
You have a point. I believe C# runs in Linux (Mono?) these days but I have not looked into it. As a language, C# is very good.

I just hope I don't have to use Windows 10..
 
pingu

pingu

Well-Known Member
Daniel Duffy said:
You have a point. I believe C# runs in Linux (Mono?) these days but I have not looked into it. As a language, C# is very good.

I just hope I don't have to use Windows 10..
Click to expand...
Actually, I'm back in windows 10 in my laptop after years using Mac OSX and I don't dislike it as much as I thought.

Still use Linux for 90-95% of what I do though.
 
You must log in or register to reply here.
Top