Slow performance compared to C++, ideas?

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Sun Jun 2 09:47:29 PDT 2013


On 06/02/2013 05:53 PM, Roy Obena wrote:
> You're making this up. I'm sure they do a lot of data-driven
> tests or simulations that make most errors detectable. They may
> not be savvy programmers, and their programs may not be
> error-free, but boat-loads of errors? C'mon.

I don't think he's making this up.  I would not want to make any assumptions
about any particular institutions, and I would like to believe that institutions
with large-scale, long-term computational projects have better practices, but I
think that most people in maths and physics research have very limited
experience of good code design and testing practices (working with D, and its
unit-testing framework and contract guarantees, has certainly been an eye-opener
for me).

Generally speaking it's true that in maths and physics there are often either
theoretical calculations or empirical data points for you to compare your
computational results to, so you can usually confirm that your program is doing
what it's supposed to, but not always.

There may not be boat-loads of errors in terms of output, but I bet there are
boat-loads of loopholes that will result in insane mistakes if the input were to
step outside the use-cases or parameter constraints the researcher has
considered.  I don't exclude my own code from that criticism, and the reason
it's tolerated is because it's often the quickest way to get to working code;
you know that you have to constrain parameters in such-and-such a way for it to
work, and you know that you _will_ constrain yourself accordingly.  But of
course it's easy to shoot yourself in the foot when you start tweaking things.
D's assert() and enforce() functions, and contract checks, are very useful here.


More information about the Digitalmars-d mailing list