• 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!

Quant programming languages of 2016? and GPU-wise: CUDA or OpenCL?

Joined
10/14/13
Messages
37
Points
18
I'm most likely doing my msc thesis in QCD (HEP phys). I want to chose a relevant programming lang and parallelisation method to quant. I largely have free reign on how I approach the project. I just need a parallel GPU method + high level lang.
  1. What are the main industry-standard GPU packages used in quant? Should I use CUDA or OpenCL
  2. What key programming languages do most firms look for on a CV? I know Fortran & Python and OpenMP / MPI. Should I focus on what I know or branch out into C/C++/Julia/F/ or even Assembler?
My gut says C++ & CUDA.

I've noticed OpenCl gaining a lot of traction (esp. in academia) & lots of weird languages popping up in job ads. last year eg. F, Julia etc.
 
Fortran is basically obsolete in the non-physics field, last I heard. Python is on the rise, and C++/C# will stay popular I think. Not sure about the other less common languages you listed.
 
In general: If I were you I'd also consider FPGAs -- they're definitely on the rise (and CUDA will be less appropriate for these than, say, OpenCL; not to say that OpenCL is necessarily optimal, however).

In any case, whichever combination of {multicore CPUs, GPUs, FPGAs} hardware you'll end up with, C++ will most likely be supported (which cannot be guaranteed about any other language at the moment). Note: This is to give you the broadest possible set of choices instead of being "the choice", because (read on)...

...In particular: "I want to chose a relevant programming lang and parallelisation method to quant."

No such thing as a "quant" -- and, by implication, no single "method" is going to be sufficient. Parallelization methods will vary, programming languages will vary, and no single general approach is "good enough". Thus, you definitely don't want to be a "one trick pony" and bet on one {language, parallelism} combination. The only thing this would guarantee is your skillset becoming obsolete very quickly.

To get an overview of the available choices among parallelization methods (and to be able to select ones that fit your particular problems at hand--which is the thing I'd recommend to learn), you may want to take a look at "Structured Parallel Programming":
- Structured Parallel Programming | Structured Parallel Programming
- http://parallelbook.com/sites/paral...Intel_McCool_Robison_Reinders_Hebenstreit.pdf
 
In general: If I were you I'd also consider FPGAs -- they're definitely on the rise (and CUDA will be less appropriate for these than, say, OpenCL; not to say that OpenCL is necessarily optimal, however).

In any case, whichever combination of {multicore CPUs, GPUs, FPGAs} hardware you'll end up with, C++ will most likely be supported (which cannot be guaranteed about any other language at the moment). Note: This is to give you the broadest possible set of choices instead of being "the choice", because (read on)...

...In particular: "I want to chose a relevant programming lang and parallelisation method to quant."

No such thing as a "quant" -- and, by implication, no single "method" is going to be sufficient. Parallelization methods will vary, programming languages will vary, and no single general approach is "good enough". Thus, you definitely don't want to be a "one trick pony" and bet on one {language, parallelism} combination. The only thing this would guarantee is your skillset becoming obsolete very quickly.

To get an overview of the available choices among parallelization methods (and to be able to select ones that fit your particular problems at hand--which is the thing I'd recommend to learn), you may want to take a look at "Structured Parallel Programming":
- Structured Parallel Programming | Structured Parallel Programming
- http://parallelbook.com/sites/paral...Intel_McCool_Robison_Reinders_Hebenstreit.pdf
Don't waste your time learning FPGA programming unless you want to do chip design. I learned how to do Verilog long time ago and I have never used it in finance in the last 10+ years.

if you want to learn parallel programming and apply it in finance, you are setting yourself to be a code monkey at the whims of others. You won't be a quant. You are going to be a glorified programmer.
 
thanks for the quick responses. v helpful.

Thus, you definitely don't want to be a "one trick pony" and bet on one {language, parallelism} combination.
totally agree but judging from the previous comment, doing a thesis in Fortran MPI would have limited applicability!

I am trying to choose combinations which, to be cynical, will have the highest "buzzword" impact and therefore greatest (probability) that I can "plug-n-play" a higher ratio of hiring managers' eyes. I think there are lots of more than capable postgrad quants looking for jobs but lots don't match job reqs closely enough. Lack of exp. in a library / lang used daily and CV ∈ Bin. This is what I am trying to preempt lest I make the same mistake.

w.r.t. to // algos, thanks for the material - I'll look through it in the holidays as I'm doing an advanced // algo module next sem.

Don't waste your time learning FPGA programming
that holds true with what I saw as an intern. Some CS guys in BO were doing FPGA on a project that was never actually going to be implemented. it was just for entertainment and their CVs from what they told me themselves.
 
Don't waste your time learning FPGA programming unless you want to do chip design. I learned how to do Verilog long time ago and I have never used it in finance in the last 10+ years.

IMHO 10+-years-ago experience is not very relevant today. It's a completely different hardware platform in terms of available solutions, productivity, and time-to-market trade-offs. Chances are that for many workloads it's going to offer better costs/benefits than, say, GPUs. As always, remains to be seen, though.
 
I'm most likely doing my msc thesis in QCD (HEP phys). I want to chose a relevant programming lang and parallelisation method to quant. I largely have free reign on how I approach the project. I just need a parallel GPU method + high level lang.
  1. What are the main industry-standard GPU packages used in quant? Should I use CUDA or OpenCL
  2. What key programming languages do most firms look for on a CV? I know Fortran & Python and OpenMP / MPI. Should I focus on what I know or branch out into C/C++/Julia/F/ or even Assembler?
My gut says C++ & CUDA.

I've noticed OpenCl gaining a lot of traction (esp. in academia) & lots of weird languages popping up in job ads. last year eg. F, Julia etc.
Do you want to be a quant or more the infrastucture stuff?
 
Thanks again for the replies... all very helpful.

there's 2 theses in the 2015 batch of MSc students from Birmingham
cheers, I actually briefly looked at that but was short on time. will look properly... are you able to comment on the type of jobs they got afterwards at all (I'm at the Higgs Centre in Edinburgh Uni so I have access to ARCHER for // code so may be able to do similar)

Do you want to be a quant or more the infrastucture stuff?
Quant. definitively: I love (and from my projects I seem to be good at) taking complex problems I know nothing about, researching a load of papers and implementing some sweet code. I think both exotics algo / electronic FX would both be very interesting.
 
My gut says C++ & CUDA.
As I heard about CUDA I was, myself, very excited about it.
Here is my poster what it can be used in quantitative finance for:
http://www.yetanotherquant.com/misc/EF2013_Poster_Nekrasov.pdf
And here is my paper, for which I used CUDA (source code is available):
Kelly Criterion for Multivariate Portfolios: A Model-Free Approach by Vasily Nekrasov :: SSRN

However, as far as I know CUDA has failed to conquer the financial world (i.a. due to suboptimal nVIDIA's marketing policy but it is another story). As to OpenCL, “no GPU vendor wants to implement OpenCL optimally because they have their own proprietary languages” (C. Davidson, "Chip and win: Banks expand use of GPUs". Risk magazine, Mar. 2013)

As to C++, yes, it is still popular but for example OpenGamma is written in Java.

Generally, a quant should be, first of all, able to create rapid prototypes (I, for one, do it in R; I also heard a lot of good things about Python; Scala is also getting popular).
 
Last edited:
CUDA and GPUs don't really work well with PDE (FDM is not SIMD).

BUT: using Alternating Direction Explicit (ADE) you can speedup of 5 on a 8-core Intel boxing using OpenMP with ONLY 1 pragma

#pragma omp parallel for

Try to get 5 speedup with CUDA?
 
RE: GPU computing... I currently do part-time research in deep machine learning (tensor matrices with massive multiplications to calculate taking days/weeks hence need for GPUs)

I use Python-theano which combines, in my opinion, the 'efficiency' of python development with GPU optimisation without having to waste time learning CUDA etc.

My point is that I already have these kind of tools "on lock" so my question, which I believe has already been answered is three fold:
  1. Would it be worthwhile doing my thesis in another language? yes to broaden skill set.
    • Which language? C++
  2. Do quants use languages like CUDA / OpenCL? Seems to be a "not really", unless you're more infrastructure/implementation rather than dev/research but useful to have proficiency.
 
RE: GPU computing... I currently do part-time research in deep machine learning (tensor matrices with massive multiplications to calculate taking days/weeks hence need for GPUs)

I use Python-theano which combines, in my opinion, the 'efficiency' of python development with GPU optimisation without having to waste time learning CUDA etc.

My point is that I already have these kind of tools "on lock" so my question, which I believe has already been answered is three fold:
  1. Would it be worthwhile doing my thesis in another language? yes to broaden skill set.
    • Which language? C++
  2. Do quants use languages like CUDA / OpenCL? Seems to be a "not really", unless you're more infrastructure/implementation rather than dev/research but useful to have proficiency.
The pain you are going to go through by implementing whatever you are doing in C++, won't be worth the hassle.
You already use CUDA through Theano. That's pretty much what you will be doing if you want to use GPUs (unless you want to drop to bare metal).

You want to do something worthwhile? Find out exactly what you want to do in finance, which products you want to deal with, where exactly you can fit better.
 
The pain you are going to go through by implementing whatever you are doing in C++, won't be worth the hassle.
I've persuaded my course organiser to let me do "Advanced // Methods" in C despite knowing jack about C programming: based on previous evidence I have in rapidly learning new languages. By extension, implementing a few core utils in C++ shouldn't be too much aggro as I'll probably need speed up in core iterations: real QCD simulations take a year to run on a super computer so even a stripped down case could take a long time.

I'll write the framework in python though because I'm not a sadistic fool but after your comments I think I'll probably avoid spending too much time in C++ just to 'demonstrate capability'.

I've already done a quant internship and figured out pretty much exactly where I want to be after that so I guess I'll just spend my time making sure my grades stay in the 90s.

Thanks again for the help. Much appreciated.
 
wtf?...! asm still top 10???? more people use matlab than ruby, swift, sql??? wtf?...!
have you ever written anything for embedded systems? I used to. Assembly is king with some C and the ASICs languages of the world.
 
Back
Top