I use DMD and GDC. DMD for debug builds and (since it is the
reference compiler) to ensure language conformance. GDC for
performance tests and release.
In other terms, I don't expect the W3 reference browser to be
the fastest, but to set the required standard for HTML
interpretation.
If you asked m
On 01/26/2013 04:43 PM, mist wrote:
Yes, of course, we all have our own preferences, that is fine :) I mean a bit
different thing: front-end efforts affect all major compiler lovers, not only
one group and thus are more important.
Yup, agree. :-)
Yes, of course, we all have our own preferences, that is fine :)
I mean a bit different thing: front-end efforts affect all major
compiler lovers, not only one group and thus are more important.
On 01/26/2013 04:26 PM, mist wrote:
Once situation with front-end bugs and stability is settled, I see zero reasons
to use dmd back-end and spending efforts on its optimization feels not
pragmatical.
Actually, I feel somewhat the contrary. When the problem of frontend/runtime
portability has
On Saturday, 26 January 2013 at 15:17:18 UTC, Joseph Rushton
Wakeling wrote:
...
++
Once situation with front-end bugs and stability is settled, I
see zero reasons to use dmd back-end and spending efforts on its
optimization feels not pragmatical.
On 01/26/2013 02:37 AM, Walter Bright wrote:
If you're feeling ambitious, taking a closer look to see why would be most
interesting.
It's nice if DMD can produce faster code, but in the short term I'd rather see
priority being given to making the frontend/druntime more easily portable to
diff
On 1/25/2013 11:46 AM, H. S. Teoh wrote:
So I think at this
point it's fair to say that GDC's back end produces superior code in
terms of performance.
If you're feeling ambitious, taking a closer look to see why would be most
interesting.
On Fri, Jan 25, 2013 at 05:50:21PM +0100, John Colvin wrote:
> On Friday, 25 January 2013 at 16:09:00 UTC, H. S. Teoh wrote:
[...]
> >Conclusions:
> >- The performance gap is smaller than previously thought, but it's
> > still present.
> >- I will be using -inline with dmd aggressively.
> >- What
On 1/25/2013 9:45 AM, Rob T wrote:
I wonder what the main reasons are for the reduction?
Some reasons:
1. elimination of .h files
2. array & string handling was so much more straightforward
3. elimination of need for many constructors and code to initialize things
4. easier cleanup with scope
On Thursday, 24 January 2013 at 10:17:50 UTC, Walter Bright wrote:
On 1/23/2013 6:36 PM, Rob T wrote:
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
On Friday, 25 January 2013 at 16:09:00 UTC, H. S. Teoh wrote:
On Fri, Jan 25, 2013 at 04:09:25PM +0100, John Colvin wrote:
On Friday, 25 January 2013 at 13:38:03 UTC, Iain Buclaw wrote:
>On 25 January 2013 10:27, John Colvin
>wrote:
>
[...]
>>Comparing dmd -O and gdc -O3 is hardly fair. "dmd -
On Fri, Jan 25, 2013 at 04:09:25PM +0100, John Colvin wrote:
> On Friday, 25 January 2013 at 13:38:03 UTC, Iain Buclaw wrote:
> >On 25 January 2013 10:27, John Colvin
> >wrote:
> >
[...]
> >>Comparing dmd -O and gdc -O3 is hardly fair. "dmd -release
> >>-inline -O" is more comparable.
> >>
> >
> >
On Friday, 25 January 2013 at 13:38:03 UTC, Iain Buclaw wrote:
On 25 January 2013 10:27, John Colvin
wrote:
On Friday, 25 January 2013 at 01:41:12 UTC, H. S. Teoh wrote:
On Thu, Jan 24, 2013 at 03:18:01PM -0800, Walter Bright wrote:
On 1/24/2013 1:13 PM, H. S. Teoh wrote:
>On Thu, Jan 24,
On 25 January 2013 10:27, John Colvin wrote:
> On Friday, 25 January 2013 at 01:41:12 UTC, H. S. Teoh wrote:
>
>> On Thu, Jan 24, 2013 at 03:18:01PM -0800, Walter Bright wrote:
>>
>>> On 1/24/2013 1:13 PM, H. S. Teoh wrote:
>>> >On Thu, Jan 24, 2013 at 12:15:07PM -0800, Walter Bright wrote:
>>> >>
On Friday, 25 January 2013 at 01:41:12 UTC, H. S. Teoh wrote:
On Thu, Jan 24, 2013 at 03:18:01PM -0800, Walter Bright wrote:
On 1/24/2013 1:13 PM, H. S. Teoh wrote:
>On Thu, Jan 24, 2013 at 12:15:07PM -0800, Walter Bright wrote:
>>On 1/24/2013 8:36 AM, H. S. Teoh wrote:
>>>Nevertheless, I also h
On Friday, 25 January 2013 at 00:25:46 UTC, Joseph Rushton
Wakeling wrote:
If I remove the writef statements, leaving just the
number-crunching part, it runs in about 4s with gdmd, 7s with
ldmd2 and 14s (!) with dmd.
From my experience, writef and friends are substantially slower
than printf.
On Thu, Jan 24, 2013 at 03:18:01PM -0800, Walter Bright wrote:
> On 1/24/2013 1:13 PM, H. S. Teoh wrote:
> >On Thu, Jan 24, 2013 at 12:15:07PM -0800, Walter Bright wrote:
> >>On 1/24/2013 8:36 AM, H. S. Teoh wrote:
> >>>Nevertheless, I also have made the same observation that code
> >>>produced by
On 01/24/2013 05:36 PM, H. S. Teoh wrote:
I think it would be ideal if the dmd front end were more isolated from
the back end, so that it's easier to port to gdc/ldc (i.e. it can happen
in the matter of days after a dmd release, not, say, weeks or months).
Case in point -- today I got bitten by
On 01/25/2013 01:02 AM, Joseph Rushton Wakeling wrote:
but they reflect my typical experience with the different D compilers.
The caveat here is that these results are typical for _number-crunching_ code.
If the dominant factor in your program's speed is e.g. console output, you'll
find the d
On 01/24/2013 10:05 PM, Rob T wrote:
You are taking care to compare with full optimization flag settings? I'm sure
you are, but I ask just in case.
I use -O -release -inline typically (I use the dmd-ish interfaces for gdc and
ldc as well).
Absent any optimizations, executables seem to run at
On 1/24/2013 1:13 PM, H. S. Teoh wrote:
On Thu, Jan 24, 2013 at 12:15:07PM -0800, Walter Bright wrote:
On 1/24/2013 8:36 AM, H. S. Teoh wrote:
Nevertheless, I also have made the same observation that code
produced by gdc consistently outperforms code produced by dmd.
Usually by about 20-30%, so
On Thu, Jan 24, 2013 at 12:15:07PM -0800, Walter Bright wrote:
> On 1/24/2013 8:36 AM, H. S. Teoh wrote:
> >Nevertheless, I also have made the same observation that code
> >produced by gdc consistently outperforms code produced by dmd.
> >Usually by about 20-30%, sometimes as much as 50-60%, IME. T
On Thursday, 24 January 2013 at 10:42:10 UTC, Joseph Rushton
Wakeling wrote:
On 01/24/2013 11:16 AM, Walter Bright wrote:
If you use the 64 bit model, dmd will use SIMD instructions
for float and
double, which are much faster.
I generally find that dmd-compiled programs run at about half
the
There is also Plot2Kill, that David Simcha developed for his own
thesis, to do 2D drawings:
https://github.com/dsimcha/Plot2kill
I used it 1 (2?) years ago, and it worked well. It was quite nice to
be able to generate / manipulate data in D, and then to keep the same
powerful language for graphs
On 1/24/2013 8:36 AM, H. S. Teoh wrote:
Nevertheless, I also have made the same observation that code produced
by gdc consistently outperforms code produced by dmd. Usually by about
20-30%, sometimes as much as 50-60%, IME. That's a pretty big
discrepancy for me, esp. when I'm doing compute-inten
On Thursday, 24 January 2013 at 10:21:47 UTC, deadalnix wrote:
On Thursday, 24 January 2013 at 02:19:06 UTC, Era Scarecrow
wrote:
And use nothrow when it's applicable; Found with a sudoku
solver how much nothrow was making an impact on the algorithm
speed.
Do you know why? It shouldn't.
As
On 1/24/13 5:21 AM, deadalnix wrote:
On Thursday, 24 January 2013 at 02:19:06 UTC, Era Scarecrow wrote:
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 "goo
On Thursday, 24 January 2013 at 16:28:29 UTC, Joseph Rushton
Wakeling wrote:
On 01/24/2013 02:11 PM, John Colvin wrote:
Walter, I know you like working with the current backend and
you understand it
etc..., but this gives dmd a bus factor of 1 and is slowing
down code in the
process.
Honestl
On Thu, Jan 24, 2013 at 05:28:16PM +0100, Joseph Rushton Wakeling wrote:
> On 01/24/2013 02:11 PM, John Colvin wrote:
> >Walter, I know you like working with the current backend and you
> >understand it etc..., but this gives dmd a bus factor of 1 and is
> >slowing down code in the process.
>
> Ho
On 01/24/2013 02:11 PM, John Colvin wrote:
Walter, I know you like working with the current backend and you understand it
etc..., but this gives dmd a bus factor of 1 and is slowing down code in the
process.
Honestly, I don't feel this is too strong an issue. The point of dmd is to be a
refer
On Thursday, 24 January 2013 at 10:42:10 UTC, Joseph Rushton
Wakeling wrote:
On 01/24/2013 11:16 AM, Walter Bright wrote:
If you use the 64 bit model, dmd will use SIMD instructions
for float and
double, which are much faster.
I generally find that dmd-compiled programs run at about half
the
On Thursday, 24 January 2013 at 10:42:10 UTC, Joseph Rushton
Wakeling wrote:
On 01/24/2013 11:16 AM, Walter Bright wrote:
If you use the 64 bit model, dmd will use SIMD instructions
for float and
double, which are much faster.
I generally find that dmd-compiled programs run at about half
the
On 01/24/2013 11:49 AM, Walter Bright wrote:
Is that with floating point code, or otherwise?
Yes, quite heavily floating-point. I did once have a brief go at writing some
entirely integer-based number-crunching code just to see if it made any
difference, but I think other priorities interven
On 1/24/2013 2:41 AM, Joseph Rushton Wakeling wrote:
That's been a fairly consistent speed difference for a long time. And yes, I'm
using 64-bit.
Is that with floating point code, or otherwise?
On 01/24/2013 11:16 AM, Walter Bright wrote:
If you use the 64 bit model, dmd will use SIMD instructions for float and
double, which are much faster.
I generally find that dmd-compiled programs run at about half the speed of those
built with gdc or ldc (the latter seem pretty much equivalent t
On Thursday, 24 January 2013 at 02:19:06 UTC, Era Scarecrow wrote:
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
On 1/23/2013 6:36 PM, Rob T wrote:
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
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
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 a
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 wh
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
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
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 s
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 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 a
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 a
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 so
47 matches
Mail list logo
