In article <Xns96387F0754DB5myidtoken@63.105.9.61>, Marcio says...
>
>"Dave" <Dave_member@pathlink.com> wrote in news:d3m1oa$15de$1@digitaldaemon.com:
>
>> IIRC, it's been a goal stated in the past for the compiler to "auto-finalize" if it can. Because of the language design this is something D compilers can readily do, even across source files. But it hasn't been implemented yet - the D compiler is not at v1.0 yet (but that's not to imply that v1.0 will do auto-finalization either - I don't know).
>
>
>  It will be interesting to see when it gets added.
>
>  I also wonder if global analysis & this optimization can be done at all if
>you allow the system to be extended via "OO DLLs". I mean components written in your OO language which can be linked in at runtime. For example, OTI/IBM Smalltalk's ICX stuff, or Java JARs etc. Does D support this ? Does it plan to ? Interestingly enough, SmartEiffel does not support this feature, but only a "monolythic app". It will be interesting to see what D will be capable of doing in this area... speed versus runtime OO extensions... Will it be able to do both ?
>
>marcio

For calls into D libraries, yes, but not for calls into other languages - those that are declared 'extern' and such (take a look here: http://digitalmars.com/d/interface.html).

For calls into D code that is not declared 'extern' this is already done to some extent (for example, for function/method inlining). More cross-source-file optimizations just have to be added to the compiler - the language spec. supports them.

Right now, the 'import' semantics require actual source code files to be imported to get the opimizations. However, there are plans for the compiler to export "symbol" files that can be distributed with libraries (static or DLL) that will then be imported. In that way: 1) You don't have to distrubute source code, 2) The symbol files should make large-scale compilation faster, 3) You can still get the same quality global optimizations at compile-time rather than at link-time (as some C/C++ compilers do know) or run-time, as the SmallTalk and Java systems do.

- Dave

Dave <Dave_member@pathlink.com> wrote:

> What compiler options?

"-O -release -inline" for both, whereby gdc is started from its dmd- script.

> W/o 'final' or 'private' DMD is the same as GDC (well, 5% diff,
> not 25% like your results).
> 
> W/ final or private, DMD is actually a tad bit faster.

So what are the critical points? As I pointed out earlier
http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/982
gdc is at least 25% faster on my AMD Athlon 64 3500+ running under
WIN XP PRO 32bit Service Pack 2 in the cygwin version.

-manfred

In article <d3miq0$1nf8$1@digitaldaemon.com>, Dave says...
> [snip]
> 3) You can
>still get the same quality global optimizations at compile-time rather than at link-time (as some C/C++ compilers do know) or run-time, as the SmallTalk and Java systems do.
>

What piqued my interest in there was "run-time".  Are you suggesting that symbol files could allow D to accomplish run-time linking?

I've often wondered how D would tackle run-time linking myself as I've been grappling with the deficiencies of dlls for sometime now.  I understand that other language platforms accomplish this with ease (.NET, Java, and you mentioned SmallTalk), but D has some fundamental differences that might make this a challenge.   Given the tools we have now, the only forseeable way to accomplish this is to have dlls' with massive export tables and/or an engine that loads object files directly... I'm sure there are other techniques to be investigated.

Dave, I'm a complete novice when it comes to the concept of 'symbol files'... could you point me in the right direction on the topic?  Maybe there's a way to assemble a short-term solution for D in this regard to enable runtime linking.

Thanks,

- EricAnderton at yahoo

In article <d3mjv4$1oco$1@digitaldaemon.com>, Manfred Nowak says...
>
>Dave <Dave_member@pathlink.com> wrote:
>
>> What compiler options?
>
>"-O -release -inline" for both, whereby gdc is started from its dmd- script.
>
>> W/o 'final' or 'private' DMD is the same as GDC (well, 5% diff,
>> not 25% like your results).
>> 
>> W/ final or private, DMD is actually a tad bit faster.
>
>So what are the critical points? As I pointed out earlier
>http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/982
>gdc is at least 25% faster on my AMD Athlon 64 3500+ running under
>WIN XP PRO 32bit Service Pack 2 in the cygwin version.
>
>-manfred

No critical points - just wondered how you ran them because the relative results are different than on my Intel system.

Just curious - what does 'gcc -v' report for your cygwin system?

- Dave

In article <d3mkra$1p4h$1@digitaldaemon.com>, pragma says...
>
>In article <d3miq0$1nf8$1@digitaldaemon.com>, Dave says...
>> [snip]
>> 3) You can
>>still get the same quality global optimizations at compile-time rather than at link-time (as some C/C++ compilers do know) or run-time, as the SmallTalk and Java systems do.
>>
>
>What piqued my interest in there was "run-time".  Are you suggesting that symbol files could allow D to accomplish run-time linking?
>
>I've often wondered how D would tackle run-time linking myself as I've been grappling with the deficiencies of dlls for sometime now.  I understand that other language platforms accomplish this with ease (.NET, Java, and you mentioned SmallTalk), but D has some fundamental differences that might make this a challenge.   Given the tools we have now, the only forseeable way to accomplish this is to have dlls' with massive export tables and/or an engine that loads object files directly... I'm sure there are other techniques to be investigated.
>
>Dave, I'm a complete novice when it comes to the concept of 'symbol files'... could you point me in the right direction on the topic?  Maybe there's a way to assemble a short-term solution for D in this regard to enable runtime linking.
>

I'm no expert, but IIRC the context of the earlier discussion of imported symbol files mentioned just 'library' files, so I don't know (for sure) if that also included DLL's or just static libs. But I presume it would apply to DLL's too because the mechanics should be the same.

To visualize what importing the symbol files could do for optimization, see the 2nd "import mydll;" line here (about 3/4 down the page):

http://digitalmars.com/d/dll.html

I would think that either source imports (as now) or detailed enough "symbol" file imports could be used by a static D compiler to make really good decisions at compile time on optimizing the "caller" code to use the "callee" code during runtime. The important optimization decisions would all be made during compilation, but the effect would be faster executables at runtime.

One of the "runtime advantages" said to be held by JIT compilers is that they have access to library code in the context of how it is run with the executable where static compilers don't. For C and C++ this is because header files are just declarations and not definitions. The semantics of import should allow pretty much the same advantage for D at compile time as JIT'ed languages have at runtime. Maybe even more so because the context will be clearer (symbols rather than machine code).

Make sense? Like I said, I'm no expert.

- Dave

>Thanks,
>
>- EricAnderton at yahoo

Dave <Dave_member@pathlink.com> wrote:

[...]
> Just curious - what does 'gcc -v' report for your cygwin system?

Konfiguriert mit: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr
--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --
libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,java,objc,pascal --enable-nls --
without-included-gettext --enable-libgcj --with-system-zlib --enable-
interpreter --enable-threads=posix --enable-java-gc=boehm --enable-s
jlj-exceptions --disable-version-specific-runtime-libs --disable-
win32-registry
Thread-Modell: posix
gcc-Version 3.3.3 (cygwin special)

-manfred