March 14, 2012
On Wed, 14 Mar 2012 14:17:28 -0700, Adam D. Ruppe <destructionator@gmail.com> wrote:

> Adam Wilson:
>
> I think I said this before, but for what it's worth,
> I think your new approach is spot-on correct.

Thank you. More importantly though, Walter and Andrei also agree, so in the end, the inlinaholics can just deal. :-)

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
March 14, 2012
El 14/03/2012 22:13, Adam Wilson escribió:
> On Wed, 14 Mar 2012 13:45:13 -0700, Alvaro <alvaroDotSegura@gmail.com>
> wrote:
>
> The problem is that in DI generation, at least as near as I can tell, D
> has now idea how big a function is during DI generation. In my
> experience it was keeping all functions not just small ones. And frankly
> DI generation is targeted at library builders who are well aware of the
> inlining trade-offs. And then comes the question of how do you define
> "small functions" to an adequately technical level.>

OK, I rechecked. DMD -H is at least omitting function bodies containing foreach() loops (and maybe other cases). Maybe that led me to assume things.

AFAIK some C++ compilers use heuristics (don't really know what that is exactly) to decide what "small functions" deserved automatic inlining.

And well, C++ library builders are aware of that and usually keep the small functions they want inlined in the header file (e.g. in the class declaration). I can see a lot of cases where D libraries would benefit from allowing some of their functions to be inlined. Think of @properties, they're often pretty short.

Other than this detail, the improvement in DI generation is very welcome.

March 14, 2012
On Wed, 14 Mar 2012 14:42:54 -0700, Alvaro <alvaroDotSegura@gmail.com> wrote:

> El 14/03/2012 22:13, Adam Wilson escribió:
>  > On Wed, 14 Mar 2012 13:45:13 -0700, Alvaro <alvaroDotSegura@gmail.com>
>  > wrote:
>  >
>  > The problem is that in DI generation, at least as near as I can tell, D
>  > has now idea how big a function is during DI generation. In my
>  > experience it was keeping all functions not just small ones. And frankly
>  > DI generation is targeted at library builders who are well aware of the
>  > inlining trade-offs. And then comes the question of how do you define
>  > "small functions" to an adequately technical level.>
>
> OK, I rechecked. DMD -H is at least omitting function bodies containing foreach() loops (and maybe other cases). Maybe that led me to assume things.

Hmmm, I hadn't seen it do this. But the whole point of DI files is to create an interface to compiled libraries, not be the absolute fastest it can be. It is generally accepted that you are going to take a minuscule (and on modern machines it is truly minuscule) hit every time you cross a library boundary, unless you import the whole source of said library, which is functionally what DI generation does now.

> AFAIK some C++ compilers use heuristics (don't really know what that is exactly) to decide what "small functions" deserved automatic inlining.

Those heuristics are in the semantic analysis step and I really don't think building the DI file against the constantly changing AST during semantic analysis is a wise idea. DI's get built before that, and as such do no have access to those heuristics. If the compiler is doing something it's based on its own special, and limited analysis prior to the semantic analysis (I think I know which function is doing this, but it doesn't work very well at all). Also, trying to build DI's during semantic analysis would most likely drastically slow down the compiler as the DI's would need to be constantly updated to make the AST changes. Basically, it's an incredible amount of work for a minuscule speed improvement in the final step. There are areas of D that are MUCH more ripe for speed improvements than inlining in DI files ... *cough*GC*cough*

> And well, C++ library builders are aware of that and usually keep the small functions they want inlined in the header file (e.g. in the class declaration). I can see a lot of cases where D libraries would benefit from allowing some of their functions to be inlined. Think of @properties, they're often pretty short.

Well, that's where the do-it-yourself part into play. This is an automated system for generating headers based on a naive AST. It will not be perfect. But C++ doesn't even have that and they have to hand maintain everything, so pretty much anything we do is an improvement. :-)
@properties are a valid concern, and also one that can be addressed in the current method of DI generation as they are a valid token that can be checked for and excluded. If the community wishes for @properties to retain their implementations that would an easy thing to do. But be warned, you wont be able to call private functions as those are dropped COMPLETELY from the DI file. Private data will of course be accessible.

> Other than this detail, the improvement in DI generation is very welcome.

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
1 2 3 4 5 6
Next ›   Last »