Benchmark of D against other languages (page 3)

On Wednesday, 1 April 2015 at 08:52:06 UTC, bearophile wrote: > Andrei Alexandrescu: > >> Oh boy all classes with one-liner non-final methods. Manu must be dancing a gig right now :o). -- Andrei > > Yes, the right default for D language should be final, because lot of programmers are lazy and they don't add attributes. > > Bye, > bearophile As soon as we have a possibility to revoke attributes, that's not that bad. Just a little anecdote like "use final:" and everyone should understand and use it. How often have we had the debate of final as default? ;) Let's not lead to more pointless debates.

On Wed, 2015-04-01 at 07:48 -0700, Andrei Alexandrescu via Digitalmars-d wrote: > "Everybody" compared to "nobody". It's a statistics thing :o). You keep pulling me up for linguistic and logical inexactness, I feel no compunction… I trust your bit of the Alexandrescu tribe is doing well given the recent change of state. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

On Wednesday, 1 April 2015 at 20:31:18 UTC, novice2 wrote: > I am sorry for so dumb question, but: > when peoples talking about D and speed, > then they always say "mark method final". > Can DMD compiler do it itself, as one of optimizations? afaik there's no reason the compiler couldn't infer it for executables, but I could easily be wrong.

On 04/01/2015 10:31 PM, novice2 wrote: > Can DMD compiler do it itself, as one of optimizations? You could do it as part of LTO or whole program optimization. It requires another compiler/linker phase, so it's not easy to achieve, maybe the LDC/GDC people have LTO running? GCC5 comes with a big announcement about devirtualization. https://www.gnu.org/software/gcc/gcc-5/changes.html#general

On 04/01/2015 10:31 PM, novice2 wrote: > Can DMD compiler do it itself, as one of optimizations? Even more interesting a complete blog post about devirtualization. http://hubicka.blogspot.de/2014/02/devirtualization-in-c-part-4-analyzing.html

On Wednesday, 1 April 2015 at 22:15:42 UTC, Martin Nowak wrote: > On 04/01/2015 10:31 PM, novice2 wrote: >> Can DMD compiler do it itself, as one of optimizations? > > You could do it as part of LTO or whole program optimization. > It requires another compiler/linker phase, so it's not easy to achieve, > maybe the LDC/GDC people have LTO running? > > GCC5 comes with a big announcement about devirtualization. > https://www.gnu.org/software/gcc/gcc-5/changes.html#general Do you know if LLVM is getting anything similar?

On Wednesday, 1 April 2015 at 22:30:55 UTC, weaselcat wrote: > On Wednesday, 1 April 2015 at 22:15:42 UTC, Martin Nowak wrote: >> On 04/01/2015 10:31 PM, novice2 wrote: >>> Can DMD compiler do it itself, as one of optimizations? >> >> You could do it as part of LTO or whole program optimization. >> It requires another compiler/linker phase, so it's not easy to achieve, >> maybe the LDC/GDC people have LTO running? >> >> GCC5 comes with a big announcement about devirtualization. >> https://www.gnu.org/software/gcc/gcc-5/changes.html#general > > Do you know if LLVM is getting anything similar? Yes, there is active dev in LLVM to achieve the same kind of results.

April 01, 2015

Re: Benchmark of D against other languages

Posted by bearophile
in reply to Martin Nowak

Permalink

bearophile

Posted in reply to Martin Nowak

Permalink

Martin Nowak:

> GCC5 comes with a big announcement about devirtualization.
> https://www.gnu.org/software/gcc/gcc-5/changes.html#general

I have a small question. That page says:

"
A new set of built-in functions for arithmetics with overflow checking has been added: __builtin_add_overflow, __builtin_sub_overflow and __builtin_mul_overflow and for compatibility with clang also other variants. These builtins have two integral arguments (which don't need to have the same type), the arguments are extended to infinite precision signed type, +, - or * is performed on those, and the result is stored in an integer variable pointed to by the last argument. If the stored value is equal to the infinite precision result, the built-in functions return false, otherwise true. The type of the integer variable that will hold the result can be different from the types of the first two arguments. The following snippet demonstrates how this can be used in computing the size for the calloc function:

    void *
    calloc (size_t x, size_t y)
    {
      size_t sz;
      if (__builtin_mul_overflow (x, y, &sz))
        return NULL;
      void *ret = malloc (sz);
      if (ret) memset (res, 0, sz);
      return ret;
    }

On e.g. i?86 or x86-64 the above will result in a mul instruction followed by a jump on overflow.
"

Now both GCC and Clang have intrinsics to perform safe integral operations.

In recent versions of druntime/dmd there are functions to perform some safe integer operations. So is the API very well compatible with those intrinsics?

Bye,
bearophile

Forums