On 03/05/2011 22:41, Jérôme M. Berger wrote:
Bruno Medeiros wrote:
On 29/04/2011 17:30, Andrei Alexandrescu wrote:
On 4/29/11 10:40 AM, Bruno Medeiros wrote:
On 23/04/2011 15:45, Andrei Alexandrescu wrote:
On 4/23/11 8:57 AM, dsimcha wrote:
BTW, since when does the ternary operator work
Jérôme M. Berger wrote:
Bruno Medeiros wrote:
On 29/04/2011 17:30, Andrei Alexandrescu wrote:
On 4/29/11 10:40 AM, Bruno Medeiros wrote:
On 23/04/2011 15:45, Andrei Alexandrescu wrote:
On 4/23/11 8:57 AM, dsimcha wrote:
BTW, since when does the ternary operator work with functions, as
On 5/4/2011 7:38 PM, Don wrote:
Jérôme M. Berger wrote:
Bruno Medeiros wrote:
On 29/04/2011 17:30, Andrei Alexandrescu wrote:
On 4/29/11 10:40 AM, Bruno Medeiros wrote:
On 23/04/2011 15:45, Andrei Alexandrescu wrote:
On 4/23/11 8:57 AM, dsimcha wrote:
BTW, since when does the ternary
On 29/04/2011 17:30, Andrei Alexandrescu wrote:
On 4/29/11 10:40 AM, Bruno Medeiros wrote:
On 23/04/2011 15:45, Andrei Alexandrescu wrote:
On 4/23/11 8:57 AM, dsimcha wrote:
BTW, since when does the ternary operator work with functions, as
opposed to variables?
And that's since the C days
Bruno Medeiros wrote:
On 29/04/2011 17:30, Andrei Alexandrescu wrote:
On 4/29/11 10:40 AM, Bruno Medeiros wrote:
On 23/04/2011 15:45, Andrei Alexandrescu wrote:
On 4/23/11 8:57 AM, dsimcha wrote:
BTW, since when does the ternary operator work with functions, as
opposed to variables?
And
On 23/04/2011 15:45, Andrei Alexandrescu wrote:
On 4/23/11 8:57 AM, dsimcha wrote:
BTW, since when does the ternary operator work with functions, as
opposed to variables?
And that's since the C days btw. The function call is just an operation,
the callee an operand, so any expression can
On 4/29/11 10:40 AM, Bruno Medeiros wrote:
On 23/04/2011 15:45, Andrei Alexandrescu wrote:
On 4/23/11 8:57 AM, dsimcha wrote:
BTW, since when does the ternary operator work with functions, as
opposed to variables?
And that's since the C days btw. The function call is just an operation,
the
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
On 04/24/2011 08:08 PM, Iain Buclaw wrote:
== Quote from Timon Gehr (timon.g...@gmx.ch)'s article
Andrei Alexandrescu wrote:
I am sorry, you simply have no case - each and every argument you put
forth has no
On 04/25/2011 10:06 AM, Iain Buclaw wrote:
I was thinking of where one implements an alternative runtime that may not
necessarily interface with a GC, or has different semantics on the use of the
keyword (the compiler, after all, doesn't know/care what exactly 'delete' does,
it
just does it's
On Apr 24, 2011, at 7:25 PM, Robert Jacques wrote:
To the best of my knowledge, for 'small' allocations, the current GC uses
free-lists of power-of-2 sized blocks. (I think small is defined as anything
under 4k)
That's correct.
On Apr 24, 2011, at 1:17 PM, Andrei Alexandrescu wrote:
It is much better in very many ways, in particular in D. For one simple
argument, consider:
auto obj = new Widget;
Simple modularity considerations would require this operator to have
semantics independent of Widget, such that
On 04/25/2011 10:06 AM, Iain Buclaw wrote:
I was thinking of where one implements an alternative runtime that may
not
necessarily interface with a GC, or has different semantics on the use of
the
keyword (the compiler, after all, doesn't know/care what exactly 'delete'
does, it
just
On 4/25/11 4:20 PM, Kim D wrote:
On 04/25/2011 10:06 AM, Iain Buclaw wrote:
I was thinking of where one implements an alternative runtime that may
not
necessarily interface with a GC, or has different semantics on the use of
the
keyword (the compiler, after all, doesn't know/care what exactly
Andrei Alexandrescu wrote:
The point is that some naively believe new and delete are some
simple do and undo actions and as such they somehow deserve the same
level of support. In reality they have dramatically different issues and
are profoundly asymmetric.
The class-specific allocators
On 04/24/2011 01:21 PM, Timon Gehr wrote:
Andrei Alexandrescu wrote:
The point is that some naively believe new and delete are some
simple do and undo actions and as such they somehow deserve the same
level of support. In reality they have dramatically different issues and
are profoundly
Since this is definite we should remove them from the docs as well.
Want me to file it to bugzilla?
Andrei:
It might not a good use of our time to further engage in a diatribe on this.
Just a note: you have not wasted your time discussing this, because I am not
expert on such matters, so I learn something from informed discussions :-)
If a book that explains C language is just 200 pages
== Quote from bearophile (bearophileh...@lycos.com)'s article
Andrei:
It might not a good use of our time to further engage in a diatribe on this.
Just a note: you have not wasted your time discussing this, because I am not
expert on such matters, so I learn something from informed discussions
On 04/24/2011 03:35 PM, Andrej Mitrovic wrote:
Since this is definite we should remove them from the docs as well.
Want me to file it to bugzilla?
Please do. BTW I just fixed the core-related documentation bug on
d-programming-language.org.
Andrei
On 4/24/11, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote:
On 04/24/2011 03:35 PM, Andrej Mitrovic wrote:
Since this is definite we should remove them from the docs as well.
Want me to file it to bugzilla?
Please do. BTW I just fixed the core-related documentation bug on
Piotr Szturmaj wrote:
Why not allow delete only in classes with custom allocators? AFAIK
they could be determined at compile time. Please let me know if I'm wrong.
Nevermind. Andrei informed that class allocators are being deprecated,
so my question is no longer relevant.
Andrei Alexandrescu wrote:
I am sorry, you simply have no case - each and every argument you put
forth has no strength or is just wrong. We could spend time on debating
each, but I suspect that would do little toward convincing you of what
is after all a simple fact, but one with many subtle
== Quote from Timon Gehr (timon.g...@gmx.ch)'s article
Andrei Alexandrescu wrote:
I am sorry, you simply have no case - each and every argument you put
forth has no strength or is just wrong. We could spend time on debating
each, but I suspect that would do little toward convincing you of
On 04/24/2011 08:08 PM, Iain Buclaw wrote:
== Quote from Timon Gehr (timon.g...@gmx.ch)'s article
Andrei Alexandrescu wrote:
I am sorry, you simply have no case - each and every argument you put
forth has no strength or is just wrong. We could spend time on debating
each, but I suspect that
On Sun, 24 Apr 2011 21:13:43 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 04/24/2011 08:08 PM, Iain Buclaw wrote:
== Quote from Timon Gehr (timon.g...@gmx.ch)'s article
Andrei Alexandrescu wrote:
I am sorry, you simply have no case - each and every argument you put
On 04/24/2011 07:10 PM, Timon Gehr wrote:
Andrei Alexandrescu wrote:
I am sorry, you simply have no case - each and every argument you put
forth has no strength or is just wrong. We could spend time on debating
each, but I suspect that would do little toward convincing you of what
is after all
Michael Stover wrote:
This sort of reference count with cyclic dependency detector is how a
lot of scripting languages do it, or did it in the past. The problem
was that lazy generational GCs are believed to have better throughput in
general.
I'd like to say were proved rather than are
== Quote from bearophile (bearophileh...@lycos.com)'s article
Iain Buclaw:
Variable length arrays are just sugary syntax for a call to alloca.
I have an enhancement request in Bugzilla on VLA, with longer discussions.
Just
two comments:
- It seems alloca() can be implemented with two
On 4/22/11 4:04 PM, Timon Gehr wrote:
[snip]
This is also the reason I think it is a bad idea to deprecate D's
'delete'.
The functionality is not going away.
Andrei
On 4/22/11 5:21 PM, Iain Buclaw wrote:
== Quote from bearophile (bearophileh...@lycos.com)'s article
Timon Gehr:
But, as pointed out by Linus, the prime performance problem is _not_ the GC, but
the mindset that comes with it. Most programmers that grew up in a managed
environment tend to use
On 4/23/2011 9:48 AM, Andrei Alexandrescu wrote:
On 4/22/11 5:21 PM, Iain Buclaw wrote:
== Quote from bearophile (bearophileh...@lycos.com)'s article
Timon Gehr:
But, as pointed out by Linus, the prime performance problem is _not_
the GC, but
the mindset that comes with it. Most programmers
Andrei:
Well in fairness they can be a fair amount more elaborate. The trouble
with alloca is that it's impossible to compose with. So in general you
need to write something like:
bool onStack = smallEnough(length * sizeof(T));
auto a = (cast(T*) (onStack ? alloca : malloc)(length *
dsimcha:
Right. This is exactly the kind of thing TempAlloc was meant to solve.
I think TempAlloc is meant for larger allocations. D-VLAs are meant to allocate
little arrays (like 1 KB or less) on the normal stack very quickly.
Bye,
bearophile
Andrei:
bool onStack = smallEnough(length * sizeof(T));
auto a = (cast(T*) (onStack ? alloca : malloc)(length * sizeof(T)));
scope(exit) if (!onStack) free(a.ptr);
initialize(enforce(a));
scope(exit) clear(a);
This block is difficult to factor out because of alloca.
As I have explained
On 4/23/2011 10:24 AM, bearophile wrote:
dsimcha:
Right. This is exactly the kind of thing TempAlloc was meant to solve.
I think TempAlloc is meant for larger allocations. D-VLAs are meant to allocate
little arrays (like 1 KB or less) on the normal stack very quickly.
Bye,
bearophile
On 4/23/11 8:57 AM, dsimcha wrote:
BTW, since when does the ternary operator work with functions, as
opposed to variables?
They are converted to pointers to functions. Not something I'd recommend
because it makes the call slower.
Andrei
On 4/22/11 4:04 PM, Timon Gehr wrote:
[snip]
This is also the reason I think it is a bad idea to deprecate D's
'delete'.
The functionality is not going away.
Andrei
Yes I realize that. It is a matter of syntax and aesthetics. Handling allocation
and deallocation non-uniformly renders the
On 4/23/11 11:33 AM, Timon Gehr wrote:
On 4/22/11 4:04 PM, Timon Gehr wrote:
[snip]
This is also the reason I think it is a bad idea to deprecate D's
'delete'.
The functionality is not going away.
Andrei
Yes I realize that. It is a matter of syntax and aesthetics. Handling allocation
and
dsimcha:
It's slightly slower than VLAs,
but the difference is negligible since it's still almost never a
threading bottleneck and you still have to do something with the array
you allocated.
I have to compare the performance of both for my use cases (fast allocations of
very small
Andrei Alexandrescu wrote:
Allocation and deallocation are not symmetric and as such handling them
in a uniform way would be a mistake that perpetuates a poor
understanding of the underlying realities of memory allocation and
object creation. I suggest you reconsider.
'char' is completely
On 4/22/2011 2:04 PM, Timon Gehr wrote:
The reason Java is garbage collected is _not_ performance, but primarily
reliability.
I believe a GC is required if one wishes to prove memory safety, which is
definitely a design goal of Java.
Timon Gehr wrote:
Andrei Alexandrescu wrote:
Allocation and deallocation are not symmetric and as such handling them
in a uniform way would be a mistake that perpetuates a poor
understanding of the underlying realities of memory allocation and
object creation. I suggest you reconsider.
'char'
On 4/23/11 1:05 PM, Timon Gehr wrote:
Andrei Alexandrescu wrote:
Allocation and deallocation are not symmetric and as such handling them
in a uniform way would be a mistake that perpetuates a poor
understanding of the underlying realities of memory allocation and
object creation. I suggest you
http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
Just a reminder: that post is 9 years old.
El 22/04/2011 19:36, Walter Bright escribió:
http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
I've always been surprised when discussions usually just bring garbage
collection as the only alternative to explicit manual memory management.
I imagined it as a garbage truck that has its own
This sort of reference count with cyclic dependency detector is how a lot of
scripting languages do it, or did it in the past. The problem was that lazy
generational GCs are believed to have better throughput in general.
I'd like to say were proved rather than are believed, but I don't
actually
On Fri, 22 Apr 2011 14:32:06 -0400, Alvaro alvaro.seg...@gmail.com wrote:
El 22/04/2011 19:36, Walter Bright escribió:
http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
I've always been surprised when discussions usually just bring garbage
collection as the only alternative to explicit
Also add to it that in many cases you're dealing with a threaded environment,
so those refcounts have to be locked
(either via mutexes, or more commonly just atomic) operations which are far
more expensive than non-atomic. More so
when there's actual contention for the refcounted resource.
On
Brad Roberts wrote:
Also add to it that in many cases you're dealing with a threaded environment,
so those refcounts have to be locked
(either via mutexes, or more commonly just atomic) operations which are far
more
expensive than non-atomic. More so
when there's actual contention for the
Timon Gehr:
But, as pointed out by Linus, the prime performance problem is _not_ the GC,
but
the mindset that comes with it. Most programmers that grew up in a managed
environment tend to use very many new keywords all over their code, instead
of
allocating large chunks of memory at once.
== Quote from bearophile (bearophileh...@lycos.com)'s article
Timon Gehr:
But, as pointed out by Linus, the prime performance problem is _not_ the
GC, but
the mindset that comes with it. Most programmers that grew up in a managed
environment tend to use very many new keywords all over
Iain Buclaw:
Variable length arrays are just sugary syntax for a call to alloca.
I have an enhancement request in Bugzilla on VLA, with longer discussions. Just
two comments:
- It seems alloca() can be implemented with two different semantics: to
deallocate at the end of the function or to
Now D I prefer something better than C99 VLAs. I'd like D-VLAs with the same
syntax as C99 VLAs but with a safer semantics,
Never mind, that semantics can't use that syntax, otherwise you have hidden
heap allocations... The syntax has to change (because the D-VLA semantics seems
OK to me).
2011/4/22 Timon Gehr timon.g...@gmx.ch:
That is only a problem if the reference count of that resource changes at a
very
high frequency. The described problem also implies that the threads would not
need
any form of synchronization for the data (otherwise the reference count
certainly
Ulrik Mikaelsson wrote:
All in all, I think the best approach is a pragmatic one, where
different types of resources can be handled according to different
schemes.
I.E. default to GC-manage everything. After profiling, determining
what resources are mostly used, and where, optimize
56 matches
Mail list logo
