QuoteOriginally posted by: hennyQuotehow to make this code faster, or how to solve this type of equation they come and help you through.I personally believe that this kind of things can not be taught efficiently, especially if money is involved. Sure you can show them a general picture and tell them a couple of tricks but I bet you can't show them why it makes the code run faster. To understand how to make code run faster requires a relatively deep knowledge of complexity (and computability) theory (you are not talking "if a particular const is used in several places, give it a name"?) and this kind of knowledge can only be acquired by reading in the quiet room inside the Birtish Library ALONE.reading in the library is a pleasure, not many people can afford in a Bank, I guess. So I guess the other approach that DCFC is talking about makes sense.Here, we are talking about professionals, not beginners. They have to continue working, while learning. The desk is not going to shut down, to wait them to learn. And anyways reading, and even understanding is far far than enough to be able to apply efficiently and quickly. Nothing better than applying from first minute to real projects and applications. I personnally find ridiculous, sometimes insulting and too boring to keep any motivation if I have to some simple exercises that are supposed to teach me some technique, I prefer to go straight to a real application, I don't (over-)simplification, I'd rather scratch my head very hard from the first minute. For my part as a PhD student, I spend a lot of time reading on my own but also trying to make my applications as real-world as I can. Sometimes, I think if someone (expert) was there to pinpoint something, it would save me a lot of time and make my life a lot easier.

QuoteOriginally posted by: hennyQuotehow to make this code faster, or how to solve this type of equation they come and help you through.I personally believe that this kind of things can not be taught efficiently, especially if money is involved. Sure you can show them a general picture and tell them a couple of tricks but I bet you can't show them why it makes the code run faster. To understand how to make code run faster requires a relatively deep knowledge of complexity (and computability) theory (you are not talking "if a particular const is used in several places, give it a name"?) and this kind of knowledge can only be acquired by reading in the quiet room inside the Birtish Library ALONE.I disagree. I have spent a significsnt part of my career working on performance tuning projects with existing systems. I have observed, heard, and propagated a tremendous amount of misinformation about performance tuning. This work has not depended on an understanding of computability or even an understanding of O[N] notation. Systems are frequently slower than required or than the problem dictates because of what I call "dumb shit." Rarely is detecting and removing said shit dependent on understanding say queueing theory. If the system in question is small and well tuned to begin with then the barriers are higher. The systems I encounter tend to be anything but.Code that does nothingPhysical architecture that makes no senseCode that does something different from what the programmer expected *and* does it slowlyCode that does something thats unnecessaryCode that does something forgets the something then does the something again a short while laterCode that does something necessary but does it inefficientlyFinding these bad smells demands: some ability in applied science (experimenting)the guts to accept that we probably don't really know what happens when our code is executing (especially if multithreading is involved)pragmatisman awareness of what happens under the covers when a processor executes codean intuitive sense of how long things "should" takean awareness of where the dragon's lurk in the technology in question (e.g. Java: string operations, object creation, heavyweight objects) experience using some basic tricks and sophisticated tools to work out what is going on (stack dumps, vmstat, iostat, lsof, insertiung timing statements, OptimizeIt, JProbe, Quantify, an intuition that tells you when an architecture or design has a bad smellThe first three are character traits that I suspect are pretty common in quants. The remainder take time. I have found that smart junior programmers can be surprisingly effective at performance tuning if they get the right training and have access to expertise when they are stuck. What is cool or sad is that there is more bad code being written than bad code being fixed so there will always be an opportunity to add value by stabilizing and tuning flaky systems.

QuotemadmaxHere, we are talking about professionals, not beginners. They have to continue working, while learning. The desk is not going to shut down, to wait them to learn.Maybe not beginners...but if they need such mentoring/teaching on how to make code faster etc. then they are not professionals.

alohashirt, as far as I know we are not talking debugging here but making already running (but slowish) code to run faster.

QuoteOriginally posted by: hennyalohashirt, as far as I know we are not talking debugging here but making already running (but slowish) code to run faster.Many times the reason that code runs slow is that it doesn't do what the programmer intended, possibly producing the correct results via coincidence. An example is a multithreaded risk monitor I worked on that listens to price an dtrade events updating risk of a portfolio. It had a complicated, over-engineered cache logic that didn't actually work. In addition there were Ten threads "running" in parallel, only one of which is runnable the remainder wiating on locks due to unintended serialization of operations. These were both bugs and both caused performance problems.

QuoteOriginally posted by: alohashirtI disagree. I have spent a significsnt part of my career working on performance tuning projects with existing systems. I have observed, heard, and propagated a tremendous amount of misinformation about performance tuning. This work has not depended on an understanding of computability or even an understanding of O[N] notation. Systems are frequently slower than required or than the problem dictates because of what I call "dumb shit." Rarely is detecting and removing said shit dependent on understanding say queueing theory. If the system in question is small and well tuned to begin with then the barriers are higher. The systems I encounter tend to be anything but.I agree with everything you say alohashirt, although I have 1 small disagreement about O[N] notation. It's very basic math, pretty much common sense, just says the limit of a polynomial as x goes to infinity depends on the term w/ the largest power. I've seen plenty of code where there's been a linear search nested inside 1 or 2 other loops. Multiplying up the logn s, n^2s etc is back-of-the-envelope stuff you can do while coding. No excuse not to, imo, esp. when in C++ a decent stl will document the cost of the functions.Tone.

I'm not saying an understanding of data structures, algorithms and O(N) notation is not useful, just that in large applications that haven't had significant tuning, the major performance problems tend to have gross causes. I think this is more true with Java than C++/C, perhaps because it's easier to write a lot of bad code in Java that executes.