Java is an all-purpose language. Check out jQuantlib and Marketcetera to get started.
All quant code in banks is in C++ , you will have better chances of a getting a
job if you do. Why software technicians keep asking the same question and always the answering the same things.
Quant job = C++ mastered. Most quants use Python for tools development & C++ for core apps don't kid yourself. Primary focus on performance is applicable to high frequency trading and market making systems.C++ is not always the fastest, in fact its predecessor C wins almost always hands down. Even there the bottle neck is networking and messaging not computation.
C++ code tends to be harder to understand and to express a mathematical problem in. Quants will find it that functional languages such as Haskell let them think about the problem rather than about language syntax.
Not that Java is that much better in this department as it yields verbose code. Java however has a huge advantage existing libraries and of a very robust software development toolbox for unit testing, continuous integration, refactoring and build process. The last one in my particular issue with C/C++. Fighting linker errors and dealing with messy makefiles create so much noise that performance gains pale in comparison.
If anyone here has a proven "system" for working with large code base of C/C++ code including third party libraries please post.
I must be in a bad dream? Or many of you are just confused in general about how things work on Wall St. Many sophisticated quantitative and computational finance work done today by the top buy side firms who are trading proprietary capital use C++ for core systems development. C++ will usually make up a bulk of the code base at these shops. Think stat/arb desks and market making firms. I can't think of any arb desk or MM firms today who has built their core systems on Java that is actually profitable.
Many algos developed at many firms for client facing order flow like DMA, dark pools, smart order routing etc.. Are usually developed in Java, C#, .NET etc.. and many of the tools and GUi around these systems. There are many reasons for this like better interoperability between GUI and back-end systems, larger pool of lower quality developers, client facing tools usually require much more customizations and rapid changes for client needs speed usually isn't the #1 priority compared to feature set.
Many firms today employ the same people an everyone is using very similar models in the end it's all about speed.
Plain and simple C++ allows a skilled programmer to squeeze much more optomizations out of his code than he could if using Java or C#.
Rodrick what you say is correct but is biased toward electronic markets like equities, futures etc. If you venture a little bit out of there into OTC traded fixed income and fixed income derivatives speed does not matter nearly as much. Sweet dreams.
Definition (wiki): "A quantitative analyst is a person who works in finance using numerical or quantitative techniques."
There is life outside Wall St(US) ;-). Also, there is front end, back end, trading, risk management, quants working for hedge funds, for trader, for rating agencies, for insurance companies, from high frequency to macro-economics, from research to day-to-day business and so on.
I don't understand this quant == trading (front end) + C++
Besides, all the statements without facts make discussion complicated. (E.g. Java is faster than C++, ok but the actual questions is how much).
Rodrick, again, if performance is the 'Key' for making money why you don't use assembler ? why C++ ?
In reality, JAVA or C# has capable to substitute C/C++, but since on Wall St. many sophisticated quantitative and computational finance application were written by C/C++(as Rodrick mentioned as well), therefore, it isn't necessary to spend money to convert all codes into JAVA or C#. JAVA is essential designed for web-application, C# inherited lots of new feature both of C++ and JAVA have(Initially for MSFT want to give a capability for all other type code converted into) . Look into JAVA & C#, they are just similar as C/C++ but adding some more features only.
If you pay attention to today's financial application, you might be able to find out certain new financial application's baseline code is done through C#.
Answering various questions:
David, you are right to ask the % difference, and as someone who used to review programming language implementations for PC Magazine, I can tell you with some authority that you cant get a good simple number.
The problem is that it's a differential equation with boundary conditions, and subjective.
In almost all cases, Java could be faster than C++
It isn't because the people who build the compilers and JVMs don't really take performance all that seriously.
This is unintuitive I believe ?
Fact is that C++ compilers waste a lot of clock cycles because they cannot know the nature of the machine they will run on. In fact you have to tell it what processor at compilation, and subtleties down to various numbers and cores / CPU cache can only be expressed by unpleasant code.
JVMs *could* do this because they know the machine they are running on.
But they don't.
The maths comes in because we have two time terms here.
Time to develop the code and time to run it.
Most code is simply irrelevant to the execution time, so if you free up the programmer from certain tasks which consume his effort, he has time to write faster code.
That I think answers the assembler vs C++ question, I believe the CQF is the only finance course that covers x86 assembler at all, and even we don't do al that much.
But.of course I can stick bits of assembler into my C++, which is something I do very sparingly, and if you find that a headhunter is writing code that goes several times faster than yours, consider despair or more education :)
So to test Java vs C++ properly you'd have to apply a time constraint to the development teams. Also you'd need to have equivalent skill in the teams.
Although Java has some features that some feel make it easier to develop, there is a surprising lack of objective evidence.
Partly I think this is because most of Java's "easier" features can seriously get in the way when you really care about speed. When I delete an object, I want the fucker dead *now*. At the limit I want to be able to tell the compiler how to translate my code, and if necessary I want to access useful operating system features.
Another factor is of course that hardware is typically cheaper than programmer time, meaning that a few cores can do more for you than changing language.
Back when I had the chance to get input into the new version of Excel, I fumbled the case for making VBA multi threaded, sorry. The reason I cared is that VBA is the 2nd most important quant language after C++, and although Excel >= 2007 is threaded, you only have one VBA instance :(
I believe the fact that VBA is #2 supports my case rather well. One can quickly knock together some code that mostly does what you want in an acceptable time. It interfaces nicely with spreadsheets (something Java doesn't), and can talk to every data source on the planet.
But Java programmers are cheaper, hard to quantify this is precisely, since on average they are less skilled and experienced, but a three year experienced Java programmer may easily be on 1/4 that of the C++ guy.
If anything, that ratio is increasing
This alters the economics. Tasks that do not require advanced techniques or high performance can be done as well in Java / C# as in C++, but more cheaply.
This is why banks use packs of cheap Indian programmers for housekeeping IT.
I didn't mention I used to be a CIO did I ?
I mention this because there is a clear division in the advice I give here.
Firstly, if you are a CIO, using Java allows you to buy cheap, medium quality programming time overseas. It also provides a good blame sink for the inevitable screw ups.
As a CIO you have no interest whatever in providing efficient reliable systems, indeed the techniques necessary to do so will hurt your political position.
But if you are writing code, Java is your enemy.
The function (supply, demand, substitability) = bad.price
Sunday, December 27, 2009
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment