View mode: basic / threaded / horizontal-split · Log in · Help
April 14, 2005
Re: speed of polymorphic calls
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
April 14, 2005
Re: speed of polymorphic calls
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
April 14, 2005
Re: speed of polymorphic calls
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
April 14, 2005
Re: speed of polymorphic calls
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
April 14, 2005
Re: speed of polymorphic calls
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
April 14, 2005
Re: speed of polymorphic calls
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home