Re: Templates do maybe not need to be that slow (no promises)

2016-09-11 Thread Stefan Koch via Digitalmars-d
There are more news. I wrote about manual template in-lining before, which is a fairly effective in bringing down the compile-time. Since templates are of course white-box, the compiler can do this automatically for you. Recursive templates will still incur a performance hit but the effects

Re: Templates do maybe not need to be that slow (no promises)

2016-09-10 Thread Stefan Koch via Digitalmars-d
On Friday, 9 September 2016 at 07:56:04 UTC, Stefan Koch wrote: There is a direct linear relationship between the generated code and the template body. So If the range of change inside the template body can be linked to the changed range in the binray and we link this to the template

Re: Templates do maybe not need to be that slow (no promises)

2016-09-09 Thread Iakh via Digitalmars-d
On Friday, 9 September 2016 at 15:28:55 UTC, Stefan Koch wrote: On Friday, 9 September 2016 at 15:08:26 UTC, Iakh wrote: On Friday, 9 September 2016 at 07:56:04 UTC, Stefan Koch wrote: I was thinking on adding "opaque" attribute for template arguments to force template to forget some

Re: Templates do maybe not need to be that slow (no promises)

2016-09-09 Thread Stefan Koch via Digitalmars-d
On Friday, 9 September 2016 at 15:08:26 UTC, Iakh wrote: On Friday, 9 September 2016 at 07:56:04 UTC, Stefan Koch wrote: I was thinking on adding "opaque" attribute for template arguments to force template to forget some information about type. E.g if you use class A(opaque T) {...} you can

Re: Templates do maybe not need to be that slow (no promises)

2016-09-09 Thread Iakh via Digitalmars-d
On Friday, 9 September 2016 at 07:56:04 UTC, Stefan Koch wrote: I was thinking on adding "opaque" attribute for template arguments to force template to forget some information about type. E.g if you use class A(opaque T) {...} you can use only pointers/references to T. Probably compiler could

Re: Templates do maybe not need to be that slow (no promises)

2016-09-09 Thread Marco Leise via Digitalmars-d
Am Fri, 09 Sep 2016 10:32:59 + schrieb Stefan Koch : > On Friday, 9 September 2016 at 09:31:37 UTC, Marco Leise wrote: > > > > Don't worry about this special case too much. At least GCC can > > turn padLength from a runtime argument into a compile-time > >

Re: Templates do maybe not need to be that slow (no promises)

2016-09-09 Thread Stefan Koch via Digitalmars-d
On Friday, 9 September 2016 at 09:31:37 UTC, Marco Leise wrote: Don't worry about this special case too much. At least GCC can turn padLength from a runtime argument into a compile-time argument itself, so the need for templates to do a poor man's const-folding is reduced. So in this case

Re: Templates do maybe not need to be that slow (no promises)

2016-09-09 Thread Marco Leise via Digitalmars-d
Am Fri, 09 Sep 2016 07:56:04 + schrieb Stefan Koch : > Hi Guys, > > I keep this short. > There seems to be much more headroom then I had thought. > > The Idea is pretty simple. > > Consider : > int fn(int padLength)(int a, int b, int c) > { >/** > very

Templates do maybe not need to be that slow (no promises)

2016-09-09 Thread Stefan Koch via Digitalmars-d
Hi Guys, I keep this short. There seems to be much more headroom then I had thought. The Idea is pretty simple. Consider : int fn(int padLength)(int a, int b, int c) { /** very long function body 1000+ lines */ return result * padLength; } This will produce roughly the same code for