I saw an old thread from 2004 while doing a google search that discussed D and scientific computing and was looking for some more recent information or opinions from people who have used it for such purposes.

I am a graduate student and my thesis work is in numerical modeling. While I have some experience using Fortran and C, I am not obligated to use any particular language for my work. I like the design goals behind D and the syntax. I was would like to know if D can compete with C or Fortran for numerical work.

Is anyone out there using D for heavy numeric work?

On Wednesday, 23 January 2013 at 22:39:04 UTC, Alan wrote:
> I saw an old thread from 2004 while doing a google search that discussed D and scientific computing and was looking for some more recent information or opinions from people who have used it for such purposes.
>
> I am a graduate student and my thesis work is in numerical modeling. While I have some experience using Fortran and C, I am not obligated to use any particular language for my work. I like the design goals behind D and the syntax. I was would like to know if D can compete with C or Fortran for numerical work.
>
> Is anyone out there using D for heavy numeric work?

Hi Alan,

I use D to build a fairly large project to analyze whole genome sequences from multiple individuals. I will actually upload things into Bitbucket soon, I will let people on this forum know. I use it straight as a replacement for C++, that means I use it for all the numeric work I used C and C++ before.

To name a few highlights:
You can very easily adapt the code samples from Numerical Recipes 3rd edition (which are in C++) to D, with a lot more convenient built-in arrays and associative arrays.
Also, you can link the Gnu scientific library (GSL) straight into your D code. This actually had some bugs in previous versions of the compiler, but now it is really flawless.
I use the GSL vector class to do very fast Matrix-Matrix multiplications with GSL's blast interface. Also, I use GSL's special functions.

So I think D is ideal for scientific developers that start new projects. We don't have to convince huge teams to endeavour in a new language. We can just pick the best there is :-)

Stephan

On Wednesday, 23 January 2013 at 22:39:04 UTC, Alan wrote:
> I saw an old thread from 2004 while doing a google search that discussed D and scientific computing and was looking for some more recent information or opinions from people who have used it for such purposes.
>
> I am a graduate student and my thesis work is in numerical modeling. While I have some experience using Fortran and C, I am not obligated to use any particular language for my work. I like the design goals behind D and the syntax. I was would like to know if D can compete with C or Fortran for numerical work.
>
> Is anyone out there using D for heavy numeric work?

I actually forgot the main argument for me: D allows safe multithreading right out of the box, which is a huge advantage I think. I never wrote anything multithreaded before, until I started in D. I recommend Andrei's book, check out the two chapters that are linked on the D page.

Stephan

On Wednesday, 23 January 2013 at 22:39:04 UTC, Alan wrote:
> to know if D can compete with C or Fortran for numerical work.

https://github.com/kyllingstad/scid

You dont need to compete, you can take established "good and fast" FORTRAN/C code and use it within your own D program.

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...

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 don't 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 assembly, etc...

 And use nothrow when it's applicable; Found with a sudoku solver how much nothrow was making an impact on the algorithm speed.

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

My project will be working with the USGS Modflow model (a finite-difference model for groundwater flow written in fortran). Thankfully, it works with text input and output. So, the bit of the program I will be writing (which will talk back and forth to modflow through text) can be written in whatever language I choose.

I guess since the source code is available it might make sense to modify it to take i/o directly as a function called from D (if D is happy to do that).

I ordered Andrei's book a couple days ago and am oddly excited about it arriving. I have worked a bit with fortran, C, and C++. C++ needs to die. C is lacking a couple useful features (rather, it is more that they are not made as convenient to implement). Fortran does not have as many intrinsic functions and easy access to do "cool stuff" :P

I am glad to hear that D has been crunching numbers are a reasonable rate for you guys. My concern was that I will potentially be working on projects that might take a week or two to run on a small computer cluster and I do not want it to take four weeks to run something that I could run in two had I written it in Fortran.

On Wednesday, 23 January 2013 at 22:39:04 UTC, Alan wrote:
> I saw an old thread from 2004 while doing a google search that discussed D and scientific computing and was looking for some more recent information or opinions from people who have used it for such purposes.
>
> I am a graduate student and my thesis work is in numerical modeling. While I have some experience using Fortran and C, I am not obligated to use any particular language for my work. I like the design goals behind D and the syntax. I was would like to know if D can compete with C or Fortran for numerical work.
>
> Is anyone out there using D for heavy numeric work?

The different D compilers available don't generate numeric code of the same quality, depending on the algorithms and data structures used. I have found in one of my projects that LDC produces code that is up to 5x or even 10x faster than DMD (though the average difference is less spectacular).

On 1/24/2013 2:08 AM, Nicolas Sicard wrote:
> The different D compilers available don't generate numeric code of the same
> quality, depending on the algorithms and data structures used. I have found in
> one of my projects that LDC produces code that is up to 5x or even 10x faster
> than DMD (though the average difference is less spectacular).

If you use the 64 bit model, dmd will use SIMD instructions for float and double, which are much faster.