QuoteSo, what is more important, machine or human performance?Both. The program which doesn't produce correct results is useless no matter how fast it is. The program which takes ages to run is useless no matter how correct the results are.Ok, here are more maxims. Hope you find them entertaining .Speed is precision (=correctness), especially in Monte-Carlo business.Think low level, design high level.Speed isn't the only thing to optimize. Clarity matters too.Fast and clear code is better than slow and bloated code.Don't micro-optimize unless you are smarter than your compiler.Some people spend years devising clever numerical algorithms. Feel free to spend a few minutes optimizing your code.Less FLOPS doesn't mean faster code. Memory matters too.

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. ? C.A.R. Hoare, The 1980 ACM Turing Award Lecture--------------------------------------------------------------------------------The computing scientist's main challenge is not to get confused by the complexities of his own making. ? E. W. Dijkstra--------------------------------------------------------------------------------The cheapest, fastest, and most reliable components are those that aren't there. ? Gordon Bell--------------------------------------------------------------------------------One of my most productive days was throwing away 1000 lines of code. ? Ken Thompson--------------------------------------------------------------------------------When in doubt, use brute force. ? Ken Thompson--------------------------------------------------------------------------------Deleted code is debugged code. ? Jeff SickelMore at http://quotes.cat-v.org/programming/

QuoteOne of my most productive days was throwing away 1000 lines of code.? Ken Thompsonnice one. Of course he was not paid for LOC produced."get it working, then get it right, then get it optimised" anonRules (M. Jackson)Rule 1: don't optimiseRule 2: don't optimise, yet.

General question: What is the average numbers of REAL lines of C++ code produced by a developer per day? A guess is [5,15].

Quote 1: don't optimiseRule 2: don't optimise, yet.Counter-maxim.Fast code usually expresses the intent of the algorithm clearly.Slow code is usually bloated and hard to understand.High level optimizations can improve both speed and clarity.

QuoteWhat is the average numbers of REAL lines of C++ code produced by a developer per day? A guess is [5,15].Pattern heavy OOP can be very bloated and boilerplate. 5000 lines per day isn't unrealistic, but that can't go on forever. Debugging, testing and optimization usually takes much longer than the actual coding.It took me all Saturday evening to code Cuchulainn's 3D scheme - about 10 KBytes of course code (without doxygen or any inline comments) in 5-6 hours. That means about 50-60 lines per hour. The function responsible for memory optimization is only 30 lines long and took at least 2-3 hours to implement and test. Testing the whole program can take a day or two. That will drop the average output to about 50-100 lines per day.

QuoteOriginally posted by: jikanNo, C is not faster than C++ but what I meant is that it's easier to code faster code in C than C++ (well, except if you use C++ as a "better C", then it's just the same).This is actually a common misconception popular in the early pre-standard era (early 1990s, mostly), when the knowledge of C++ features was poor (some of the basic fundamentals, like templates were considered "too advanced") and compilers were of pretty low quality relative to more mature C compilers (at that time).I don't think it's true anymore. As renorm noted, there's (mostly) a subset relationship between the languages per se.But I think (I'm open to discussion) that it might go even further:You can achieve faster code in idiomatic C++ than a hand-crafted solution of the same problem in idiomatic C. For instance, compare implementation of an arbitrary map / reduce algorithm acting on an arbitrary data-structure via (C++) function objects applied to a data-structure with STL algos to (C) function pointers applied to a data-structure in a loop: operator() can be inlined, function passed-by-ptr -- not really. Hence, you'll have function-call overhead in C, while avoiding one in C++. C++ code will be also more elegant, easier to read, friendlier to maintain. What's not to like?Moreover, with function templates you can achieve a static/compile-time polymorphism, while attempting to achieve that by hand through the use of fn. ptrs. & selection statements (in other words: reinventing virtual functions) costs you in run-time (and ugly code).Finally, in the new standard r-value references give you easy-to-use, language supported, move semantics, so you can construct a huge container in a local (block) scope in a function and easily pass-it-up to the call site (btw, that's a better way to achieve the behavior of pass-by-ref--mutate--return-by-ref code snippet posted by Cuch.) without O(n) copying costs (at most some O(1) for internal pointer(s) reassignments, subject to compiler implementation/optimization). You have some of that even today (for a long time, in fact) in a form of (N)RVO for most modern implementations.I still hear plenty of embedded programmers swearing by C and while there is _some_ truth to _some_ of their statements (e.g. a particular C compiler for a particular micro-controller might produce a smaller code resulting in smaller memory footprint than the one produced by less mature C++ compiler for a given platform), in general I've grown rather skeptical toward claims of higher C performance.The bottom line is:- familiarize yourself with ISO/IEC TR 18015:2006(E) Technical Report on C++ Performance- check how the overhead measures apply to your compiler & platform/environment (and be sure to re-check when applicable), identify zero-overhead features and keep in mind the possibly-unacceptable-overhead ones,- based on that, select the features wisely (calibrating them to your task at hand), avoiding premature optimization _and_ premature pessimization,- enjoy the best of both worlds

QuoteIt took me all Saturday evening to code Cuchulainn's 3D scheme - about 10 KBytes of course code (without doxygen or any inline comments) in 5-6 hours. That means about 50-60 lines per hour. The function responsible for memory optimization is only 30 lines long and took at least 2-3 hours to implement and test. Testing the whole program can take a day or two. That will drop the average output to about 50-100 lines per day. This sounds about right. The LOC per day is somewhat less that [50, 100] when then new numerical method is being formed and developed.

QuoteOriginally posted by: CuchulainnQuoteIt took me all Saturday evening to code Cuchulainn's 3D scheme - about 10 KBytes of course code (without doxygen or any inline comments) in 5-6 hours. That means about 50-60 lines per hour. The function responsible for memory optimization is only 30 lines long and took at least 2-3 hours to implement and test. Testing the whole program can take a day or two. That will drop the average output to about 50-100 lines per day. This sounds about right. The LOC per day is somewhat less that [50, 100] when then new numerical method is being formed and developed.I think this is very hard to quantify. I just had a look at my last C++ project, last C# project and my current R project and did a small check over a week on each via subversion submissions. C++ was speed intensive so there was a lot of re-writing for optimization. C# was an API for a C# app with data stored in SQL. R is a data retrieval and data cleansing package. The LOC/d over a week average were: C++: 84, C#: 102, R: 427This is net lines so re-writing and refactoring included. I think the main difference is based on what type of projects were in questions since my skills at these languages are basically C#>C++>R.Like I said it's hard to quantify and no way of really netting these numbers. Because if you did the same project in all three you'd bias the first iteration down and the others up.

QuoteI think this is very hard to quantify. I just had a look at my last C++ project, last C# project At a basic level, C# does not have explicit const, &, -> and all that stuff in C++; and no separation of .hpp and .cpp.And no include issues; just bung all .cs files into the project and off you go.

QuoteOriginally posted by: CuchulainnQuoteI think this is very hard to quantify. I just had a look at my last C++ project, last C# project At a basic level, C# does not have explicit const, &, -> and all that stuff in C++; and no separation of .hpp and .cpp.How is the C# const different from C++? (not readonly but the keyword const). & and -> exist within C# but are considered unsafe.QuoteOriginally posted by: CuchulainnAnd no include issues; just bung all .cs files into the project and off you go.Well that would only work if you're working with all .cs files in the same namespace. On most stuff you'd need to define the namespaces to give access to in the same way an include would work from a general user perspective although the compiler perspective is quite different.

Why is C# Maths slow!(?)