Taken from a real job ad:"Our client, a top tier hedge fund is seeking an exceptional low latency developer with C++, Boost, STL and multithreaded expertise."If they were seeking low latency they wouldn't be using Boost / STL / templates in the first place!Nothing like trying to squeeze out the last microsecond by jumping through vtables.

If I had to guess - maybe they're BSing. Then again, maybe the low latency code might be not be using any of that stuff, but they likely have other, non-performance critical code that does utilize it.

QuoteOriginally posted by: DSPGuyTaken from a real job ad:"Our client, a top tier hedge fund is seeking an exceptional low latency developer with C++, Boost, STL and multithreaded expertise."If they were seeking low latency they wouldn't be using Boost / STL / templates in the first place!Nothing like trying to squeeze out the last microsecond by jumping through vtables.there are no virtual functions in STL.

Low latency means that there is a critical path that has to execute really fast. It does not mean that each and every part of your system has to be blazing fast. For example, you can read your system configuration at startup from XML using boost and still have a high performance HFT system.Templates do not slow down your code by themselves, but can increase code size which can indirectly cause slow down.STL is really fast. One can run slightly faster without STL or by not using vtables at all but it is usually not worth it. How much do you think it takes to call a virtual function? Nanoseconds more than a regular one. There are few strategies in HFT that require that kind of latencies; most of them require decent latency and a smart algorithm.

QuoteOriginally posted by: DSPGuyTaken from a real job ad:"Our client, a top tier hedge fund is seeking an exceptional low latency developer with C++, Boost, STL and multithreaded expertise."If they were seeking low latency they wouldn't be using Boost / STL / templates in the first place!NIH syndrome? It's just madness trying to write yet another mouse trap.

QuoteOriginally posted by: nicka81Low latency means that there is a critical path that has to execute really fast. It does not mean that each and every part of your system has to be blazing fast. For example, you can read your system configuration at startup from XML using boost and still have a high performance HFT system.Templates do not slow down your code by themselves, but can increase code size which can indirectly cause slow down.STL is really fast. One can run slightly faster without STL or by not using vtables at all but it is usually not worth it. How much do you think it takes to call a virtual function? Nanoseconds more than a regular one. There are few strategies in HFT that require that kind of latencies; most of them require decent latency and a smart algorithm.Exactly!Many Boost libraries do not use subtype polymorphism (~ virtual) but static polymorphisn (CRTP)In 90% of cases STL and Boost do it better than I could ever do. So, concentrate what you are good at. The price of going virtual

Not if you are going for absolute speed.Presumably these boys are going for the last microsecond. I wonder how many people look at the asm code that's being generated? Or for that matter compare highly optimized 'C' to trendy C++ before making pronouncements? My point is for some reason they commingle low latency and STL / Boost,which to me seems ridiculous. Even 'C' that's too abstract gives up a lot.

QuoteOriginally posted by: DSPGuyTaken from a real job ad:"Our client, a top tier hedge fund is seeking an exceptional low latency developer with C++, Boost, STL and multithreaded expertise."If they were seeking low latency they wouldn't be using Boost / STL / templates in the first place!Nothing like trying to squeeze out the last microsecond by jumping through vtables.BTW, they want someone with low latency experience AND with C++, Boost, STL and multithreaded expertise, they never say the two are the same thing.

QuoteOriginally posted by: DevonFangsQuoteOriginally posted by: DSPGuyTaken from a real job ad:"Our client, a top tier hedge fund is seeking an exceptional low latency developer with C++, Boost, STL and multithreaded expertise."If they were seeking low latency they wouldn't be using Boost / STL / templates in the first place!Nothing like trying to squeeze out the last microsecond by jumping through vtables.BTW, they want someone with low latency experience AND with C++, Boost, STL and multithreaded expertise, they never say the two are the same thing.Well no, actually they're looking for a low latency developer with ... blah blah blah.Which implies that part of a low latency skill set is Boost and STL. Its like saying "is seeking an exceptional web developer with HTML, XML, Javascript and VHDL".Clearly the presence of VHDL on the list would be a head scratcher, whereas XML is ok.Or how about this "low latency developer with C++, DB2 and multithread expertise"Uhhh, DB2? Are they really looking for someone to squeeze code if they are list DB2?What is the likely hood that someone who's pounded code down has worked with DB2?

Maybe they need someone who will write some low latency code but will need to interface it or communicate somehow with code written by people in the other technologies ?

QuoteIf they were seeking low latency they wouldn't be using [...] templates in the first place!Addressing templates in particular -- they're often used as a tool for metaprogramming, where preprocessor is another tool used for this purpose.The impact on code generation, and thus on icache (if that's what you're worried about), is identical (and yes, this coming from someone who actually does look at the generated ASM) -- with one important difference, in that in practice templates impact on the generated code is easier to control (easier != easy, but every bit helps).At a very basic level, if you have ever used an #include directive, you've used preprocessor for metaprogramming.So, this statement is analogous to:QuoteIf they were seeking low latency they wouldn't be using [...] #include directives in the first place!I think this may just be a simple strategy to weed-out "developers" who don't know this.

QuoteOriginally posted by: bluetrinMaybe they need someone who will write some low latency code but will need to interface it or communicate somehow with code written by people in the other technologies ?Maybe they need someone who will write... better job specs:-)

QuoteOriginally posted by: DSPGuyNot if you are going for absolute speed.Presumably these boys are going for the last microsecond. I wonder how many people look at the asm code that's being generated? Or for that matter compare highly optimized 'C' to trendy C++ before making pronouncements? My point is for some reason they commingle low latency and STL / Boost,which to me seems ridiculous. Even 'C' that's too abstract gives up a lot.I once found a race condition by accident when looking at the asm code for a really simple loop. The compiler was reloading a value from memory after the comparison was done of a load of the same address. There was no guarantee that the value compared was the same as the reloaded value... lost data! When writing tight code I generally check that the compiler generates something along the lines of what I'd expect. I've seen throughput gains of 10% when one virtual was eliminated.

QuoteOriginally posted by: dd3QuoteOriginally posted by: DSPGuyNot if you are going for absolute speed.Presumably these boys are going for the last microsecond. I wonder how many people look at the asm code that's being generated? Or for that matter compare highly optimized 'C' to trendy C++ before making pronouncements? My point is for some reason they commingle low latency and STL / Boost,which to me seems ridiculous. Even 'C' that's too abstract gives up a lot.I once found a race condition by accident when looking at the asm code for a really simple loop. The compiler was reloading a value from memory after the comparison was done of a load of the same address. There was no guarantee that the value compared was the same as the reloaded value... lost data! When writing tight code I generally check that the compiler generates something along the lines of what I'd expect. I've seen throughput gains of 10% when one virtual was eliminated.One a related issue: is it possible to discover (potential) race conditions that did not occur when compiled for a 2-core machine (2 threads) but which did actualise when the app was installed on a 4-core machine (4 threads) by looking at asm code?

QuoteOriginally posted by: dd3QuoteOriginally posted by: DSPGuyNot if you are going for absolute speed.Presumably these boys are going for the last microsecond. I wonder how many people look at the asm code that's being generated? Or for that matter compare highly optimized 'C' to trendy C++ before making pronouncements? My point is for some reason they commingle low latency and STL / Boost,which to me seems ridiculous. Even 'C' that's too abstract gives up a lot.I once found a race condition by accident when looking at the asm code for a really simple loop. The compiler was reloading a value from memory after the comparison was done of a load of the same address. There was no guarantee that the value compared was the same as the reloaded value... lost data! When writing tight code I generally check that the compiler generates something along the lines of what I'd expect. I've seen throughput gains of 10% when one virtual was eliminated.what compiler was this? Some standard c/c++?