Dude, nbates said: 'My Experience started in '73 before Software & CPU's existed...' At least get some of the history of computer languages right... Fortran - 1957 Lisp -1959 Algol60 - 1960 Basic -1964 Simula - 1967 Unix OS - 1970 Pascal - 1971 C - 1972 Prolog -1972 Smalltalk - 1973 Some Hardware... CDC 7600 - 1968 Intel 4004 - 1971 Intel 8008 then 8080 - 1972 Dec PDP 11/45 Xerox Alto - 1973 As for the question by the OP, pick something that is 'free and open' and will run across several OSes and hardware platforms as you move forward... Cordially, -DD- "It's like they just gave you a new horse." -Dan Ingalls-
Could you put some light on this topic http://www.youtube.com/watch?v=YkapMQbbyEU I wish to hear from experts and please use plain English. Not a programmer here but Trading Algo developer and trader
http://java.sun.com/javase/technologies/realtime/index.jsp I am inclined to learn Java. However, i am on my first steps to develop a really fast ATS that might/could be a basis of a HFT system. My plan is to learn JAVA and Matlab to be able to communicate better with the real experts in these domains and to be able to design certain subcodes by myself. I am focusing on designing just one trading system. I am not interested to learn java and matlab to design other systems or explore other trading ideas. Please share
I've seen people use hybrid systems with Java and C++. Concept modeling and the high level stuff goes in Java, and the execution level, market data, etc... they do in C++. It kind of depends on what you want to do. The best approach is to just measure and go from there. Don't necessarily trust others' research, do your own.
The knock I've heard in the past about Java relates to its memory management (aka, garbage collection). The JVM will release memory based on an internal algorithm which cannot be overriden or user-defined. Consequently, when this memory cleanup becomes active, brief pauses can occur while an app is running, seemingly randomly. The concern/risk is this memory housekeeping may occur during some time-critical (HF) transaction, and the processing delay could adversely impact trade execution. It's been many years since I've heard anyone discuss this issue, so recent Java releases may contain improvements that solve this concern. And with today's blazingly fast CPU's, these types of memory mgmt concerns may no longer apply anyway. Any modern programming language will likely meet your performance/speed requirements. Probably more important is to select a language and IDE platform that enables you to achieve good design and testing.
I think the OP and a few others use "mission critical" and "high perfomance" as interchangeable terms. "Mission critical" first of all means "reliable"... and (assuming the programmer is equally good at all of them) C# and Java require less experince and effort to create code that works reliably and predictably. Yes, C++ gives more control to the programmer and as such is superior where there is a requirement to squeeze every last bit of perfomance from the platfom... especially in terms of memory management. It's not accidental that Tomcat (the most popular Java "servlet" server") was originally pure jave but parts of it were later implemented in C++. However, unlike Web-servers, you never ever want to see your "production" auto-trading platform "stretched". In a lot of algorithms the execution time scales linearly with a number of ticks. So, you want to keep the platform with lots and lots of spare capacity for when spikes of market activity generate faster tick streams. Yes, you may see some difference in performance between programming languages but you can achieve better performance gain by writing algorithms carefully and not doing something stupid (like storing every price-timestamp pair as a separate object). The thing is computers are cheeap and you want to dedicate your time to making the trading make more money, not work faster. Regarding garbage callection: 1) It never kicks in unless the application allocates and then frees a lot of memory (which would not be the best design decision in a trading application anyway) 2) The user algorithm can control to a very large extent when GC kicks in 3) With advancement of muticore platforms GC no longer totally freezes all threads for the duration of the pass. In other words the impact is far less severe than sources from 5-6 years ago may suggest. Also look at a related discussion http://www.elitetrader.com/vb/showthread.php?s=&threadid=213861
I would go java performance not an issue these days unless u need milli second req/responce and even then you would have to pay to have your program reside by your exchange to get that performance. I would look at easy of build implementation and when you take that into account java wins hands down 90% of what you need has already been built and is open source. Check this out I built this in Java the API is currently to IB TWS but could run with any broker that has an interface that gives mkt data and orders. http://www.youtube.com/watch?v=nOglE3wZjGo Took me 3mth 2-3hrs a day should be live in 2-3 weeks. Uses all open source components. My strategy wins 56% of the time and the management strategy return 1.8 times what it looses. TTYL James
I just wanted to add to the performance debate. In this case, C# vs F# vs C. I came across this recently (its from 2009): F# has better Performance than C# in Math Summary: "So it turns out that F# compiler creates code that is 2-6 times faster for the math code, compared to C# (while the output is still .NET compatible). And this F# code has performance close to the one of the C code." Take it for what its worth. Also F# is much easier (with less code) for mult-core, multi-threaded, and parallel programming. And you can mix F# and C# in .NET apps.
Are you guys seriously arguing over the merits of Java vs C# on a Windows system hooked up to a 10 gig ethernet exchange feed? I'm "fairly confident" that your first problem isn't going to be choice of high level language. If you're not hooked up like that, you're not running all that fast anyway, and could probably code it all up in Perl and have a shot at being fast enough.