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 =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

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

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

Windows (no exceptions) or the one that requires Walter to give away all rights to his work?

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 Joseph Wakeling <joseph.wakeling webdrake.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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
prev sibling next sibling parent 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
prev sibling next 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)

Apr 17 2010
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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.

Windows (no exceptions) or the one that requires Walter to give away all rights to his work?

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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "Petru Avram" <avrampv gmail.com> writes:
------------BuhZa6PwdDgKxcDACxKINr
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Content-Transfer-Encoding: Quoted-Printable

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=


 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/ ------------BuhZa6PwdDgKxcDACxKINr Content-Type: multipart/related; boundary=----------BuhZa6PwdDgKxchFaKF4Xq ------------BuhZa6PwdDgKxchFaKF4Xq Content-Type: text/html; charset=utf-8 Content-ID: <op.1271435298984.6edadd546d5dba03 79.116.55.230> Content-Transfer-Encoding: Quoted-Printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> <HTML> <HEAD></HEAD> <BODY style=3D"font-family:'Times New Roman'; font-size:13px"><DIV><BLOC= KQUOTE>On Fri, 16 Apr 2010 16:26:00 +0300, eles &lt;eles eles.com&gt; wr= ote:<BR></BLOCKQUOTE><BLOCKQUOTE><BR></BLOCKQUOTE><BLOCKQUOTE>&gt; Hello= ,<BR></BLOCKQUOTE><BLOCKQUOTE>&gt;<BR></BLOCKQUOTE><BLOCKQUOTE>&gt; I j= ust started using D (2.0). I have three or four questions:<BR></BLOCKQUO= TE><BLOCKQUOTE>&gt;<BR></BLOCKQUOTE><BLOCKQUOTE>&gt; 1) How to use the = newsgroup link (e.g. <A href=3D"news://news.digitalmars.com/">news://new= s.digitalmars.com/</A><BR></BLOCKQUOTE><BLOCKQUOTE>&gt; digitalmars.D.le= arn) to read the newsgroup? Is the "<A href=3D"news://">news://</A>" pro= tocol <BR></BLOCKQUOTE><BLOCKQUOTE>&gt; handled<BR></BLOCKQUOTE><BLOCKQ= UOTE>&gt; by some program under Linux (Ubuntu, 64)? I write this using t= he HTTP <BR></BLOCKQUOTE><BLOCKQUOTE>&gt; interface<BR></BLOCKQUOTE><BL= OCKQUOTE>&gt; (e.g. <A href=3D"http://www.digitalmars.com/pnews/indexing= .php">http://www.digitalmars.com/pnews/indexing.php</A>?<BR></BLOCKQUOTE=
<BLOCKQUOTE>&gt; server=3Dnews.digitalmars.com&amp;group=3Ddigitalmars.=

LOCKQUOTE><BLOCKQUOTE>&gt; COuld we, at least, have an interface like th= e one used by archives? <BR></BLOCKQUOTE><BLOCKQUOTE>&gt; (e.g.<BR></BL= OCKQUOTE><BLOCKQUOTE>&gt; <A href=3D"http://www.digitalmars.com/d/archiv= es/digitalmars/D/">http://www.digitalmars.com/d/archives/digitalmars/D/<= /A><BR></BLOCKQUOTE><BLOCKQUOTE>&gt; Re_value_range_propagation_for_bitw= ise_OR_108807.html)? And a SEARCH <BR></BLOCKQUOTE><BLOCKQUOTE>&gt; but= ton?<BR></BLOCKQUOTE><BLOCKQUOTE>&gt;<BR></BLOCKQUOTE><BLOCKQUOTE>&gt; = 2) What is the status of complex numbers in D2? Is stated that module<BR=
</BLOCKQUOTE><BLOCKQUOTE>&gt; std.complex will replace the built-in typ=

</BLOCKQUOTE><BLOCKQUOTE>&gt; idouble, and ireal. When and... how?<BR><=

ode is for KDE but it is the best I have used so far. You can also <BR>t= ry Pan for Gnome (I heard it is the best) or you can try the new Opera <= BR>browser that has this feature included in the mail module (along many= <BR>other features =E2=80=93 I recommend downloading the preview deb pa= ckage of <BR>Opera 10.5 from<A href=3D"http://snapshot.opera.com/unix/sn= apshot-6317/"> http://snapshot.opera.com/unix/snapshot-6317/</A> which i= s=C2=A0<BR>usable as a browser too and is as fast/faster than Chromium (= it uses <BR>more memory though).<BR> <BR>-- </DIV><DIV id=3D"M2Signature= "><DIV>Using Opera's revolutionary e-mail client: <A href=3D"http://www.= opera.com/mail/">http://www.opera.com/mail/</A></DIV></DIV></BODY></HTML=

------------BuhZa6PwdDgKxcDACxKINr--
Apr 16 2010
prev sibling next sibling 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
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 next sibling parent 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
prev sibling next sibling parent 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
prev sibling 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 next sibling parent 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
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