Search results

Well, trading changed a lot since then, so I would not recommend those books I've read back then, except maybe "The disciplined trader" from Douglas and his "Trading in the zone". He oversimplifies trading a bit, attributing succes almost purely to psychology. It's not like that, however his...

When I started my trading career, 13 years ago, I read a lot of books. I think the best advice I read in all those book was this: get with a prop firm where people actually make money and learn from them. I still think this is the best advice anyone can give you. Trading never was easy...

ECN code written in Foxpro ... I dont know if I should laugh or cry. It surely explains all the ECN crashes back then ! Most funny Island crash I remember, must have been around 2002-2003, when the ECN crashed, came back up a few hours later but all orders were still live and executable, while...

Their site states: "4,400 individuals with Direct Market Access to over 10 major markets around the world."

The authorities had Peter by the balls, he had to shut down swift but he started a new company: http://www.orbixa.com which basically is just swifttrade in disguise.

Totally agreed that it's only a matter of time before Sterling is out of business. Their API is just a big fat joke. Using COM for API communication, LOL, COM was never designed for speed. It's obsolete and slow as hell. Socket based API, not going through the platform but directly to the...

Of course. It's just asking for problems to write stock exchange code for Windows. Not only because its TCP/IP layer is at least 3x slower, but also because you never know when your latency critical code is being executed and it can easily take 3000x more latency than a realtime OS like Redhat MRG

[/b] I guess you have never heard about a realtime OS ? Take a look here for example: http://www.redhat.com/products/mrg/realtime/ Ok, you obviously didnt try some C++ compiled software then. Very fine by me. But if you still want to make your point, then just send me a VERY simple...

Windows might schedule some interrupt handling between the hardware call and the report, which might add up to a lot of milliseconds. The thing is, that if you want to program directly to the TCP/IP layer for example, there will always be .NET libraries between that layer and your code...

Yeah, the HPET, but even though the timer itself is accurate, windows is NOT and hence the result is not. Still waiting on your answer though why my previous remark would be a 'ridiculous blanket statement'

However, I do want to add that regardless of the compiler, even if every *milli* second of *latency* is important, that windows (and hence C#) is NOT the way to go. Its top precision is around 15 ms and the OS is not real time at all (your code might easily be executed way later than 15 ms due...

Oops, that's a typo of course, I meant micro obviously.

Please explain yourself ?

Maybe the key to our differences is that we're talking about different things here. If you need to be THE fastest, then you don't have another option than C++ (or ASM, but I still think C++ would be the right choice). However this also comes with the need for steep monthly costs (easily more...

But anyway, it IS kind of depressing. To be among the fastest is getting more and more expensive by the day. a 40gbe connection (which offers several microseconds improvement over 10 gbe) to arca and nasdaq alone, together with data and some FGPA's will set you back around $50,000 per month. And...

You know, that's just theoretically not possible. C# uses .NET libraries. This means it is NOT code that is tailored to your specific needs. With C++ you can nail it down and only use code you really want.

That's something we finally agree upon. And you'll understand what this means. It's very grim outlook for the industry. We're already seeing that a handful of people rule the markets. And this will only get worse. Only the people with the deepest pockets will build their own dedicated hardware...

[/b] Maybe if you weren't so busy defending your C#, you would have actually read my posts and seen that I've been saying all along that C (NOT C# !!!) is as fast as ASM nowadays.

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++ ...

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. Again, same thing. Only reason a .net library would be faster would be if the C++ coder is not doing a good job. Anyway, getting back to our...