On 28.04.2011 2:19, Alexander wrote:
On 27.04.2011 22:46, Dmitry Olshansky wrote:
- there is an awful lot of operations which allocate GC memory implicitly aka
arr1 ~ arr2, so it's not like you can pass the allocator and prevent the
function from allocating _somewhere_ else
This is solvab
On 2011-04-27 20:44, ulrik.mikaels...@gmail.com wrote:
Den, skrevJacob Carlborg :
> Yeah, that's correct. But in this case I think he actually was
referring to the latest commit. I'm pretty sure I've heard the latest
commit in SVN be referred to as "trunk".
I'm too curious for my own good, so I
On 2011-04-27 21:13, Andrei Alexandrescu wrote:
On 4/27/11 1:13 AM, Russel Winder wrote:
What also matters is that stuff that stays is stuff that gets done. You
seem to have a good amount of expertise, but at the same time choose to
firmly plant your figurative self in the proverbial armchair. I
On 2011-04-27 22:28, Daniel Gibson wrote:
Am 27.04.2011 22:13, schrieb so:
One thing that is perhaps obvious, but eludes me; when dropping the
delete-operator, are there any obvious reason to not also drop the
"new" keyword? ("new" is a fairly good method/variable name, if
nothing else)
I could
On 2011-04-28 00:15, Alexander wrote:
On 27.04.2011 22:42, Steven Schveighoffer wrote:
For non-garbage-collected languages, yes. For GC languages, delete is to be
discouraged (that is what the GC is for).
delete() is 99% of the cases O(1) operation (thanks to free lists), while
invocati
On 28.04.2011 10:14, Dmitry Olshansky wrote:
> That's your C++ experience speaking ;) It seems you just like manual memory
> management in c++ and can't see other ways.
This is not true, actually :) I agree, that GC is nice thing for most
applications, and I really like it, but, I simply
wa
On 28.04.2011 01:10, Andrej Mitrovic wrote:
> I really like the "in" keyword, and I also like hashes since they can
> potentially speed up look-ups compared to conventional arrays.
The problem is, "potentially" means "for [relatively] large sets", as hashing
overhead will kill the benefits for
Am 28.04.2011 10:28, schrieb Jacob Carlborg:
On 2011-04-27 22:28, Daniel Gibson wrote:
Am 27.04.2011 22:13, schrieb so:
One thing that is perhaps obvious, but eludes me; when dropping the
delete-operator, are there any obvious reason to not also drop the
"new" keyword? ("new" is a fairly good m
I think this might be interesting; it's also using D.
http://attractivechaos.wordpress.com/2011/04/25/my-programming-language-
benchmarks-plb/
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 encouraging either
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 few of t
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 with D1, a
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:46, Daniel Gibson wrote:
> ... so IMHO it makes sense for D to have the same syntax as the majority of
> these languages for the same feature (if that syntax doesn't have big enough
> drawbacks like <> for templates).
That's my point too. And especially this is true when some
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
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 realistic exampl
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
You seem to be right. It looks like DMD is pretty good at optimizing
if statements. The Hash version is quite a bit slower actually.
Well, that's what happens when I assume things. :)
Here's a little benchmark of searching an array and hash of randomly
generated strings:
http://pastebin.com/GddUn
On Wed, 27 Apr 2011 18:15:26 -0400, Alexander wrote:
On 27.04.2011 22:42, Steven Schveighoffer wrote:
For non-garbage-collected languages, yes. For GC languages, delete is
to be discouraged (that is what the GC is for).
delete() is 99% of the cases O(1) operation (thanks to free lists),
On 28.04.2011 16:25, Andrej Mitrovic wrote:
> Here's a little benchmark of searching an array and hash of randomly
> generated strings:
Make it 16 values and run again :) Sure, the more elements we have, the
better hash performs.
But in case of ints/floats, for instance, for small sets espe
On Wed, 27 Apr 2011 17:30:54 -0400, Alexander wrote:
On 27.04.2011 19:13, Steven Schveighoffer wrote:
clear is not a keyword, it is possible to name a member clear, and also
have a clear global function.
Sure it is, though it is counter-intuitive - to use same name with
quite different
On 28.04.2011 16:52, Steven Schveighoffer wrote:
>> delete() is 99% of the cases O(1) operation (thanks to free lists),
>
> Not exactly, it still needs to update the metadata for the block, which
> involves a binary search (O(lgn)) + you have to take the global lock, which
> means you could b
"InSet!(var, values...)."
That wouldn't work because var is known only at runtime. Ideally I'd
like to write something like:
string needle = "foo";
if (needle.InSet!("bar", "barfoo", "doo", "foo")) { }
And InSet would mixin and call a function such as:
bool inSet(string needle)
{
if (needle
On 28/04/11 4:24 PM, Andrej Mitrovic wrote:
"InSet!(var, values...)."
That wouldn't work because var is known only at runtime. Ideally I'd
like to write something like:
string needle = "foo";
if (needle.InSet!("bar", "barfoo", "doo", "foo")) { }
And InSet would mixin and call a function such a
On Thu, 28 Apr 2011 11:11:41 -0400, Alexander wrote:
On 28.04.2011 16:52, Steven Schveighoffer wrote:
delete() is 99% of the cases O(1) operation (thanks to free lists),
Not exactly, it still needs to update the metadata for the block, which
involves a binary search (O(lgn)) + you have
On 4/28/11 3:24 AM, Jacob Carlborg wrote:
On 2011-04-27 21:13, Andrei Alexandrescu wrote:
On 4/27/11 1:13 AM, Russel Winder wrote:
What also matters is that stuff that stays is stuff that gets done. You
seem to have a good amount of expertise, but at the same time choose to
firmly plant your fi
On 4/28/11, 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)
It works, but it makes the if statement ugly again. :)
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 matmul
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/
(The m
On 28.04.2011 17:32, Steven Schveighoffer wrote:
> This is not how it's implemented. The metadata is kept in a separate page
> from the memory itself.
Huh? Could you please elaborate, what do you mean by "metadata" and why it
has to be kept on a separate page?
I've seen at least one GC im
On 28.04.2011 17:46, Andrej Mitrovic wrote:
> It works, but it makes the if statement ugly again. :)
Well, just a bit - still much better than (var == "..." || var = "..." || var
== "..." ...), don't you think so? ;)
If compiler would support special "in" usage, automatically expanding valu
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 benchmark" shows how good specific language (+
com
On 4/28/11 11:00 AM, Alexander wrote:
On 28.04.2011 17:46, Andrej Mitrovic wrote:
It works, but it makes the if statement ugly again. :)
Well, just a bit - still much better than (var == "..." || var = "..." || var ==
"..." ...), don't you think so? ;)
If compiler would support specia
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 should measure compilation speed,
> for instance, but "language
Well, DMD accepts this kind of syntax already:
if (value == val1, val2, val3) { }
I think this turns the expression value==val1 into a bool, and then
turns val2 and val3 into bools and compares against each of them. Or
something like that. It's odd and I've never seen it used anywhere.
Maybe we
On Thu, 28 Apr 2011 11:57:00 -0400, Alexander wrote:
On 28.04.2011 17:32, Steven Schveighoffer wrote:
This is not how it's implemented. The metadata is kept in a separate
page from the memory itself.
Huh? Could you please elaborate, what do you mean by "metadata" and
why it has to be
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
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
> Well, DMD accepts this kind of syntax already:
>
> if (value == val1, val2, val3) { }
>
> I think this turns the expression value==val1 into a bool, and then
> turns val2 and val3 into bools and compares against each of them. Or
> something like that. It's odd and I've never seen it used anywhe
I know it's not doing that, it was a hypothetical. What I'm saying is
I've never seen the comma used this way in code.
> I know it's not doing that, it was a hypothetical. What I'm saying is
> I've never seen the comma used this way in code.
Well, it would almost certainly be bad practice to do so. The comma operator
can be very useful in some cases (such as for loops) but should generally be
avoided. Here, it's
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/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
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/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
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
Steven Schveighoffer wrote:
> Yes, the allocation and free performance could be improved, but it doesn't
> change the fact that delete manually is not a huge performance gain, if at
> all.
My benchmark shows that in the current implementation manual deletion of GC
memory
is at least 15 times fast
On 4/28/11 2:27 PM, Timon Gehr wrote:
Steven Schveighoffer wrote:
Yes, the allocation and free performance could be improved, but it doesn't
change the fact that delete manually is not a huge performance gain, if at
all.
My benchmark shows that in the current implementation manual deletion of
On Thu, 28 Apr 2011 15:27:16 -0400, Timon Gehr wrote:
Steven Schveighoffer wrote:
Yes, the allocation and free performance could be improved, but it
doesn't
change the fact that delete manually is not a huge performance gain, if
at
all.
My benchmark shows that in the current implementati
Andrei Alexandrescu wrote:
> On 4/28/11 11:00 AM, Alexander wrote:
>> On 28.04.2011 17:46, Andrej Mitrovic wrote:
>>
>>> It works, but it makes the if statement ugly again. :)
>>
>>Well, just a bit - still much better than (var == "..." || var = "..." >||
var == "..." ...), don't you think so?
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. And the matmul
Steven Schveighoffer wrote:
> I would need to see what your benchmark is before I'd say it was
> conclusive.
Ok. Version with delete is GC_hints (delete does not give many semantic
guarantees, ergo it is a hint), version without delete is GC. It is also
attached
for convenience.
This benchmark t
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.
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
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
Peter Alexander wrote:
On 26/04/11 9:01 AM, Don wrote:
Sean Cavanaugh wrote:
In many ways the biggest thing I use regularly in game development
that I would lose by moving to D would be good built-in SIMD support.
Yes. It is for primarily for this reason that we made static arrays
return-by-
> 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
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?
> >
> >
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
Hi,
checking whether a floating point exception occurred is good coding
practice for me.
I discovered a strange behavior using dmd.
divByZero.d:
import std.math;
unittest {
auto a = 1.0L;
assert(!ieeeFlags.divByZero);
a /= 0.0L;
assert(ieeeFlags.divByZero);
}
$ rdmd --main -unitt
Here's a little 100-line thingy that generates a wavetable of some
shape (sine, saw, square - although only sine is implemented at the
moment), of any length, and of either float or double element type. It
stores this inside a struct which can also keep a number of different
phases, which do bounds
Oh that last snippet is wrong, it should be:
sample = audioTable.table[audioTable.phase[0] += leftPhase];
sample = audioTable.table[audioTable.phase[1] += rightPhase];
:)
> "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
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.
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
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 28.04.2011 18:17, Steven Schveighoffer wrote:
> It would seem making the metadata be a constant offset from the data page
> would be better, but of course, it cannot be that way for multi-page blocks.
Why it cannot?
> If you have ideas on how to improve the performance, I encourage you to
On 28.04.2011 21:46, Timon Gehr wrote:
> Why is 'in' not currently defined on arrays? To me it seems like a left-out
> that
> should be fixed, because it has quite obvious and useful semantics.
+1. It would be very useful and convenient this way, especially if search
will be optimized to seri
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
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
2011/4/29 Alexander :
> On 28.04.2011 21:46, Timon Gehr wrote:
>
>> Why is 'in' not currently defined on arrays? To me it seems like a left-out
>> that
>> should be fixed, because it has quite obvious and useful semantics.
>
> +1. It would be very useful and convenient this way, especially if sea
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
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/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.
== 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 3:02 PM, Jens Mueller wrote:
Hi,
checking whether a floating point exception occurred is good coding
practice for me.
I discovered a strange behavior using dmd.
divByZero.d:
import std.math;
unittest {
auto a = 1.0L;
assert(!ieeeFlags.divByZero);
a /= 0.0L;
asse
On Apr 29, 11 14:27, Walter Bright wrote:
That's because the a/=1.0L; is a dead assignment and is removed by the
optimizer.
I'd say it's a wrong-code bug.
-
import std.math, std.stdio;
void main() {
auto a = 1.0, b = 0.0;
writeln(a);
writeln(i
78 matches
Mail list logo
