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

.NET HFT systems

  • Thread starter Thread starter Tsotne
  • Start date Start date
So do you find java and C# better for algos than C/C++ ignoring the speed concern? I have come across the similar article above and read many about C-based languages' comparison, some say one is better over another since the program execution speed is less, others talk in favor of languages which significantly decrease the development speed on the expense of little better performance and so on. One thing is clear: There is no one language which can be said is "better" than another. It depends on many things. If one was clearly "better" over another in all terms then that one wouldn't exist. But the widespread usage of the language talks for itself and it's usefulness forgetting about its disadvantages. I'm still interested in pure .NET (C#) written high speed programs and algos...
 
  1. If you ever want to work in a startup, avoid .NET. It does you no favors.
  2. If you are a startup looking to hire really excellent people, take notice of .NET on a resume, and ask why it’s there.

I think everything that needs to be said about that article is in the 500+ comments on the link you provided!
 
I think everything that needs to be said about that article is in the 500+ comments on the link you provided!

All the folks are defending .NET in the comments. That's a really interesting article and the lots of points raised there are subjects of debate.
 
So what’s the moral of this whole story? Two things:
  1. If you ever want to work in a startup, avoid .NET. It does you no favors.
  2. If you are a startup looking to hire really excellent people, take notice of .NET on a resume, and ask why it’s there.
http://blog.expensify.com/2011/03/25/ceo-friday-why-we-dont-hire-net-programmers/

I co-founded a startup (which I'm currently working at), and I used to work as a C# developer (part-time, when I was in school). Our first product is .NET-based and (depending on how you look at it) *much* faster than C/C++.

I won't post the link here (unless Andy OK's it) since I don't want people to think I'm spamming. If you're interested, I'll PM the link to you and you can see if it disproves your theory.
 
I co-founded a startup (which I'm currently working at), and I used to work as a C# developer (part-time, when I was in school). Our first product is .NET-based and (depending on how you look at it) *much* faster than C/C++.

I won't post the link here (unless Andy OK's it) since I don't want people to think I'm spamming. If you're interested, I'll PM the link to you and you can see if it disproves your theory.
(Not my theory)

JKPappas
I'd like to see the link please if you don't mind. I'm interested in such kind of stuff. Thanks in advance
 
I did not see anyone talk about the operating system. if we assume .NET == WindowsOS and C/C++ == Unix/Linux Or C/C++ == WindowsOS then we have many more things to compare. What about network stack latency on Windows vs. Solaris vs. Linux? What about bypassing the OS all together an running the HFT code in an FPGA on the network card? If round trip latency is the key to your
HFT system then reducing latency at all layers should be investigated.

Cheers,

Rich H.
 
I don't see the problem. If I know C#, but I also know C++, Java, Perl, Python, and F#, what's the problem? I would definitely say that it is bad that it is so easy, and if that is their only language then I would be suspect. However, if they have multiple languages, I just think it adds to the resume. It shows they branched out and learned something relatively new, rather than sticking with an older language because everybody says it is better.

Yes. .Net development is crazy easy, that's why I love it. I'm not a good programmer with C# yet, and I don't really know any Javascript, but I'm cooking up a website with my friends. It will have probably been less than a month from knowing nothing at all to launching a website, and you won't be able to tell if it was made by professionals or people like us.
 
I'd like to see the link please if you don't mind. I'm interested in such kind of stuff. Thanks in advance

Sure: GPU.NET

Basically, the idea is that you can write code similar to CUDA, but in C# (and within the next few months, VB.NET and F#). We also handle all of the memory management automagically. 99.9% of the codebase is F#, with the remainder in C#. Most of the things we do in GPU.NET -- transferring data, JIT-compiling device code, executing computations, etc. -- fall into the tens-of-microseconds to hundreds-of-milliseconds range.

I don't think there are a lot of .NET based startups out there, but we do exist. I think the reason you don't often hear about them is that most of them are B2B-focused and staffed by older developers (where "old" means >25), which doesn't provide a lot of material for a sensational headline.

So, back to the original topic -- it's certainly possible to write really fast, low-latency code on .NET / JVM. Does that mean you can write managed code which runs with *zero* latency? Of course not, there's still going to be some overhead from the VM doing things in the background -- with careful planning (and coding) though, you can shave that latency down to nearly nothing.

The way I look at it is: if you're looking to shave off every possible cycle and you're willing to spend any amount of money to achieve that, then you ought to be writing those parts of the code in assembler and/or using FPGAs with an integrated NIC. (Note : You might get similar performance from a Fermi-based nVidia Tesla, like a C2050, now that they support DMA with Mellanox/Infiniband.)

Most companies don't have an unlimited budget (in either money or time) though, so they have to compromise -- and that's where C/C++ has found it's niche. However, most of the C++ code I've ever seen could be nearly/just as fast if competently written in C# or F# (or even faster, in a few cases), and productivity would increase thanks to the *awesome* developer ecosystem built around .NET.
 
This thread popped back into my head today and I remembered something else worth mentioning: if you really, really need serious speed and want to code some parts of your app in native C++ but you'd also like to work with .NET -- wrapping your native code for use by some other .NET project, or perhaps you want to call into some .NET-based library -- check out C++/CLI. It's gone under other names before (e.g., "Managed C++") and it's not very well-known or frequently used (in my personal experience), but if you take the time to learn it, you'll get the best of both worlds.

If you want a book recommendation: "Pro Visual C++/CLI and the .NET 3.5 Platform" by Stephen R. G. Fraser. (Amazon)

Although it references the previous version of .NET, I don't think there's much you'll be missing from .NET 4.0 (that you'd care to use from C++, anyway). It covers everything in ultra-detail and also provides a good background on how .NET works under the hood -- important if you want to squeeze out every last bit of performance from a .NET app (in any language).
 
Back
Top