-
C++ Programming for Financial Engineering
Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!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. Learn more Join!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. Learn more Join!
Bringing C++ to the 21st Century
- Thread starter pingu
- Start date
This is useful, but is more of an operational workaround/fix IMO.
There are deeper issues
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0142r0.pdf
There are deeper issues
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0142r0.pdf
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)
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:
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.
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.
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:
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:
When I said C++ Concurrency I was referring to a very specific part of the standard C++11 compiler, not external libraries.
Thread support library - cppreference.com
That's why I say it's not there yet.
Thread support library - cppreference.com
That's why I say it's not there yet.
Ah, in that case you are correct. Native support in C++ is a fairly recent thing.
I would like if they just supported TBB directly.
A really cool development is that you can write .NET applications in C++/CLI and mix freely with native C++ code.
C++/CLI - Wikipedia
C++/CLI - Wikipedia
I rather stay away from .Net
...
Any particular reasons apart from the fact what some people call the Evil Empire?I rather stay away from .Net
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#
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.
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..
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.
Last edited:
