View previous topic :: View next topic |
Author |
Message |
unDEFER
Joined: 15 Aug 2011 Posts: 6
|
Posted: Mon Aug 15, 2011 4:10 pm Post subject: So why it designed with this way? |
|
|
Hello!
I'm very green and newbie in D. And try to use it on Linux platform.
I have worried with sizes of the simplest program on D which working with OpenGL and SDL.
The libDerelictGL.a has 1,5 Mb size and the executable in the result has 1,4 Mb size. After "strip --strip-unneeded" it gets 914K filesize.
I think this sizes connected with the main feature of the D - dynamic loading libraries. The next text from documentation:
Quote: | What makes Derelict different from other D bindings to C libraries is in the method used to link. Most bindings are designed to be linked at compile time either with a static version of a C library, or with the dynamic version. Derelict does not support static linking in any form. Instead, it requires the bound libraries to always be in shared form. The shared libraries are loaded manually at runtime. |
So why it have implemented with this way? What advantages this way has?
If there is any bindings for OpenGL and SDL "designed to be linked at compile time"?
Thank you in advance. |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Mon Aug 15, 2011 11:47 pm Post subject: Re: So why it designed with this way? |
|
|
unDEFER wrote: |
So why it have implemented with this way? What advantages this way has? |
There are several reasons. The most important being that I started the project for myself and I like it that way .
If a shared library is unavailable or corrupted, then the load method will throw an exception. This allows you to give instructions to the user, open up the web browser to a trouble shooting page, fall back on another alternative, or whatever you want to do. It also allows allows for a selective loading mechanism to easily support multiple versions of a library in the same application. Plus, on Windows, it avoids the annoyance of having to convert the import library to the proper format.
Quote: |
If there is any bindings for OpenGL and SDL "designed to be linked at compile time"? |
I've seen some over the years, but I don't know how up to date they are. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
unDEFER
Joined: 15 Aug 2011 Posts: 6
|
Posted: Tue Aug 16, 2011 2:33 am Post subject: Re: So why it designed with this way? |
|
|
Thank you, aldacron!
Do you need tester for GDC compilation? I see it doesn't compile with GDC now.
So anybody don't think that difference in 166 times between binary sizes of D program and C program is too big? (stripped version of C programs takes only 5,5K that much more less than 914K of stripped D program binary).
Not stripped C program binary takes 19K (in 74 times less). |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Tue Aug 16, 2011 5:56 am Post subject: Re: So why it designed with this way? |
|
|
unDEFER wrote: | Thank you, aldacron!
Do you need tester for GDC compilation? I see it doesn't compile with GDC now. |
I had no idea compilation on GDC was broken. What are the errors?
Quote: |
So anybody don't think that difference in 166 times between binary sizes of D program and C program is too big? (stripped version of C programs takes only 5,5K that much more less than 914K of stripped D program binary).
Not stripped C program binary takes 19K (in 74 times less). |
Once in a while someone complains on the newsgroups that the binaries are too big. But I think most D users just don't worry about it. I know I don't. After all, most of the bloat is a fixed cost per app, so as the amount of code grows, the growth rate of the executable is not so big. It's just not an issue for most people.
One thing you have to remember is that C programs usually make use of a system-wide standard library or runtime, so they generally do not get compiled in to the executable. When you compile a D program, however, you are getting a large chunk of both Phobos and DRuntime added in, along with a good bit of metadata for modules and types. It all adds up. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
unDEFER
Joined: 15 Aug 2011 Posts: 6
|
Posted: Tue Aug 16, 2011 7:48 am Post subject: Re: So why it designed with this way? |
|
|
aldacron wrote: | One thing you have to remember is that C programs usually make use of a system-wide standard library or runtime, so they generally do not get compiled in to the executable. When you compile a D program, however, you are getting a large chunk of both Phobos and DRuntime added in, along with a good bit of metadata for modules and types. It all adds up. |
Thank you for this explain. Looks like the big binary sizes is the problem of exclusively DMD compiler. DMD compiles "hello world" for 2.2 sec and makes 716K binary. GDC compiles the same for 0.6 sec and makes 242K binary.
Stripped versions has sizes 472K and 166K accordingly.
So lets try to make Derelict2 compilable with GDC if you are not against.
The error looks like in the make files:
Code: | gdmd -release -O -inline -lib -I../DerelictUtil derelict/allegro/acodec.d -Hd../import/derelict/allegro -oflibDerelictAllegroACodec.a
make[1]: *** No rule to make target `gdmd_build_cod', needed by `libDerelictAllegroACodec.a'. Stop. |
|
|
Back to top |
|
|
unDEFER
Joined: 15 Aug 2011 Posts: 6
|
Posted: Tue Aug 16, 2011 8:15 am Post subject: Re: So why it designed with this way? |
|
|
LOL, here the patch to make gdmd working:
Code: | Index: DerelictAllegro/Makefile
===================================================================
--- DerelictAllegro/Makefile (revision 583)
+++ DerelictAllegro/Makefile (working copy)
@@ -93,7 +93,7 @@
gdmd_build_aud:
$(DC) $(DFLAGS) $(DFLAGS_REQ) $(AUD_SRC) $(HD)/$(PACKAGE_PATH) $(OF)$(AUD_LIB)
-gdmd_build_aud:
+gdmd_build_cod:
$(DC) $(DFLAGS) $(DFLAGS_REQ) $(COD_SRC) $(HD)/$(PACKAGE_PATH) $(OF)$(COD_LIB)
copylib: |
My the simplest program binary takes now 630K and 392K in stripped version. So I'm satisfied with this sizes. Thank you. |
|
Back to top |
|
|
unDEFER
Joined: 15 Aug 2011 Posts: 6
|
Posted: Tue Aug 16, 2011 9:56 am Post subject: |
|
|
Hm.. I have read D code calling D code in DLLs and have new question:
so there is no in D more easier way to use shared (dynamic) libraries than one which uses Derelict?
In C I can use the same code to use shared (dynamic) library also as static version of one. But D compiler can't to compile D-code with shared library to make it loadable with OS-methods without manually calling functions like Runtime.loadLibrary()? |
|
Back to top |
|
|
doob
Joined: 06 Jan 2007 Posts: 367
|
Posted: Tue Aug 16, 2011 10:37 am Post subject: |
|
|
unDEFER wrote: | In C I can use the same code to use shared (dynamic) library also as static version of one. But D compiler can't to compile D-code with shared library to make it loadable with OS-methods without manually calling functions like Runtime.loadLibrary()? |
Currently the support for dynamic libraries in D isn't very good, it kind of works on Mac OS X. It is/will be possible to create D dynamic libraries that don't need to call any function to initialize the runtime. This can be achieved by having a small C file containing two functions declared with __attribute__((constructor)) and the corresponding destructor. These functions can initialize and terminate the runtime, see https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dylib_fixes.c |
|
Back to top |
|
|
doob
Joined: 06 Jan 2007 Posts: 367
|
Posted: Tue Aug 16, 2011 10:42 am Post subject: Re: So why it designed with this way? |
|
|
unDEFER wrote: | Hello!
I'm very green and newbie in D. And try to use it on Linux platform.
I have worried with sizes of the simplest program on D which working with OpenGL and SDL.
The libDerelictGL.a has 1,5 Mb size and the executable in the result has 1,4 Mb size. After "strip --strip-unneeded" it gets 914K filesize. |
Compared to C and C++, D's standard library and runtime is statically linked, not dynamically linked. This will cause the executable size to grow quite a lot. If you instead build the runtime and standard library as dynamic libraries (possible on Mac OS X) the size of a Hello World executable written in D will be of the same size as one written in C.
The advantage C has is that's available on all platforms, meaning you don't have to distribute the runtime or standard library, as you would need with D. |
|
Back to top |
|
|
unDEFER
Joined: 15 Aug 2011 Posts: 6
|
Posted: Tue Aug 16, 2011 10:59 am Post subject: |
|
|
Thank you, doob!
I yet don't decide if I will split my project on dynamic libraries, but I very hope that when it will be needed I will find way to make D dynamic libraries auto-initializable. |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Wed Aug 17, 2011 6:57 am Post subject: Re: So why it designed with this way? |
|
|
unDEFER wrote: | LOL, here the patch to make gdmd working:
|
Thanks! I've updated SVN with the fix. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
|