D for scientific computing

[Rob T]

On Thursday, 24 January 2013 at 00:35:13 UTC, Joshua Niehus wrote:
> On Thursday, 24 January 2013 at 00:29:15 UTC, Joshua Niehus 
> wrote:
>> You dont need to compete, you can take established "good and 
>> fast" FORTRAN/C code and use it within your own D program.
>
> I forgot to add:
> If you doing new stuff then D can be as fast as anything eles, 
> provided the algorithm is sound, optimizers turned on, sprinkle 
> in a lil asembly, etc...

.. also don't forget that there's a garbage collector which can 
have a huge impact on performance if you are doing a lot of 
memory allocations. The GC is adjustable to a degree, so 
performance problems can be solved provided that you are aware of 
them.

For example, I wrote a sqlite3 library in D, and for large SELECT 
returns it was 3 times slower than an almost identical C++ 
implementation.

The performance difference was resolved by disabling the GC prior 
to running the query and re-enabling afterwards. It was an easy 
fix, only two lines of code in one function.

BTW the D version of my sqlite3 lib is at least 1/3 smaller than 
the C++ version, and not only is it smaller, but it is far more 
flexible due to the use of templates (I just could not make much 
use out of C++ templates). A reduction like that is very 
significant. For large projects. it's a drastic reduction in 
development costs and perhaps more so in long term maintenance 
costs.

--rt