QuoteOriginally posted by: jawabeantrading is a special case. i dont have experience in this field, but i would imagine that it's in the realm of real-time systems. in RT world both Java and .NET have issues. it's not just the latency, Java now is (almost) as fast as C/C++, and is definitely faster than any C/C++ hw/sw configuration of 10 years ago. the issue is that latencies r unpredictable, it actually is OS problem too. there r special RT OSs, maybe that's what u need.Which is why there is so much interest in linux. Linux lets you hack the operating system if you need to, and even if you don't need to, there are lots of people who know how the internals work that aren't owned by a single company. Also the thing about "special cases" is that they take up most of the work, and also produce most of the high paying jobs.Quotef u really need a special financial app server, then u can take Geronimo and jBoss. these r highly modularized systems. u can assemble your own app server from parts or replace/customize stock components to meet your needs.There are two issues. One is the legacy system issue. The firm has years if not decades of experience working on a particular system and interfacing the old and new systems is non trivial. The other is that a lot of financial programming is one-off systems, so there are no stock components, but rather components that you need to write. You end up with bizzarre Rube Goldberg systems.Quoteit saves a lot of time, you can lose performance here and there, but in total it's economically more productive. you wont need super-duper programmers too, just a couple of them to maintain the core, no more low-level multi-threading quizes on interviews. developers will b like commodities with standardized skills, and in ample supply, cheap.It basically boils down to the question is whether the loss of performance and functionality will cause you to lose more money than hiring super-duper programmers. In the financial arena, there is so much money involved and the business is so competitive, that yes, you will end up making more money by shelling out the cash and hiring the super-duper programmers. There are some super-duper programmers maintaining the core, but there are also people who have other skills maintaining the components.Also if development becomes a commodity skill, then it becomes possible for someone whose core expertise is in other places to pick up the skills. If programming becomes "easy" then the bank will likely not look for "cheap programmers" but will likely look for someone with skills in non-programming areas that has those commodity programmer skills. Which is sort of what is happening.

It's worth noting that by entering the world of poerating systems you are squarely dealing with C/C++ and leaving Java and C# behind.But hacking the operating system won't really solve the latency variability issues.Its a language thing, or more precisely a run time environment issue.C++ is the most imperative of the imperative languages. You tell C++ to free some memory, it's gone.You say "load this" and it is loaded. You say "put this here, exactly here, no where else", and lo ! it is so.C++ will do what you tell it, or die in the attempt, and it is of course the death toll that scares the weak and lazy.Java and C# think they know better than you, and if you're an average programmer doing average stuff like form filling apps and Monte Carlo, then it's probably right.But when they don't know better, you're screwed.

QuoteJava and C# think they know better than youWhen Java came out I noticed that it did not have operator overloads ... the designers in their wisdom said using the feature is confusing, so this is not possible:Matrix m3 = 0.5 * (m1 + m2) - offset;(for the record I know what matrices are)On paradigm: C++ is multi-paradigm (OO, generics AND modular (use it like C)). This gives the experienced developer great room for maneuver. In Java - like Smalltalk - everything is an object. Well, not exactly. Having said that I find C# to be a well-designed language BUT you have no(little) control over memory and other resources.

I want to say some words in C# defenseDefinitely correctly written unmanaged code is much faster then managed, but certainly no single human with less than a decade of experience can even begin to hope to create applications in one language where speed difference in executed code are the cause of slow downs and not inefficient algorithim implementation and design.Basically, it is unlikely, the chances highly remote that you'd ever run into the case where the "speed" differences would actually matter. The probability of encountering a scenario where languages create speed bottlenecks decreases with time. Processor and operating complexity further diminish this alleged spped gap.Remember, C# features JIT (just-in-time) compiling, or the ability to dynamically compile the application at runtime, allowing for theoretically better speed and performance than a C++ application.The efficiency of the code/algorythm does matter. One developer can write an app faster in C# than another in C++ because of better optimizations. While it is true that C#, practically speaking, is slower than C++, the optimizations that are possible in managed code do help offset some of its overhead costs. So, the difference is smaller than what one might expect.

QuoteOriginally posted by: bestdevBasically, it is unlikely, the chances highly remote that you'd ever run into the case where the "speed" differences would actually matter. The probability of encountering a scenario where languages create speed bottlenecks decreases with time. Processor and operating complexity further diminish this alleged spped gap.In normal business application software this is true. In hard real-time systems and algorithmic software, this is simply not true, and using any sort of interpreted language is going to give you a noticable slowdown even if you use just-in-time compilation. The efficiency in compiled code made Fortran the language of choice for numerical computing until around 1998 when the use of templates killed any speed advantage that Fortran had. I've noticed that a number of people have stated that in most cases this difference or that difference isn't important. However, the situations where it *does* make a difference are usually the important ones because those are the situations were you can find yourself in a competitive advantage. If you have code that can process 5000 bond prices per second, you could find yourself in a competitive advantage over a competitor that can only process 1500 bond prices per second, and that difference could be more than enough to pay for the cost of maintaining the faster code.

QuoteOriginally posted by: twofishQuoteOriginally posted by: bestdevI've noticed that a number of people have stated that in most cases this difference or that difference isn't important. However, the situations where it *does* make a difference are usually the important ones because those are the situations were you can find yourself in a competitive advantage. If you have code that can process 5000 bond prices per second, you could find yourself in a competitive advantage over a competitor that can only process 1500 bond prices per second, and that difference could be more than enough to pay for the cost of maintaining the faster code.I agree that C++ beats the shit of C# as far as performance if it is done right, but are most of the quants on that level of C++ development??

QuoteOriginally posted by: bestdevQuoteOriginally posted by: twofishI agree that C++ beats the shit of C# as far as performance if it is done right, but are most of the quants on that level of C++ development??One can put quant jobs along two axisinfrastructure versus modellingandworking with machines versus working with peopleWhat typically happens in a large organization is that you have someone that develops the models, maybe codes a rough sketch of the algorithm, and then works with someone that knows all of the tricks of C++ to optimize the code. The modeller has to have some knowledge of C++, and the C++ guru has to have some knowledge of quantitative modelling, but the two work with each other to produce very high performance code.

QuoteI agree that C++ beats C# as far as performance if it is done right, but are most of the quants on that level of C++ development??Can you quantify? My rule-of-thumbs is that C++ is about [20, 30]% faster than C# for number crunching. C# is much easier to write.So, it's a trade-off (optimisation problem)

QuoteOriginally posted by: twofishQuoteOriginally posted by: bestdevBasically, it is unlikely, the chances highly remote that you'd ever run into the case where the "speed" differences would actually matter. The probability of encountering a scenario where languages create speed bottlenecks decreases with time. Processor and operating complexity further diminish this alleged spped gap.In normal business application software this is true. In hard real-time systems and algorithmic software, this is simply not true, and using any sort of interpreted language is going to give you a noticable slowdown even if you use just-in-time compilation. The efficiency in compiled code made Fortran the language of choice for numerical computing until around 1998 when the use of templates killed any speed advantage that Fortran had. I've noticed that a number of people have stated that in most cases this difference or that difference isn't important. However, the situations where it *does* make a difference are usually the important ones because those are the situations were you can find yourself in a competitive advantage. If you have code that can process 5000 bond prices per second, you could find yourself in a competitive advantage over a competitor that can only process 1500 bond prices per second, and that difference could be more than enough to pay for the cost of maintaining the faster code.Dr Wang If I was your boss, I would load you with work. You seem to be having all the free time in the world.Jackie.

QuoteOriginally posted by: jackdanielsDr Wangonly TJ calls him that