On Friday, 15 February 2013 at 20:58:30 UTC, Jonathan M Davis
wrote:
I should probably add that bringing up discussions on how to
solve problems in
the language can be of benefit, because they often result in
good discussions
that help lead toward a solution, and that can lead towards
that
I am starting to understand the difficulty with ref being too
restrictive. Some kind of const ref in the language would
have helped indeed. But it would probably cause some
allocation difficulties for actual constants... or worse?
Search for 'auto ref' or right after 'rvalue references' and
On Thursday, 14 February 2013 at 20:33:21 UTC, Ivan Kazmenko
wrote:
Rob T wrote:
When I look at the std.container source code, it seems that
the payload element is passed by value multiple times
unnecessarily, so to minimize copy construction you'll have to
implement element as a class and
On Fri, 15 Feb 2013 12:11:55 -0500, monarch_dodra monarchdo...@gmail.com
wrote:
Also keep in mind that a b is implemented as two calls to
a.opCmp(b), and a.opCmp(b) is itself usually implemented as two
calls to something something else (!)
Huh?
a b is implemented as a.opCmp(b) 0,
On Friday, 15 February 2013 at 17:42:30 UTC, Steven Schveighoffer
wrote:
On Fri, 15 Feb 2013 12:11:55 -0500, monarch_dodra
monarchdo...@gmail.com wrote:
Also keep in mind that a b is implemented as two calls to
a.opCmp(b), and a.opCmp(b) is itself usually implemented
as two calls to
On Friday, 15 February 2013 at 17:42:30 UTC, Steven Schveighoffer
wrote:
On Fri, 15 Feb 2013 12:11:55 -0500, monarch_dodra
monarchdo...@gmail.com wrote:
Also keep in mind that a b is implemented as two calls to
a.opCmp(b), and a.opCmp(b) is itself usually implemented
as two calls to
On Thursday, 14 February 2013 at 20:53:26 UTC, Jonathan M Davis
wrote:
And Walter and Andrei both seem to think that having expensive
postlbits is a
design mistake. The range stuff sort of tries to support it
with the move*
primitives, but Andrei's been wanting to argue for just
assuming
When you say things like Andrei was considering phasing out
postblits... I get nervous. Can we please have some comments
from Andrei/Walter about what the plans are? I'm not asking for
the ultimate solution - just to know the general direction and
where this issue stands at present. Is there
On Thursday, 14 February 2013 at 19:31:36 UTC, Steven
Schveighoffer wrote:
If it was pass by ref, then rbt.insert(5) would not work. And
in fact, I wouldn't want things passed by ref if the element is
int.
What is the reason for the second objection - is just performance?
Is performance
On Friday, February 15, 2013 20:12:08 Dan wrote:
Granted the no rvalue passing is a pain - but is it a big deal in
library/generic code?
Yes, it's a big deal. Any place that it's part of an API, it's a big deal. It
forces you to create what are essentially useless variables all over the place
They're not going to do that until they've decided, and AFAIK,
they haven't.
Attempting to essentially confront them and get them to say
what they plan to
do generally doesn't get you anywhere - especially since
they're unlikely to
say much until they actually are planning to do it, and it's
On Friday, February 15, 2013 21:16:51 Namespace wrote:
They're not going to do that until they've decided, and AFAIK,
they haven't.
Attempting to essentially confront them and get them to say
what they plan to
do generally doesn't get you anywhere - especially since
they're unlikely to
On Friday, February 15, 2013 21:37:46 Jonathan M Davis wrote:
On Friday, February 15, 2013 21:16:51 Namespace wrote:
They're not going to do that until they've decided, and AFAIK,
they haven't.
Attempting to essentially confront them and get them to say
what they plan to
do
Again: My intention was not const.
And you're right, but there was so many discussions about const
(since dmd 2.057; also in the last few days) and as every
discussion here: after page 2 is the topic changed.
I'm also very sure that neither Walter nor Andrei see a
(important) reason for
On Fri, 15 Feb 2013 13:14:21 -0500, Dan dbdavid...@yahoo.com wrote:
When you say things like Andrei was considering phasing out
postblits... I get nervous. Can we please have some comments from
Andrei/Walter about what the plans are? I'm not asking for the ultimate
solution - just to know
On Friday, February 15, 2013 22:41:24 Namespace wrote:
Again: My intention was not const.
I know. What I'm saying applies in general.
And you're right, but there was so many discussions about const
(since dmd 2.057; also in the last few days) and as every
discussion here: after page 2 is the
On Friday, February 15, 2013 16:53:36 Steven Schveighoffer wrote:
On Fri, 15 Feb 2013 13:14:21 -0500, Dan dbdavid...@yahoo.com wrote:
When you say things like Andrei was considering phasing out
postblits... I get nervous. Can we please have some comments from
Andrei/Walter about what the
They definitely agree that it's a problem. They just don't see
it as having as
high a priority as you do.
For me it is not a priority (anymore). I use C++ again.
It's just a question of how and when.
- Jonathan M Davis
Yes as I said: I count the versions. :)
On Fri, 15 Feb 2013 13:02:39 -0500, Dan dbdavid...@yahoo.com wrote:
On Friday, 15 February 2013 at 17:42:30 UTC, Steven Schveighoffer wrote:
On Fri, 15 Feb 2013 12:11:55 -0500, monarch_dodra
monarchdo...@gmail.com wrote:
Also keep in mind that a b is implemented as two calls to
On Friday, 15 February 2013 at 22:06:55 UTC, Steven Schveighoffer
wrote:
With opcmp:
int opCmp(int a, int b)
{
return a - b;
}
Genius!
Now I feel bad for every time I've done integral opCmp with
double ternary operators :(
On Fri, Feb 15, 2013 at 11:49:53PM +0100, monarch_dodra wrote:
On Friday, 15 February 2013 at 22:06:55 UTC, Steven Schveighoffer
wrote:
With opcmp:
int opCmp(int a, int b)
{
return a - b;
}
Genius!
Now I feel bad for every time I've done integral opCmp with double
ternary
On Friday, February 15, 2013 23:49:53 monarch_dodra wrote:
On Friday, 15 February 2013 at 22:06:55 UTC, Steven Schveighoffer
wrote:
With opcmp:
int opCmp(int a, int b)
{
return a - b;
}
Genius!
Now I feel bad for every time I've done integral opCmp with
double ternary
On Fri, 15 Feb 2013 17:49:53 -0500, monarch_dodra monarchdo...@gmail.com
wrote:
On Friday, 15 February 2013 at 22:06:55 UTC, Steven Schveighoffer wrote:
With opcmp:
int opCmp(int a, int b)
{
return a - b;
}
Genius!
Now I feel bad for every time I've done integral opCmp with double
On Fri, 15 Feb 2013 18:41:51 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
There needs to be some extra checking, possibly with the carry flag.
And further to that point, my generated assembly for a b also is
similarly flawed, so it still may be better to do opCmp.
-Steve
Steven Schveighoffer:
Actually, I'm not as smart as you think ;)
There needs to be some extra checking, possibly with the carry
flag.
For example:
0x7000 - (-0x7000)
would be less than zero as a resulting integer.
But it would work with shorts or bytes!
I remember a page about
On Friday, 15 February 2013 at 23:41:50 UTC, Steven Schveighoffer
wrote:
In any case, the example was bad, the point that which is
better depends on the situation is still correct.
The compiler has to do something with ab. I would hope for a
fundamental type it can avoid the lowering and just
On Thursday, 14 February 2013 at 10:23:18 UTC, Namespace wrote:
I agree. There are cases where structs make a lot of sense,
usually when they are very simple simple and contain no
pointers or references, otherwise structs should be avoided in
favor of classes to avoid doing copy/move
Another good balance are stack based struct pointer wrappers to
implementation : You can pass them by value, but they carry a
complex payload.
I'm not sure what that is.
Can you give a small example?
On Thursday, 14 February 2013 at 10:44:22 UTC, Namespace wrote:
Another good balance are stack based struct pointer wrappers
to implementation : You can pass them by value, but they carry
a complex payload.
I'm not sure what that is.
Can you give a small example?
struct S
{
static
struct S
{
static struct Payload
{
//Tons of data here
}
Payload* _p;
//fonctions
}
Ref counted is implemented that way. most of the containers are
also implemented that way. associative arrays are also
implemented that way under the hood.
But you have to
First, thank you all for the replies!
Jonathan M Davis wrote:
Also, it could make a big difference if you use gdc or ldc
rather than dmd.
Thank you for the suggestion, I'll check that. However, I don't
expect the GCC optimizer to reduce the number of calls in this
specific test, since it
On Thursday, 14 February 2013 at 10:58:19 UTC, Namespace wrote:
struct S
{
static struct Payload
{
//Tons of data here
}
Payload* _p;
//fonctions
}
Ref counted is implemented that way. most of the containers
are also implemented that way. associative arrays are also
14-Feb-2013 03:22, Ivan Kazmenko пишет:
Hi!
I'm learning to use D collections properly, and I'm looking for a sorted
data structure with logarithmic access time (i.e., a binary search tree
will do, but a hash table would not help). As far as I can see,
std.container.RedBlackTree is exactly what
If I use (as you do)
this(ref this) {
I get 0 as output. (dmd 2.062 beta1)
If I remove the 'ref' I get 11389556.
On Thu, 14 Feb 2013 09:47:31 -0500, Namespace rswhi...@googlemail.com
wrote:
If I use (as you do)
this(ref this) {
I get 0 as output. (dmd 2.062 beta1)
If I remove the 'ref' I get 11389556.
this(ref this) is not a postblit. That it would even compile is a bug.
-Steve
If I use (as you do)
this(ref this) {
I get 0 as output. (dmd 2.062 beta1)
If I remove the 'ref' I get 11389556.
Ouch, sorry! That's a copy paste bug I introduced when posting
here.
Actually, I use this (this) of course. I tried this (ref this)
at some point, it does indeed
On Thursday, February 14, 2013 13:27:30 monarch_dodra wrote:
Actually, (and IMO, this is a very big problem), these structures
are *always* null by default. There is no easy way to default
initialize structs in D :(
You mean there's no way to default-construct them. They're always default-
Dmitry Olshansky wrote:
D2 (DMD 2.059, -O): 11,389,556
I'd add :
-release -inline
or it may not inline away temporary copies.
Thank you for the suggestion. However, the result after -O
-release -inline is still 11,389,556.
When I look at the std.container source code, it seems that the
payload element is passed by value multiple times unnecessarily,
so to minimize copy construction you'll have to implement element
as a class and implement a dup function for it.
I expect performance will increase substantially
On Thu, 14 Feb 2013 13:45:30 -0500, Rob T al...@ucora.com wrote:
When I look at the std.container source code, it seems that the payload
element is passed by value multiple times unnecessarily, so to minimize
copy construction you'll have to implement element as a class and
implement a dup
On Thursday, 14 February 2013 at 19:31:36 UTC, Steven
Schveighoffer wrote:
On Thu, 14 Feb 2013 13:45:30 -0500, Rob T al...@ucora.com
wrote:
When I look at the std.container source code, it seems that
the payload element is passed by value multiple times
unnecessarily, so to minimize copy
On Thursday, 14 February 2013 at 19:56:33 UTC, Namespace wrote:
There are discussions for such thing for almost a year - but
nothing has changed so far.
I think its finally on the priority radar, but there's still
other things in more dire need to be resolved first, like
@property and lack
Rob T wrote:
When I look at the std.container source code, it seems that the
payload element is passed by value multiple times
unnecessarily, so to minimize copy construction you'll have to
implement element as a class and implement a dup function for
it.
Thank you all for assistance, I've
Ivan Kazmenko:
Thank you all for assistance, I've finally pinned it down!
This is great. The first step to solve a problem is to find it.
The second step is to formalize it. So I suggest you to create a
small benchmark that shows what you mean (it should not include
RedBlackTree) and put
On Thursday, 14 February 2013 at 20:20:59 UTC, Rob T wrote:
On Thursday, 14 February 2013 at 19:56:33 UTC, Namespace wrote:
There are discussions for such thing for almost a year - but
nothing has changed so far.
I think its finally on the priority radar, but there's still
other things in
On Thursday, February 14, 2013 14:31:36 Steven Schveighoffer wrote:
On Thu, 14 Feb 2013 13:45:30 -0500, Rob T al...@ucora.com wrote:
When I look at the std.container source code, it seems that the payload
element is passed by value multiple times unnecessarily, so to minimize
copy
On Thursday, 14 February 2013 at 20:44:13 UTC, bearophile wrote:
Ivan Kazmenko:
Thank you all for assistance, I've finally pinned it down!
This is great. The first step to solve a problem is to find it.
The second step is to formalize it. So I suggest you to create
a small benchmark that
On Thu, 14 Feb 2013 15:33:19 -0500, Ivan Kazmenko ga...@mail.ru wrote:
Rob T wrote:
When I look at the std.container source code, it seems that the payload
element is passed by value multiple times unnecessarily, so to minimize
copy construction you'll have to implement element as a class
On Thu, 14 Feb 2013 15:33:19 -0500, Ivan Kazmenko ga...@mail.ru wrote:
... I get only exactly 3 * LIMIT postblit constructor calls, which is
300,000 instead of 11,389,556. While I still want to find where the
excess 200,000 calls originate from, this is definitely asymptotically
better
As I said elsewhere, the issue is D not having a good solution
for accepting both rvalues and lvalues by ref. Jonathan
mentioned auto ref, but it's not exactly implemented correctly.
In C++, it just takes all parameters as const T, and that
works for both lvalues and rvalues.
The extra
Steven Schveighoffer wrote:
Again, the issue here is D has restrictions on ref parameters.
There are no such restrictions on pass-by-value parameters. So
by default, the predicate tries by-value.
I am starting to understand the difficulty with ref being too
restrictive. Some kind of
P.S. More on C++ version:
Personally, I don't see why at all we should call the copy
constructor more than once per element. I mean, if we intend to
build a generic data structure, we sure need an internal node
object with some extra bytes (internal references and counters)
per each element,
On Thursday, February 14, 2013 00:33:26 Ivan Kazmenko wrote:
P.S. More on C++ version:
Personally, I don't see why at all we should call the copy
constructor more than once per element. I mean, if we intend to
build a generic data structure, we sure need an internal node
object with some
You can check if disabling the GC just before the insert process
improves the performance. You may see 3x performance improvement.
Disabling is safe provided you re-enable, this can be done
reliably with scope(exit) or something similar.
import core.memory;
// ...
void main ()
{
On 2013-02-14 01:09, Rob T wrote:
You can check if disabling the GC just before the insert process improves the
performance. You may see 3x performance improvement. Disabling is safe provided
you re-enable, this can be done reliably with scope(exit) or something similar.
How did you know? It
On Wed, 13 Feb 2013 18:22:02 -0500, Ivan Kazmenko ga...@mail.ru wrote:
Hi!
I'm learning to use D collections properly, and I'm looking for a sorted
data structure with logarithmic access time (i.e., a binary search tree
will do, but a hash table would not help). As far as I can see,
On Wednesday, 13 February 2013 at 23:22:03 UTC, Ivan Kazmenko
wrote:
Hi!
-
Ivan Kazmenko.
Keep in mind that C++ and D have very different philosophies
regarding copy construction.
C++ has strong ownership, so for example, whenever you copy a
string/vector, or pass it by value, the
On Thursday, 14 February 2013 at 00:25:15 UTC, FG wrote:
On 2013-02-14 01:09, Rob T wrote:
You can check if disabling the GC just before the insert
process improves the
performance. You may see 3x performance improvement. Disabling
is safe provided
you re-enable, this can be done reliably with
58 matches
Mail list logo
