On 29.04.2011 14:48, Paulo Pinto wrote:
> There are no slow or fast languages, there are slow or fast implementations
> of a given language.
But is is quite seldom that some language has several implementations, that's
why compiler and language benchmarks are bound usually.
For example - p
It is always about compiler benchmark.
There are no slow or fast languages, there are slow or fast implementations
of a given language.
The only point that you can make about language related performance, is to
say that a given language
feature cannot be made to run any faster given the best c
On 28.04.2011 18:19, Daniel Gibson wrote:
> Furthermore this particular benchmark is a "programming language benchmark"
> and not a compiler benchmark, so it's fair to use every feature of the
> language.
But applicability of language features is a bit limited, I would say. I
think, this is
1500x1500:
I also did a little benchmarks. Here is the results:
Time for multiplying two 1000x1000 matrics:
clang 2.8 (-O3)2.4s
gcc 4.4.5 (-O3)2.5s
ldc2 llvm-2.9 (-O3 -release) 2.7s
gdc2 4.4.6 (-O3 -frelease -finline)2.9s
dmd 2.05
== Quote from Walter Bright (newshou...@digitalmars.com)'s article
> True, but dynamic arrays offer no inherent protection against overlap, though
> you can add a runtime check for that.
Another reason why we should have memory pool support in Phobos.
On 4/28/2011 9:10 PM, Don wrote:
D reduces the use of pointers. You can do much more with arrays.
True, but dynamic arrays offer no inherent protection against overlap, though
you can add a runtime check for that.
Jens Mueller wrote:
Andrei Alexandrescu wrote:
On 4/28/11 12:57 PM, Jens Mueller wrote:
Walter Bright wrote:
On 4/28/2011 9:19 AM, Daniel Gibson wrote:
But there's no need for a D compiler to optimize loops that just copy
parts of an array into another array (and similar stuff), because in D
On 4/28/11 7:53 PM, bearophile wrote:
Andrei:
C's restricts sets a poor example.
There are infinite things that a compiler can't prove about the code.
Restrict is particularly bad. See
http://www.lysator.liu.se/c/dmr-on-noalias.html (noalias was the initial
name of restrict).
Andrei
Andrei:
> C's restricts sets a poor example.
There are infinite things that a compiler can't prove about the code. Example:
the type system can't prove that @system code that uses pointer arithmetic
contains no bugs, pointers that go past arrays, etc. C99 restrict is just
another example where
On 4/28/11 4:14 PM, Jens Mueller wrote:
Walter Bright wrote:
On 4/28/2011 11:44 AM, Jens Mueller wrote:
Thanks. So if a compiler can assume that pointers do not alias it can
generate much better code. What's D's standpoint on that matter then?
C99 has restrict. I never came across something sim
Moritz Warning:
> When the contents are both const, then there won't be any writing
> to it, of course. In that case the same optimizations can be applied as
> when they point to different memory.
>
> both arrays point to different memory.
I see, thank you.
Bye,
bearophile
On Thu, 28 Apr 2011 17:44:35 -0400, bearophile wrote:
> Walter:
>
>> On 4/28/2011 11:44 AM, Jens Mueller wrote:
>> > Thanks. So if a compiler can assume that pointers do not alias it can
>> > generate much better code. What's D's standpoint on that matter then?
>> > C99 has restrict. I never came
Jens Mueller:
> That allows specifying that the memory pointed to is only readable which
> enables doing the optimizations. But what if the memory is writable but
> I can my sure that the pointers pointing to it will never alias? How do
> I pass that information to the compiler?
Here's my answer.
> "restrict" means "this pointer has no alias".
Jens Mueller is right, it's not just pointers, a.ptr and b.ptr are distinct but
they refer to memory zones that are not distinct:
auto a = [1, 2, 3, 4, 5];
auto b = [1 .. 3];
Bye,
bearophile
Walter:
> On 4/28/2011 11:44 AM, Jens Mueller wrote:
> > Thanks. So if a compiler can assume that pointers do not alias it can
> > generate much better code. What's D's standpoint on that matter then?
> > C99 has restrict. I never came across something similar in D.
>
> Const and immutable.
I do
Timon Gehr wrote:
> > That allows specifying that the memory pointed to is only readable which
> > enables doing the optimizations. But what if the memory is writable but
> > I can my sure that the pointers pointing to it will never alias? How do
> > I pass that information to the compiler?
> >
> >
> That allows specifying that the memory pointed to is only readable which
> enables doing the optimizations. But what if the memory is writable but
> I can my sure that the pointers pointing to it will never alias? How do
> I pass that information to the compiler?
>
> Jens
assert(p1 != p2); (or a
Walter Bright wrote:
> On 4/28/2011 11:44 AM, Jens Mueller wrote:
> >Thanks. So if a compiler can assume that pointers do not alias it can
> >generate much better code. What's D's standpoint on that matter then?
> >C99 has restrict. I never came across something similar in D.
>
> Const and immutab
bearophile wrote:
Andrei:
Cristi's GSoC project may target linear algebra operations.
That benchmark code is not a realistic example because don't write matrix
multiplications manually like that. But the benchmark has found a weakness in
array management that's important anyway.
Bye,
bearo
On 4/28/2011 11:44 AM, Jens Mueller wrote:
Thanks. So if a compiler can assume that pointers do not alias it can
generate much better code. What's D's standpoint on that matter then?
C99 has restrict. I never came across something similar in D.
Const and immutable.
On 28.04.2011 15:10, Francisco Almeida wrote:
On 28-04-2011 12:57, Moritz Warning wrote:
I think this might be interesting; it's also using D.
http://attractivechaos.wordpress.com/2011/04/25/my-programming-language-
benchmarks-plb/
Oh dear, the regex results for D are dreadful. An
Walter Bright wrote:
> On 4/28/2011 11:29 AM, Andrei Alexandrescu wrote:
> >It's simple - Fortran can assume that all data is unaliased (although
> >aliasing
> >is still technically possible). C, with its intensive pointer-based ethos
> >that
> >makes many aliasing-related optimizations difficult
On 4/28/2011 11:29 AM, Andrei Alexandrescu wrote:
It's simple - Fortran can assume that all data is unaliased (although aliasing
is still technically possible). C, with its intensive pointer-based ethos that
makes many aliasing-related optimizations difficult, has annoyed many a Fortran
aficionad
Andrei Alexandrescu wrote:
> On 4/28/11 12:57 PM, Jens Mueller wrote:
> >Walter Bright wrote:
> >>On 4/28/2011 9:19 AM, Daniel Gibson wrote:
> >>>But there's no need for a D compiler to optimize loops that just copy
> >>>parts of an array into another array (and similar stuff), because in D
> >>>yo
On 4/28/11 12:57 PM, Jens Mueller wrote:
Walter Bright wrote:
On 4/28/2011 9:19 AM, Daniel Gibson wrote:
But there's no need for a D compiler to optimize loops that just copy
parts of an array into another array (and similar stuff), because in D
you use slices for that - they're (probably) fast
Walter Bright wrote:
> On 4/28/2011 9:19 AM, Daniel Gibson wrote:
> >But there's no need for a D compiler to optimize loops that just copy
> >parts of an array into another array (and similar stuff), because in D
> >you use slices for that - they're (probably) faster and easier to use.
> >So IMHO i
On 4/28/2011 9:19 AM, Daniel Gibson wrote:
But there's no need for a D compiler to optimize loops that just copy
parts of an array into another array (and similar stuff), because in D
you use slices for that - they're (probably) faster and easier to use.
So IMHO it's fair to use slices where poss
Andrei:
> Cristi's GSoC project may target linear algebra operations.
That benchmark code is not a realistic example because don't write matrix
multiplications manually like that. But the benchmark has found a weakness in
array management that's important anyway.
Bye,
bearophile
Am 28.04.2011 18:10, schrieb Alexander:
> On 28.04.2011 17:44, Andrej Mitrovic wrote:
>
>>
>> But then these are not programming >language< benchmarks, they are
>> >compiler< benchmarks.
>
> "compiler benchmark" is something that sh
On 28.04.2011 17:44, Andrej Mitrovic wrote:
>
> But then these are not programming >language< benchmarks, they are >compiler<
> benchmarks.
"compiler benchmark" is something that should measure compilation speed, for
instance, but "language benchma
On 4/28/11 6:50 AM, bearophile wrote:
Moritz Warning:
I think this might be interesting; it's also using D.
I was about to post this :-)
The little benchmark:
http://attractivechaos.wordpress.com/2011/04/25/my-programming-language-benchmarks-plb/
http://attractivechaos.github.com/plb/
On 4/28/11 6:10 AM, Francisco Almeida wrote:
On 28-04-2011 12:57, Moritz Warning wrote:
I think this might be interesting; it's also using D.
http://attractivechaos.wordpress.com/2011/04/25/my-programming-language-
benchmarks-plb/
Oh dear, the regex results for D are dreadful. And the m
r/optimizer (and VM, if any) are - for (almost) same code, same
> algorithm.
But then these are not programming >language< benchmarks, they are
>compiler< benchmarks.
If you can get more performance out of a language with less code and
simpler syntax, then that language is better performing in my book.
On Thu, 28 Apr 2011 07:50:19 -0400, bearophile wrote:
> Moritz Warning:
>
>> I think this might be interesting; it's also using D.
>
> I was about to post this :-)
I was surprised you haven't had already.
Looks like I got lucky. :-)
Have you seen somewhere what compiler options he did use for g
Moritz Warning:
> I think this might be interesting; it's also using D.
I was about to post this :-)
The little benchmark:
http://attractivechaos.wordpress.com/2011/04/25/my-programming-language-benchmarks-plb/
http://attractivechaos.github.com/plb/
(The matrix mul code is not a r
On 28/04/2011 12:37, Alexander wrote:
On 28.04.2011 13:24, Robert Clipsham wrote:
I also notice lots of nested for loops in some of the tests, which should be
using slice operations really.
This is the whole point of benchmarking, IMHO - to see how good
compiler/optimizer (and VM, if any
On 28.04.2011 13:24, Robert Clipsham wrote:
> I also notice lots of nested for loops in some of the tests, which should be
> using slice operations really.
This is the whole point of benchmarking, IMHO - to see how good
compiler/optimizer (and VM, if any) are - for (almost) same code, same
a
On 28/04/2011 12:13, Robert Clipsham wrote:
On 28/04/2011 11:57, Moritz Warning wrote:
I think this might be interesting; it's also using D.
http://attractivechaos.wordpress.com/2011/04/25/my-programming-language-
benchmarks-plb/
Looks like this is using an old version of gdc along wi
On 28/04/2011 11:57, Moritz Warning wrote:
I think this might be interesting; it's also using D.
http://attractivechaos.wordpress.com/2011/04/25/my-programming-language-
benchmarks-plb/
Looks like this is using an old version of gdc along with D1, and it
performs abysmally on quite a f
On 28-04-2011 12:57, Moritz Warning wrote:
I think this might be interesting; it's also using D.
http://attractivechaos.wordpress.com/2011/04/25/my-programming-language-
benchmarks-plb/
Oh dear, the regex results for D are dreadful. And the matmul benchmark
result isn't too e
I think this might be interesting; it's also using D.
http://attractivechaos.wordpress.com/2011/04/25/my-programming-language-
benchmarks-plb/
42 matches
Mail list logo
