I'm not going into details regarding my situation and code. I've done my own tests, both via observation and disassembling and have come to the conclusion that C# is just worthless when every nanosecond counts. Heck, Windows itself is totally worthless: it's not even realtime and its TCP/IP stack implementation is a joke. I don't care if you believe otherwise and wish you all the best with your algo's. Bye.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
Anyone coding in Assembler?
- Thread starter braincell
- Start date
Sure when nanoseconds count. That is one of the cases where I openly admitted all along that there are specific use cases where each language has its place, given you have a highly skilled coder who can make use of each language specific advantages.
However, I highly doubt nanoseconds matter to you ;-)
However, I highly doubt nanoseconds matter to you ;-)
Quote from luckybastard:
I'm not going into details regarding my situation and code. I've done my own tests, both via observation and disassembling and have come to the conclusion that C# is just worthless when every nanosecond counts. Heck, Windows itself is totally worthless: it's not even realtime and its TCP/IP stack implementation is a joke. I don't care if you believe otherwise and wish you all the best with your algo's. Bye.
Quote from luckybastard:
Do you have an example of ASM code that works more efficiently than the code a C compiler generates ? I always thought as well that I could write faster ASM code than Visual Studio could generate but after decompiling I was always amazed how well the code was optimized and came to the conclusion that there's really not much improvement ASM can give you ...
BTW why use olly when you can just view the disassembly directly in VS ?
I don't really have to provide an example myself, there are a lot of posts on the net regarding the screwups of C compilers.
On the other hand, I agree on some points with amazingIndustry.
Having coded in C# for a long time, there are certainly ways to make it almost as fast as C++. The biggest problem are the cache hit and miss, for speed. To narrow down your dicsussion, because I've participated in many such as the one you/we are having here, it comes down to how specialized you can make your code. There are special cases and programming styles that will make C++ faster than ASM and C# faster than C++, there's no arguing about that. So until we can disassemble every bit of code each one of us has ever coded and do high precision timing on it (a feat in itself), it's a moot point as to which is fastest.
As far as ASM is concerned, for the HFT it might provide some but not many benefits. This is because you can focus on specific bottlenecks and when coding in C, this allows you manouvering space (around the compiler) to make them very specific and efficient. Coding special networking or buffer management drivers in ASM can get very tedious I imagine, so in the end it wouldn't pay off. I don't have enough experience with HFT to really say much more on the subject.
thats what it comes down to: When coding close to hardware such as drivers and gpu components C++ and C definitely has its place. Well, you can do anything in C++ you can do in C# but the whole argument centers around ease and speed of development in C# vs pulling the last little peace of performance advantage out of algorithms with ASM, C, or C++. Nobody belittles C++ but calling .Net's CLR an incompetent piece of compiler and C# garbage only demonstrates that such person has not coded much in C# and especially has not worked with Version 4.0 and the new beta. Many sell-side investment banking development teams have switched over to C#, including some banks who turned to C# to re-write their entire pricing engine for derivatives rates and equity structures, a prominent French house comes to mind.
Quote from braincell:
I don't really have to provide an example myself, there are a lot of posts on the net regarding the screwups of C compilers.
On the other hand, I agree on some points with amazingIndustry.
Having coded in C# for a long time, there are certainly ways to make it almost as fast as C++. The biggest problem are the cache hit and miss, for speed. To narrow down your dicsussion, because I've participated in many such as the one you/we are having here, it comes down to how specialized you can make your code. There are special cases and programming styles that will make C++ faster than ASM and C# faster than C++, there's no arguing about that. So until we can disassemble every bit of code each one of us has ever coded and do high precision timing on it (a feat in itself), it's a moot point as to which is fastest.
As far as ASM is concerned, for the HFT it might provide some but not many benefits. This is because you can focus on specific bottlenecks and when coding in C, this allows you manouvering space (around the compiler) to make them very specific and efficient. Coding special networking or buffer management drivers in ASM can get very tedious I imagine, so in the end it wouldn't pay off. I don't have enough experience with HFT to really say much more on the subject.
Again, you're contradicting yourself. First you agree that when every nanosecond counts, then C# is worthless (hell, even timing anything below 15 ms accuracy is impossible within Windows) and then you say C# is great !?!?Quote from amazingIndustry:
thats what it comes down to: When coding close to hardware such as drivers and gpu components C++ and C definitely has its place. Well, you can do anything in C++ you can do in C# but the whole argument centers around ease and speed of development in C# vs pulling the last little peace of performance advantage out of algorithms with ASM, C, or C++. Nobody belittles C++ but calling .Net's CLR an incompetent piece of compiler and C# garbage only demonstrates that such person has not coded much in C# and especially has not worked with Version 4.0 and the new beta. Many sell-side investment banking development teams have switched over to C#, including some banks who turned to C# to re-write their entire pricing engine for derivatives rates and equity structures, a prominent French house comes to mind.
And like I said, the windows TCP/IP implementation is worthless as well (of course you can bypass that with an FPGA but I don't think there are even FPGA's that work with windows). In short, if latency REALLY matters, C# is just not going to be what you need.
That's an odd comment. All that means is that the compiler is smarter than the ASM programmer. Doesn't have anything to do with the language itself.There are special cases and programming styles that will make C++ faster than ASM
Again, same thing. Only reason a .net library would be faster would be if the C++ coder is not doing a good job.and C# faster than C++
Anyway, getting back to our main point, nowadays C compilers are so good that you really need a very smart ASM coder to beat the compiler (if even possible, in most cases it's simply not). And even then, the speed improvement is so marginal that it's greatly outweighted by the risk of coding errors. If you really believe you can beat the compiler, you can always use inline ASM code in your C code, but after comparing my own ASM code to what the C compiler came up with, time after time, I stopped bothering ..
you seem to be a very binary type of person, either its great or worthless. I never said C# is worthless nor have I claimed worthlessness for any other language or product. Maybe you want to differentiate a little more fine-grained, it would certainly help to find common ground, at your work as well as discussion with others.
Quote from luckybastard:
Again, you're contradicting yourself. First you agree that when every nanosecond counts, then C# is worthless (hell, even timing anything below 15 ms accuracy is impossible within Windows) and then you say C# is great !?!?
And like I said, the windows TCP/IP implementation is worthless as well (of course you can bypass that with an FPGA but I don't think there are even FPGA's that work with windows). In short, if latency REALLY matters, C# is just not going to be what you need.
Wow, you FINALLY GOT THE POINT, congrats!!!! If you have all the resources, top ASM or C programmers, and TONS of development time then you should program everything in ASM and C. You may live in a perfect world, most hedge funds, investment banks, certainly I, do not!!! Guess why most strategists use Matlab or R or Python, because you can't code a faster profiling platform from scratch in C? Certainly you can, but it all comes down to the trade off between speed and resources/time to get something up and running. I am glad you yourself realized it in the end.
Quote from luckybastard:
Anyway, getting back to our main point, nowadays C compilers are so good that you really need a very smart ASM coder to beat the compiler (if even possible, in most cases it's simply not). And even then, the speed improvement is so marginal that it's greatly outweighted by the risk of coding errors. [/B]
Look. Windows itself is not suitable for HFT trading (due to it not being realtime and Microsoft's bad TCP/IP stack implementation). But even if you don't need the box for trading but for back testing or whatever. Then why would a .net library be faster than what you could code yourself in C++ ? From my analysis, these .net libraries contain huge chunks of codes you will only partially need for most cases and hence slow you down.Quote from amazingIndustry:
you seem to be a very binary type of person, either its great or worthless. I never said C# is worthless nor have I claimed worthlessness for any other language or product. Maybe you want to differentiate a little more fine-grained, it would certainly help to find common ground, at your work as well as discussion with others.
Of course C# really earned its place in the programming world. If you need to build something quickly and speed isn't THE most important factor, then it's a great language and I'd take it anytime over C/C++