One subject that frequented the talks at dconf was the poor performance of
CTFE and mixins.
The major issue as I understand it (maybe I'm wrong) is the vast amounts
of memory the compiler consumes while building mixin strings. In fact, one
of the talks (can't remember which one) mentioned t
If would be nice if Don could elaborate on his comment in bug
#6498 (https://issues.dlang.org/show_bug.cgi?id=6498#c1)
I.e. What has been done, what needs to be done, what is a "proper
fix".
I think it was stated somewhere that the goal was to implement
reference counting.
This would help pe
On 5/29/14, 12:22 PM, Steven Schveighoffer wrote:
One subject that frequented the talks at dconf was the poor performance
of CTFE and mixins.
The major issue as I understand it (maybe I'm wrong) is the vast amounts
of memory the compiler consumes while building mixin strings. In fact,
one of the
On Thu, May 29, 2014 at 01:13:39PM -0300, Ary Borenszweig via Digitalmars-d
wrote:
> On 5/29/14, 12:22 PM, Steven Schveighoffer wrote:
> >One subject that frequented the talks at dconf was the poor
> >performance of CTFE and mixins.
> >
> >The major issue as I understand it (maybe I'm wrong) is th
I'm not well acquainted with how the compiler works internally,
or how CTFE is implemented. But it seems like a full-blown D
interpreter with eval functionality is needed. Lots of scripting
language interpreters exist out there, and they all get
relatively decent performance and memory footprin
On Thursday, 29 May 2014 at 16:13:40 UTC, Ary Borenszweig wrote:
If you add reference counting or a GC to the compiler, it will
make those large projects compile, but it will inevitably be
slower than now. That's why Walter disabled GC completely in
the compiler (turning it on made the compil
On Thu, 29 May 2014 13:07:17 -0400, safety0ff
wrote:
On Thursday, 29 May 2014 at 16:13:40 UTC, Ary Borenszweig wrote:
If you add reference counting or a GC to the compiler, it will make
those large projects compile, but it will inevitably be slower than
now. That's why Walter disabled G
On Thursday, 29 May 2014 at 17:33:15 UTC, Steven Schveighoffer
wrote:
On Thu, 29 May 2014 13:07:17 -0400, safety0ff
wrote:
On Thursday, 29 May 2014 at 16:13:40 UTC, Ary Borenszweig
wrote:
If you add reference counting or a GC to the compiler, it
will make those large projects compile, but
On Thu, 29 May 2014 12:53:54 -0400, Dylan Knutson
wrote:
I'm not well acquainted with how the compiler works internally, or how
CTFE is implemented. But it seems like a full-blown D interpreter with
eval functionality is needed. Lots of scripting language interpreters
exist out there, an
On 05/29/2014 07:33 PM, Steven Schveighoffer wrote:
But CTFE is full of code that expects to have a GC running, e.g. string
concatenation for mixins, etc.
Even the following code runs out of memory on my machine:
int foo(){
foreach(i;0..1){}
return 2;
}
pragma(msg, foo());
I.
On Thu, 29 May 2014 13:54:07 -0400, Timon Gehr wrote:
On 05/29/2014 07:33 PM, Steven Schveighoffer wrote:
But CTFE is full of code that expects to have a GC running, e.g. string
concatenation for mixins, etc.
Even the following code runs out of memory on my machine:
int foo(){
foreach
On 05/29/2014 06:53 PM, Dylan Knutson wrote:
...
Is there anything so radically different in D than these other
languages, that prevents the implementation of a run-of-the-mill VM to
eval D code?
No. (In fact, I've written a naive but mostly complete byte code
interpreter in half a week or so
On Thursday, 29 May 2014 at 15:22:54 UTC, Steven Schveighoffer
wrote:
One subject that frequented the talks at dconf was the poor
performance of CTFE and mixins.
The major issue as I understand it (maybe I'm wrong) is the
vast amounts of memory the compiler consumes while building
mixin strin
On Thursday, 29 May 2014 at 17:54:08 UTC, Timon Gehr wrote:
On 05/29/2014 07:33 PM, Steven Schveighoffer wrote:
But CTFE is full of code that expects to have a GC running,
e.g. string
concatenation for mixins, etc.
Even the following code runs out of memory on my machine:
int foo(){
fo
On Thu, 29 May 2014 11:22:54 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
> One subject that frequented the talks at dconf was the poor
> performance of CTFE and mixins.
>
> The major issue as I understand it (maybe I'm wrong) is the vast
> amounts of memory the compiler consumes while bui
On Thu, 29 May 2014 09:16:26 -0700
"H. S. Teoh via Digitalmars-d" wrote:
> On Thu, May 29, 2014 at 01:13:39PM -0300, Ary Borenszweig via
> Digitalmars-d wrote:
> > On 5/29/14, 12:22 PM, Steven Schveighoffer wrote:
> > >One subject that frequented the talks at dconf was the poor
> > >performance o
On Thursday, 29 May 2014 at 20:44:43 UTC, Dicebot wrote:
I'd love to see command-line flag that enables garbage
collection in compiler (disabled by default). It does not
matter how fast compiler is if it crashes on big project. And
difference between 10 seconds vs 30 seconds is not as importan
On Thu, 29 May 2014 23:11:25 -0400, Puming wrote:
On Thursday, 29 May 2014 at 20:44:43 UTC, Dicebot wrote:
I'd love to see command-line flag that enables garbage collection in
compiler (disabled by default). It does not matter how fast compiler is
if it crashes on big project. And differen
On Thursday, 29 May 2014 at 15:28:28 UTC, safety0ff wrote:
If would be nice if Don could elaborate on his comment in bug
#6498 (https://issues.dlang.org/show_bug.cgi?id=6498#c1)
What is really needed is the ability to update variables in place.
Currently every mutation allocates a new value.
I
On Saturday, 31 May 2014 at 02:40:29 UTC, Martin Nowak wrote:
On Thursday, 29 May 2014 at 15:28:28 UTC, safety0ff wrote:
If would be nice if Don could elaborate on his comment in bug
#6498 (https://issues.dlang.org/show_bug.cgi?id=6498#c1)
What is really needed is the ability to update variabl
On Sunday, 1 June 2014 at 10:46:52 UTC, Peter Alexander wrote:
On Saturday, 31 May 2014 at 02:40:29 UTC, Martin Nowak wrote:
On Thursday, 29 May 2014 at 15:28:28 UTC, safety0ff wrote:
If would be nice if Don could elaborate on his comment in bug
#6498 (https://issues.dlang.org/show_bug.cgi?id=6
On Friday, 30 May 2014 at 03:11:27 UTC, Puming wrote:
On Thursday, 29 May 2014 at 20:44:43 UTC, Dicebot wrote:
I'd love to see command-line flag that enables garbage
collection in compiler (disabled by default). It does not
matter how fast compiler is if it crashes on big project. And
differe
On Fri, 30 May 2014 22:40:29 -0400, Martin Nowak wrote:
On Thursday, 29 May 2014 at 15:28:28 UTC, safety0ff wrote:
If would be nice if Don could elaborate on his comment in bug #6498
(https://issues.dlang.org/show_bug.cgi?id=6498#c1)
What is really needed is the ability to update variables
On Monday, 2 June 2014 at 14:16:50 UTC, Steven Schveighoffer
wrote:
On Fri, 30 May 2014 22:40:29 -0400, Martin Nowak
wrote:
On Thursday, 29 May 2014 at 15:28:28 UTC, safety0ff wrote:
If would be nice if Don could elaborate on his comment in bug
#6498 (https://issues.dlang.org/show_bug.cgi?id
On Mon, 02 Jun 2014 10:47:56 -0400, Dicebot wrote:
On Monday, 2 June 2014 at 14:16:50 UTC, Steven Schveighoffer
wrote:
On Fri, 30 May 2014 22:40:29 -0400, Martin Nowak wrote:
On Thursday, 29 May 2014 at 15:28:28 UTC, safety0ff wrote:
If would be nice if Don could elaborate on his comment in
On Monday, 2 June 2014 at 14:47:57 UTC, Dicebot wrote:
On Monday, 2 June 2014 at 14:16:50 UTC, Steven Schveighoffer
wrote:
On Fri, 30 May 2014 22:40:29 -0400, Martin Nowak
wrote:
On Thursday, 29 May 2014 at 15:28:28 UTC, safety0ff wrote:
If would be nice if Don could elaborate on his comment
On Monday, 2 June 2014 at 20:54:28 UTC, deadalnix wrote:
Even if you do, you could create a pool for allocating CTFE. At
the end, you move objects you are interested in from that pool
to
some other memory location and trash the whole pool.
I have proposed that during DConf as temporary workar
On Thursday, 29 May 2014 at 18:12:59 UTC, Timon Gehr wrote:
On 05/29/2014 06:53 PM, Dylan Knutson wrote:
...
Is there anything so radically different in D than these other
languages, that prevents the implementation of a
run-of-the-mill VM to
eval D code?
No. (In fact, I've written a naive
28 matches
Mail list logo
