www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Newsgroups, off-topic

reply eles <eles eles.com> writes:
Hello,

 I just started using D (2.0). I have three or four questions:

 1) How to use the newsgroup link (e.g. news://news.digitalmars.com/
digitalmars.D.learn) to read the newsgroup? Is the "news://" protocol handled
by some program under Linux (Ubuntu, 64)? I write this using the HTTP interface
(e.g. http://www.digitalmars.com/pnews/indexing.php?
server=news.digitalmars.com&group=digitalmars.D) which is not very pleasant.
COuld we, at least, have an interface like the one used by archives? (e.g.
http://www.digitalmars.com/d/archives/digitalmars/D/
Re_value_range_propagation_for_bitwise_OR_108807.html)? And a SEARCH button?

 2) What is the status of complex numbers in D2? Is stated that module
std.complex will replace the built-in types cfloat, cdouble, creal, ifloat,
idouble, and ireal. When and... how?

 2a) Why the following program has the following output?

 import std.stdio;
real x;
ireal y;
creal z;

int main(){
	x=3;
	y=5i;
	z=x+y;
	writefln("x=%f",x);
	writefln("y=%f",y);
	writefln("z=%f",z);
	return 0;
}
=================================
x=3.000000
y=5.000000
z=3.000000+5.000000i

Since y is an ireal number, I would have expected to be written as 5.000000i,
not 5.000000. This is even more confussing as "%f" formatting seems to handle
well creal numbers, but not ireal ones.


 3) When DMD for Linux will be 64-bit, too? (Now it works, with multilib).
However, it is a nuisance to install multilib.

 Thanks everybody.

 Eles
Apr 16 2010
next sibling parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
eles wrote:

 Hello,
 
  I just started using D (2.0). I have three or four questions:
 
  1) How to use the newsgroup link (e.g. news://news.digitalmars.com/
 digitalmars.D.learn) to read the newsgroup? Is the "news://" protocol handled
 by some program under Linux (Ubuntu, 64)? I write this using the HTTP interface
 (e.g. http://www.digitalmars.com/pnews/indexing.php?
 server=news.digitalmars.com&group=digitalmars.D) which is not very pleasant.
 COuld we, at least, have an interface like the one used by archives? (e.g.
 http://www.digitalmars.com/d/archives/digitalmars/D/
 Re_value_range_propagation_for_bitwise_OR_108807.html)? And a SEARCH button?


The news:// protocol should be handled by a news reader.  Whether one is 
started automatically depends on whether you have one installed, and 
whether your browser handles such links correctly.

I am writing this from Thunderbird, which has a very capable news reader 
built in.



  2) What is the status of complex numbers in D2? Is stated that module
 std.complex will replace the built-in types cfloat, cdouble, creal, ifloat,
 idouble, and ireal. When and... how?


I am almost done writing a replacement for std.complex.  Some minor work 
remains, and then it will have to be reviewed/approved.  Assuming that 
goes well it shouldn't be too far away. :)



  2a) Why the following program has the following output?
 
  import std.stdio;
 real x;
 ireal y;
 creal z;
 
 int main(){
 	x=3;
 	y=5i;
 	z=x+y;
 	writefln("x=%f",x);
 	writefln("y=%f",y);
 	writefln("z=%f",z);
 	return 0;
 }
 =================================
 x=3.000000
 y=5.000000
 z=3.000000+5.000000i
 
 Since y is an ireal number, I would have expected to be written as 5.000000i,
 not 5.000000. This is even more confussing as "%f" formatting seems to handle
 well creal numbers, but not ireal ones.


The built-in complex numbers are weird in several ways.  The above will 
be addressed in the new std.complex.



  3) When DMD for Linux will be 64-bit, too? (Now it works, with multilib).
 However, it is a nuisance to install multilib.


The D2 language, which has so far been the "experimental branch" of D 
and as such has been a rapidly moving target, is in its final stages of 
completion.  The specification has more or less been frozen, and 
currently work is being done on bringing the DMD compiler up to spec. 
When this is done (this summer, I believe) work is supposed to start on 
a 64-bit compiler.

-Lars
Apr 16 2010
next sibling parent reply Joseph Wakeling <joseph.wakeling webdrake.net> writes:
Lars T. Kyllingstad wrote:

 The D2 language, which has so far been the "experimental branch" of D
 and as such has been a rapidly moving target, is in its final stages of
 completion.  The specification has more or less been frozen, and
 currently work is being done on bringing the DMD compiler up to spec.
 When this is done (this summer, I believe) work is supposed to start on
 a 64-bit compiler.


My concern about this is more along the lines of: when will D2 versions
of LDC and/or GDC be available?

To an extent I'm not sure I understand why, with two great backends
available, D2 development did not switch over entirely to one or the
other of these -- though I understand the fact that the DMD backend is
probably the one the Digital Mars developers are most comfortable with.
Apr 16 2010
parent reply Moritz Warning <moritzwarning web.de> writes:
On Fri, 16 Apr 2010 17:28:36 +0200, Joseph Wakeling wrote:


 Lars T. Kyllingstad wrote:

 The D2 language, which has so far been the "experimental branch" of D
 and as such has been a rapidly moving target, is in its final stages of
 completion.  The specification has more or less been frozen, and
 currently work is being done on bringing the DMD compiler up to spec.
 When this is done (this summer, I believe) work is supposed to start on
 a 64-bit compiler.


 
 My concern about this is more along the lines of: when will D2 versions
 of LDC and/or GDC be available?
 
 To an extent I'm not sure I understand why, with two great backends
 available, D2 development did not switch over entirely to one or the
 other of these -- though I understand the fact that the DMD backend is
 probably the one the Digital Mars developers are most comfortable with.


I think many people behind these compilers lack the personal motivation
to integrate the D2 front end.
That may change, but it may take time.

Some reasons I can think of:
- it's quite some work to integrate a new front end (there are a lot of 
new features in D2)
- D1 works quite well for many people and is more stable (important!)
- D2 doesn't offer much gain for many existing projects atm. (features 
vs. stability and transition cost)
- not everybody likes the road the D2 design takes

anyway, gdc has D2 support already (but not up to date/DMD), see http://
bitbucket.org/goshawk/gdc/overview
Apr 16 2010
parent reply Joseph Wakeling <joseph.wakeling webdrake.net> writes:
Moritz Warning wrote:

 I think many people behind these compilers lack the personal motivation
 to integrate the D2 front end.
 That may change, but it may take time.


Maybe true, but I was thinking of it from a different angle -- why the
main D2 development does not switch backends.  To be fair, the work
involved would surely detract from the main development effort on the
language and features.  I can also see the desire to have a backend that
is fully under the control of the main developers.


 - not everybody likes the road the D2 design takes


What are the concerns here ... ?  I don't currently have a strong enough
sense of the differences.


 anyway, gdc has D2 support already (but not up to date/DMD), see http://
 bitbucket.org/goshawk/gdc/overview


I've been following that D2 work for a while now, and am looking forward
to where it is going ... :-)

Best wishes,

    -- Joe
Apr 18 2010
next sibling parent BCS <none anon.com> writes:
Hello Joseph,


 I can also see the desire to have a backend
 that is fully under the control of the main developers.


There is also the point that if Walter never looks at the source for another 
compiler, it is nearly impossible for him to be sued for stealing from them.

-- 
... <IXOYE><
Apr 18 2010
prev sibling parent reply "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Joseph Wakeling <joseph.wakeling webdrake.net> wrote:


 Maybe true, but I was thinking of it from a different angle -- why the
 main D2 development does not switch backends.


So which do you suggest be used instead - the one that doesn't work on
Windows (no exceptions) or the one that requires Walter to give away
all rights to his work?

-- 
Simen
Apr 18 2010
parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Simen kjaeraas wrote:

 Joseph Wakeling <joseph.wakeling webdrake.net> wrote:
=20

 Maybe true, but I was thinking of it from a different angle -- why the=





 main D2 development does not switch backends.


=20
 So which do you suggest be used instead - the one that doesn't work on
 Windows (no exceptions) or the one that requires Walter to give away
 all rights to his work?
=20


	Actually, gcc doesn't require Walter to give away all rights to his
work just to use it as a backend (or else the gdc project wouldn't
exist). It would require ceding the rights only if Walter wanted D
to be part of the official gcc distribution.

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Apr 18 2010
next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
J=C3=A9r=C3=B4me M. Berger <jeberger free.fr> wrote:


 	Actually, gcc doesn't require Walter to give away all rights to his
 work just to use it as a backend (or else the gdc project wouldn't
 exist). It would require ceding the rights only if Walter wanted D
 to be part of the official gcc distribution.


You're right, I'm sorry.

-- =

Simen
Apr 18 2010
prev sibling parent reply Don <nospam nospam.com> writes:
Jérôme M. Berger wrote:

 Simen kjaeraas wrote:

 Joseph Wakeling <joseph.wakeling webdrake.net> wrote:


 Maybe true, but I was thinking of it from a different angle -- why the
 main D2 development does not switch backends.


 So which do you suggest be used instead - the one that doesn't work on
 Windows (no exceptions) or the one that requires Walter to give away
 all rights to his work?


 	Actually, gcc doesn't require Walter to give away all rights to his
 work just to use it as a backend (or else the gdc project wouldn't
 exist). It would require ceding the rights only if Walter wanted D
 to be part of the official gcc distribution.
 
 		Jerome


No, the problem is that it potentially makes him give away the rights to 
the dmd backend. Which I think he can't legally do, even if he wanted to.
Apr 20 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 20 Apr 2010 10:50:37 -0400, Don <nospam nospam.com> wrote:


 Jérôme M. Berger wrote:

 Simen kjaeraas wrote:

 Joseph Wakeling <joseph.wakeling webdrake.net> wrote:


 Maybe true, but I was thinking of it from a different angle -- why the
 main D2 development does not switch backends.


 So which do you suggest be used instead - the one that doesn't work on
 Windows (no exceptions) or the one that requires Walter to give away
 all rights to his work?


 	Actually, gcc doesn't require Walter to give away all rights to his
 work just to use it as a backend (or else the gdc project wouldn't
 exist). It would require ceding the rights only if Walter wanted D
 to be part of the official gcc distribution.
  		Jerome


 No, the problem is that it potentially makes him give away the rights to  
 the dmd backend. Which I think he can't legally do, even if he wanted to.


I don't think there is any danger of this, it would be well established  
that Walter wrote all his proprietary backend code before he viewed gcc  
source.  The danger is for future code he writes.

Personally, I am not too concerned about the backend performance, it's not  
critical to D at this time.  Someone, somewhere, will make this better,  
and then any code written in D magically gets faster :)  We're talking  
about decreasing the constant for the D compiler complexity, not  
decreasing the complexity.  Code built with dmd runs plenty fast for me  
(save the GC performance, maybe we can focus on that first?).

-Steve
Apr 20 2010
parent reply Joseph Wakeling <joseph.wakeling webdrake.net> writes:
Steven Schveighoffer wrote:

 No, the problem is that it potentially makes him give away the rights
 to the dmd backend. Which I think he can't legally do, even if he
 wanted to.


 
 I don't think there is any danger of this, it would be well established
 that Walter wrote all his proprietary backend code before he viewed gcc
 source.  The danger is for future code he writes.


I can see the concern here, certainly.


 Personally, I am not too concerned about the backend performance, it's
 not critical to D at this time.  Someone, somewhere, will make this
 better, and then any code written in D magically gets faster :)  We're
 talking about decreasing the constant for the D compiler complexity, not
 decreasing the complexity.  Code built with dmd runs plenty fast for me
 (save the GC performance, maybe we can focus on that first?).


I'm looking forward to seeing gdc released for D2 -- I think it will be
interesting to compare.  From what I understand part of the motivation
for reawakening it was a comparison of performance of code generated by
llvm and gcc respectively.

Part of my original issue over speed was that I'd heard D described as
'performance already as good as C++'.  So, I was coming with
expectations about what I'd be able to achieve ... :-)
Apr 23 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 23 Apr 2010 11:55:42 -0400, Joseph Wakeling  
<joseph.wakeling webdrake.net> wrote:


 Steven Schveighoffer wrote:

 Personally, I am not too concerned about the backend performance, it's
 not critical to D at this time.  Someone, somewhere, will make this
 better, and then any code written in D magically gets faster :)  We're
 talking about decreasing the constant for the D compiler complexity, not
 decreasing the complexity.  Code built with dmd runs plenty fast for me
 (save the GC performance, maybe we can focus on that first?).


 I'm looking forward to seeing gdc released for D2 -- I think it will be
 interesting to compare.  From what I understand part of the motivation
 for reawakening it was a comparison of performance of code generated by
 llvm and gcc respectively.


ATM, the bottleneck almost always is the GC.  And the gdc GC is the same  
as the dmd GC, meaning you'll get the same relative performance.  Like I  
said, you are decreasing the constant, not the complexity.  Creating a  
better GC algorithm would be a more effective speedup.  I think LLVM has  
its own GC, so that might be significantly different.


 Part of my original issue over speed was that I'd heard D described as
 'performance already as good as C++'.  So, I was coming with
 expectations about what I'd be able to achieve ... :-)


As long as you discount the vast differences in allocation performance,  
the code generated should be just as good as code generated by a C++  
compiler.  Your interpretation of performance did not focus on the right  
part :)  Your test application heavily used allocation and reallocation,  
things that have nothing to do with how fast the code compiled by the  
compiler is, but are based more on the algorithms behind the allocation.   
An equivalent C++-based GC would probably show similar performance (in  
fact, I think D's GC was based on a C++ GC).

This is all taken with a grain of salt of course, the perception is often  
more important than the technical details.  This thread being a prime  
example of it.

How I would characterize D when talking about performance is that it is  
possible to make it as high-performing as C++, but often favors memory  
safety over performance.  As far as syntax, D wins that battle hands down  
IMO.  And syntax is way more important to me than performance, especially  
at this stage of D's life.  Performance can always be tweaked and improved  
with few changes to the source code, but syntax changes can force you to  
have to modify an entire program.

-Steve
Apr 23 2010
parent reply Joseph Wakeling <joseph.wakeling webdrake.net> writes:
Steven Schveighoffer wrote:

 As long as you discount the vast differences in allocation performance,
 the code generated should be just as good as code generated by a C++
 compiler.  Your interpretation of performance did not focus on the right
 part :)  Your test application heavily used allocation and reallocation,
 things that have nothing to do with how fast the code compiled by the
 compiler is, but are based more on the algorithms behind the
 allocation.  An equivalent C++-based GC would probably show similar
 performance (in fact, I think D's GC was based on a C++ GC).
 
 This is all taken with a grain of salt of course, the perception is
 often more important than the technical details.  This thread being a
 prime example of it.


I do see the point about allocation and reallocation -- what was
bothering me a bit was that even taking those aspects out of the code
and preallocating everything, I could write C++ code that _didn't_
preallocate and still ran (much) faster ... :-)


 How I would characterize D when talking about performance is that it is
 possible to make it as high-performing as C++, but often favors memory
 safety over performance.  As far as syntax, D wins that battle hands
 down IMO.  And syntax is way more important to me than performance,
 especially at this stage of D's life.  Performance can always be tweaked
 and improved with few changes to the source code, but syntax changes can
 force you to have to modify an entire program.


Certainly agree about syntax -- it was not quite love at first sight,
but close.  In my case performance matters a lot, safety somewhat less
-- since I'm used to taking responsibility for it myself, and my
programming is quite small-scale.

As for perception, my perception is that I like D a lot and will surely
be using it more in future... :-)
Apr 23 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 23 Apr 2010 12:28:55 -0400, Joseph Wakeling  
<joseph.wakeling webdrake.net> wrote:


 Steven Schveighoffer wrote:

 As long as you discount the vast differences in allocation performance,
 the code generated should be just as good as code generated by a C++
 compiler.  Your interpretation of performance did not focus on the right
 part :)  Your test application heavily used allocation and reallocation,
 things that have nothing to do with how fast the code compiled by the
 compiler is, but are based more on the algorithms behind the
 allocation.  An equivalent C++-based GC would probably show similar
 performance (in fact, I think D's GC was based on a C++ GC).

 This is all taken with a grain of salt of course, the perception is
 often more important than the technical details.  This thread being a
 prime example of it.


 I do see the point about allocation and reallocation -- what was
 bothering me a bit was that even taking those aspects out of the code
 and preallocating everything, I could write C++ code that _didn't_
 preallocate and still ran (much) faster ... :-)


If you are comparing vector's push_back to D's array append after  
pre-allocating, you are still not comparing apples to apples...

Array appending is working without context -- it has no idea who owns the  
data or how big it is until it does a GC query.  vector owns the data and  
knows exactly how big it is, so no expensive lookup needed.  The benefit  
of D arrays is you can pass them, or slices of them, around without  
copying or worrying about them being deallocated very cheaply.

D's standard library should have a construct that duplicates the  
performance of vector, I'm not sure if there is anything right now.  I  
thought Appender would do it, but you have said in the past it is slow.   
This needs to be remedied.

-Steve
Apr 23 2010
next sibling parent Joseph Wakeling <joseph.wakeling webdrake.net> writes:
Steven Schveighoffer wrote:

 I do see the point about allocation and reallocation -- what was
 bothering me a bit was that even taking those aspects out of the code
 and preallocating everything, I could write C++ code that _didn't_
 preallocate and still ran (much) faster ... :-)


 
 If you are comparing vector's push_back to D's array append after
 pre-allocating, you are still not comparing apples to apples...


No ... !  That was true in the original code I posted, but following
bearophile's kind example that part of the code was updated to a form
along the lines of,

    x.length = 5_000_000;

    for(uint i=0;i<100;++i) {
        size_t pos = 0;
        for(uint j=0;j<5_000;++j) {
            for(uint k=0;k<1_000;++k) {
                x[pos++] = j*k;
            }
        }
    }

... which in itself indeed runs about the same speed as C++.  But that's
not the main cause of the difference in running time of the codes.


 D's standard library should have a construct that duplicates the
 performance of vector, I'm not sure if there is anything right now.  I
 thought Appender would do it, but you have said in the past it is slow. 
 This needs to be remedied.


It would be great -- but by itself it's not responsible for the timing
differences I'm observing.

Best wishes,

    -- Joe
Apr 23 2010
prev sibling parent reply Joseph Wakeling <joseph.wakeling webdrake.net> writes:
Joseph Wakeling wrote:

 No ... !  That was true in the original code I posted, but following
 bearophile's kind example that part of the code was updated to a form
 along the lines of,


Just for reference, here are the two pieces of code, for side-by-side
comparison.  As far as I can tell the algorithms are identical; the
results are certainly identical; and the D code is significantly slower
(on the order of half the speed on my machine).  I don't know what the
cause is, but my guess would be something along the lines of iterating
across or writing values to arrays in D.

The C++ code relies on the Boost libraries, another reason to like D2:
you get a lot of nice functionality built-in ... :-)

Best wishes,

    -- Joe
Apr 23 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 23 Apr 2010 14:00:50 -0400, Joseph Wakeling  
<joseph.wakeling webdrake.net> wrote:


 Joseph Wakeling wrote:

 No ... !  That was true in the original code I posted, but following
 bearophile's kind example that part of the code was updated to a form
 along the lines of,


 Just for reference, here are the two pieces of code, for side-by-side
 comparison.  As far as I can tell the algorithms are identical; the
 results are certainly identical; and the D code is significantly slower
 (on the order of half the speed on my machine).  I don't know what the
 cause is, but my guess would be something along the lines of iterating
 across or writing values to arrays in D.


I did a little review of the code, I concur that the code is pretty  
identical, and the D version does not really do any extra allocation.  I  
found one place where you were using pow(x, 2) to square something in the  
D version but doing it with simple multiplication in the C++ version, but  
that didn't account for any slowdowns when fixed.  I also saw some places  
where you write 0 to arrays several times, but removing those didn't help  
either.

My measurements were 2 minutes 2 seconds on D to 1 minute 20 seconds on  
C++, so not quite a 2x difference, but still significant.

I can only attribute the difference to g++'s more mature  
optimization/inlining techniques.  I can see why you are interested in  
having gdc working to try and compare the two :)

In spite of all this, I still remain convinced that there is nothing  
inherently bad about these results, D compilers can and probably will get  
better at optimizing code.  That it doesn't beat a compiler which has been  
in production/mainstream for many more years probably shouldn't be  
surprising to any of us, even though we want D compilers to perform the  
best.

-Steve
Apr 23 2010
next sibling parent reply Joseph Wakeling <joseph.wakeling webdrake.net> writes:
Steven Schveighoffer wrote:

 I did a little review of the code, I concur that the code is pretty
 identical, and the D version does not really do any extra allocation.  I
 found one place where you were using pow(x, 2) to square something in
 the D version but doing it with simple multiplication in the C++
 version, but that didn't account for any slowdowns when fixed.  I also
 saw some places where you write 0 to arrays several times, but removing
 those didn't help either.


Not several times superfluously?  I think I would be embarrassed if that
were true :-P


 I can only attribute the difference to g++'s more mature
 optimization/inlining techniques.  I can see why you are interested in
 having gdc working to try and compare the two :)


ldc already speeds things up somewhat (its inlining is better), but
still leaves a fairly sizeable gap.  There seem to be some fairly
sizeable performance differences between gcc and llvm:
http://www.phoronix.com/scan.php?page=article&item=apple_llvm_gcc&num=1

... which if I recall correctly was the motivation for the current gdc
team to start working on it again.


 In spite of all this, I still remain convinced that there is nothing
 inherently bad about these results, D compilers can and probably will
 get better at optimizing code.  That it doesn't beat a compiler which
 has been in production/mainstream for many more years probably shouldn't
 be surprising to any of us, even though we want D compilers to perform
 the best.


Completely agree here.  I was concerned based on early experience that I
was doing 'un-D-ish' things that were screwing performance, but now I'm
fairly confident that I can write OK D code.  From now on it will be all
pleasure as the compilers speed things up ... :-)

Thanks and best wishes,

    -- Joe
Apr 24 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sat, 24 Apr 2010 05:32:25 -0400, Joseph Wakeling  
<joseph.wakeling webdrake.net> wrote:


 Steven Schveighoffer wrote:

 I did a little review of the code, I concur that the code is pretty
 identical, and the D version does not really do any extra allocation.  I
 found one place where you were using pow(x, 2) to square something in
 the D version but doing it with simple multiplication in the C++
 version, but that didn't account for any slowdowns when fixed.  I also
 saw some places where you write 0 to arrays several times, but removing
 those didn't help either.


 Not several times superfluously?  I think I would be embarrassed if that
 were true :-P


Hm... I hate to embarrass you :)

I found it while manually inlining some functions (to try and see if that  
helps speed it up).  So it wasn't obvious until I saw the two lines  
together.

In Yzlm.objectReputationUpdate, you zero out reputationObject array, then  
call super.opCall, which also zeros out reputationObject.

It's understandable that this got introduced in the D version, you are  
doing something quite different than in the C++ version, swapping with  
another array and you were just being thorough.  I wouldn't be too  
embarrassed, and I note that it doesn't affect the runtime significantly  
anyways.


 In spite of all this, I still remain convinced that there is nothing
 inherently bad about these results, D compilers can and probably will
 get better at optimizing code.  That it doesn't beat a compiler which
 has been in production/mainstream for many more years probably shouldn't
 be surprising to any of us, even though we want D compilers to perform
 the best.


 Completely agree here.  I was concerned based on early experience that I
 was doing 'un-D-ish' things that were screwing performance, but now I'm
 fairly confident that I can write OK D code.  From now on it will be all
 pleasure as the compilers speed things up ... :-)

 Thanks and best wishes,


Good luck to you too!

-Steve
Apr 24 2010
prev sibling parent Joseph Wakeling <joseph.wakeling webdrake.net> writes:
On 04/23/2010 10:04 PM, Steven Schveighoffer wrote:

 My measurements were 2 minutes 2 seconds on D to 1 minute 20 seconds on
 C++, so not quite a 2x difference, but still significant.
 
 I can only attribute the difference to g++'s more mature
 optimization/inlining techniques.  I can see why you are interested in
 having gdc working to try and compare the two :)


Just a small note.  As per discussion on the D.gnu list, I installed an
alpha version of gdc2 based on the dmd 2.015 frontend and gcc 4.3.
There were difficulties in making a direct comparison -- compilation
problems which I guess are down to changes between 2.015 and 2.043 meant
I had to make some code tweaks -- but the speed of the gdc-compiled code
in terms of iterations per second did not seem much different to the
dmd-compiled code.
May 04 2010
prev sibling parent reply eles <eles eles.com> writes:
Thank you for your answer. I hope to see std.complex integrated in the next
release of dmd. I am mainly interested in scientific (i.e. numerical)
computations, so a good numerical library (GSL, Lapack etc.) would be welcome
in D.

I like the std.algorithm, though.

Eles

PS Thanks to everybody for pointing me to Thunderbird and Opera. Both are nice.

PS2 What does really means to use LLVM or GCC backends for dmd? Is a front-end
somewhat like a parser (or bytecode compiler) and the back-end something like
an assembler?
Apr 16 2010
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 04/16/2010 03:13 PM, eles wrote:

 PS2 What does really means to use LLVM or GCC backends for dmd? Is a front-end
 somewhat like a parser (or bytecode compiler) and the back-end something like
 an assembler?


Pretty much.

Except in the case of D, the front end also requires a backend of sorts 
(for ctfe), and from what I understand, DMD's frontend and backend are 
kind of squooshed together. (Like certain errors don't get caught unless 
and until the backend's optimizer gets run)
Apr 16 2010
parent Don <nospam nospam.com> writes:
Ellery Newcomer wrote:

 On 04/16/2010 03:13 PM, eles wrote:

 PS2 What does really means to use LLVM or GCC backends for dmd? Is a 
 front-end
 somewhat like a parser (or bytecode compiler) and the back-end 
 something like
 an assembler?





 
 Pretty much.
 
 Except in the case of D, the front end also requires a backend of sorts 
 (for ctfe),


  and from what I understand, DMD's frontend and backend are

 kind of squooshed together. 


Not really, the frontend compiles everything to an intermediate form, 
and then the backend converts the intermediate form into native code. 
There's not much interaction between them. In particular, the backend is 
the same backend used for C++. It doesn't have anything which is D-specific.

(Like certain errors don't get caught unless

 and until the backend's optimizer gets run)


That behaviour is fairly common in C++ compilers.
Apr 17 2010
prev sibling parent "Petru Avram" <avrampv gmail.com> writes:
On Fri, 16 Apr 2010 16:26:00 +0300, eles <eles eles.com> wrote:


 Hello,

 I just started using D (2.0). I have three or four questions:

 1) How to use the newsgroup link (e.g. news://news.digitalmars.com/
 digitalmars.D.learn) to read the newsgroup? Is the "news://" protocol=




 =


 handled
 by some program under Linux (Ubuntu, 64)? I write this using the HTTP=




 =


 interface
 (e.g. http://www.digitalmars.com/pnews/indexing.php?
 server=3Dnews.digitalmars.com&group=3Ddigitalmars.D) which is not ver=




y =


 pleasant.
 COuld we, at least, have an interface like the one used by archives? =





 (e.g.
 http://www.digitalmars.com/d/archives/digitalmars/D/
 Re_value_range_propagation_for_bitwise_OR_108807.html)? And a SEARCH =





 button?

 2) What is the status of complex numbers in D2? Is stated that module=





 std.complex will replace the built-in types cfloat, cdouble, creal, =





 ifloat,
 idouble, and ireal. When and... how?





Knode is for KDE but it is the best I have used so far. You can also
try Pan for Gnome (I heard it is the best) or you can try the new Opera
browser that has this feature included in the mail module (along many
other features =E2=80=93 I recommend downloading the preview deb package=
 of
Opera 10.5 from http://snapshot.opera.com/unix/snapshot-6317/ which is
usable as a browser too and is as fast/faster than Chromium (it uses
more memory though).

-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Apr 16 2010