On 05/17/2010 01:15 AM, Walter Bright wrote:
> bearophile wrote:
>> DMD compiler doesn't perform many optimizations,
>
> This is simply false. DMD does an excellent job with integer and pointer
> operations. It does a so-so job with floating point.
Interesting to note, relative to my earlier expe
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
Robert Clipsham wrote:
> This should do what you want:
Thanks! :-)
Is it possible to do this with an interface instead of a base class?
I'm not familiar with how the former work ...
Best wishes,
-- Joe
Hello all,
Occasionally in C++ I find it useful to build an array which contains
classes of multiple different types all using the same interface -- by
constructing an array of pointers to some common base class, e.g.
class BaseClass {
// blah, blah ...
};
class A : BaseClass {
// ... bl
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 multiplicatio
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
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 y
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 alloc
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 proprietar
bearophile wrote:
> Joseph Wakeling:
>
>> I took a little time last night and wrote up a C++ version that
>
> I'll take a look at this, I was away for few days.
Thank you very much!
No rush or even necessity -- I'm just curious if it sheds any light on
D-related issues. :-)
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
bearophile wrote:
>> This is the middle parts (the two loops) of Yzlm.objectReputationUpdate
>> compiled with ldc, this is one of the two main hot spots of the program, the
>> you can compared this asm with the asm of the same part from the C++ version:
>
> To find why the C++ code is faster you
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
bearophile wrote:
> You are right, sorry.
No need to apologise! You helped me significantly improve my code,
helped me understand D a lot better and left me feeling generally very
positive about developing further in D. I'd call that a result. :-)
>> So I think it's probably just compiler diffe
bearophile wrote:
> Robert Clipsham Wrote:
>
>> this way if/when
>> tango is ported to D2 it doesn't have to hack around this to allow it to
>> allow users to use ^^.
>
> I hope Tango2 will be designed to be installed beside Phobos2, and not in
> place of it.
I thought that was the aim ... ?
Hi Bearophile,
Thanks ever so much for the amount of effort you put into this -- it is
extremely kind and generous. :-)
I'm not seeing the significant gains that you see with DMD, but for me
too LDC doubles the speed.
My guess for the difference is that you ran less than the full 100
iterations
Don wrote:
> The D code compiles directly to a memset and memcpy, which are
> intrinsics. There's no way C++ could beat it.
OK. I'm just bemused about why -- having solved the memory leak -- my D
code is running significantly slower than equivalent C++ code.
For now I'm just playing with D by do
Steven Schveighoffer wrote:
> Assuming you may ask questions about this, it's not an exact description
> of what happens. The append code and GC are smarter about it than this,
> I just wanted to explain it in an easy-to-understand way :) The real
> code uses algorithms to determine optimal grow
Joseph Wakeling wrote:
> On the other hand, if the assumeSafeAppend takes place outside the loops
> entirely, blow-up occurs -- because the command is not issued after the
> array resize to zero? I've attached examples.
If I include a line
x.reserve(5_000_000);
before the as
Steven Schveighoffer wrote:
> This should work as you expect. Can you produce a full code example?
> Are you reserving space in x before-hand?
Weird; now it works. I wonder if because I upgraded to 2.043 ... ? I
understand there was a fix in there for array append.
On the other hand, if the a
Joseph Wakeling wrote:
> (Actually I'm still having some issues with this, despite using
> assumeSafeAppend, but more on that in a separate email.)
... solved; it's interesting to note that assumeSafeAppend has to be
used in _exactly_ the same scope as the append ~= itself.
e.g
Steven Schveighoffer wrote:
> On Mon, 12 Apr 2010 12:03:38 -0400, Joseph Wakeling
> wrote:
>
>> I thought dev effort was now focusing back on GDC ... ? :-P
>
> AFAIK, gdc hasn't been actively developed for a few years.
>
> ldc, on the other hand, has regular r
Thanks to all again for the discussion, examples and explanations. :-)
One note -- I wouldn't want anyone to think I'm bashing D or complaining.
I've been interested in the language for some time and this seemed an
opportune time to start experimenting properly. It's fun, I'm learning
a lot, and
Thanks very much for the extended and detailed explanations. The
assumeSafeAppend
function
indeed fixes the memory leakage. :-)
In reply to some comments ...
> > That is to be expected. The append function is not the most efficient
> > thing. It still must do a lot of work just to look up the
Hello all,
This one is another 'oh God it doesn't work like C++' query ... :-)
I've been having a problem with a memory leak that I've tied down to a dynamic
array that is repeatedly resized to zero and then extended within a loop. The
following code gives a minimal example:
///
> Also try:
>
> foreach(uint i;0..1) {
>scope Foo f = new Foo(i);
>// Do something with f ...
> }
>
> That sometimes doesn't require allocations.
To be sure I understand -- is there anything wrong with writing
scope auto f = new Foo(i)
... or, in general, using auto to infer the
I wrote:
> I guess I am worried about what could happen in the case of code like this in
> C++:
>
> for(i=0;i<1;++i) {
> Foo f(i);
> // Do something with f ...
> }
>
> ... when it reappears in D as:
>
> foreach(uint i;0..1) {
> auto f = new Foo(i);
>
Thanks for the interesting and detailed explanation. :-)
> Now you see, 'new' is for dynamic memory allocation in D as well, it's
> just that for classes it is required. You normally don't need to worry
> about 'delete', as the GC will take care of deallocation.
I guess I am worried about what c
Ali Çehreli wrote:
> I have experience with C++ and still don't understand why opCall exists.
> :) I think I heard that opCall was needed to create struct objects
> before structs had constructors in D.
>
> Now structs do have constructors, which sometimes conflict with opCall. :)
I also have some
Thanks to everyone for the responses.
I'll respond to Bearophile's detailed comments:
> Few notes:
> - opCall() of AvgWeighted was abstract.
> - keep in mind that in D classes are CamelCase;
> - variable names are written like weightSum (but once in a while a underscore
doesn't kill).
I think it
Hello everyone,
A probably stupid but I-can't-find-the-solution-with-Google problem.
I'm trying to compile a small project I'm working on to learn D, called
'dregs'. It's just 3 files for now (2 modules plus a little test program).
Unfortunately every time I try and compile, I get 'undefined ref
31 matches
Mail list logo
