Menu
▾
▴
mingw-users
|
From: Andy S. <was...@ea...> - 2003-12-05 11:39:40
|
All, Does anyone know which libraries I need to link with to call the win32 service functions? I would like for my application to be able to register itself and run as a service. Thanks, Andy Smith |
|
From: Benjamin R. <Ben...@ep...> - 2003-12-05 12:10:54
|
Hi Andy, Andy Smith <was...@ea...> writes: > Does anyone know which libraries I need to link with to call the > win32 service functions? I would like for my application to be able > to register itself and run as a service. Something like this should tell you: grep -l the-function-you-want /usr/lib/*.a /usr/lib/w32api/*.a Or at least it should give you some candidates, that you can than verify with "nm". benny |
|
From: Earnie B. <ea...@us...> - 2003-12-05 12:54:32
|
Benjamin Riefenstahl wrote: > Hi Andy, > > > Andy Smith <was...@ea...> writes: > >>Does anyone know which libraries I need to link with to call the >>win32 service functions? I would like for my application to be able >>to register itself and run as a service. > > > Something like this should tell you: > > grep -l the-function-you-want /usr/lib/*.a /usr/lib/w32api/*.a > You want /mingw/lib not /usr/lib for the MinGW libraries. > Or at least it should give you some candidates, that you can than > verify with "nm". > I typically will ``nm --defined-only --print-file-name --demangle /mingw/lib/*.a | grep ' [TD] ' > /mingw/lib/libdef.txt'' and then ``grep my_needed_function /mingw/lib/libdef.txt''. Earnie. -- http://www.mingw.org <http://sourceforge.net/projects/mingw> |
|
From: Andy S. <was...@ea...> - 2003-12-05 13:23:11
|
Thanks all. A simple grep of /mingw/lib was all it took. My first run through I gave grep the -I option which is why I didn't find anything in a directory full of binaries. Doh! Andy Earnie Boyd wrote: > > > Benjamin Riefenstahl wrote: > >> Hi Andy, >> >> >> Andy Smith <was...@ea...> writes: >> >>> Does anyone know which libraries I need to link with to call the >>> win32 service functions? I would like for my application to be able >>> to register itself and run as a service. >> >> >> >> Something like this should tell you: >> >> grep -l the-function-you-want /usr/lib/*.a /usr/lib/w32api/*.a >> > > You want /mingw/lib not /usr/lib for the MinGW libraries. > >> Or at least it should give you some candidates, that you can than >> verify with "nm". >> > > I typically will ``nm --defined-only --print-file-name --demangle > /mingw/lib/*.a | grep ' [TD] ' > /mingw/lib/libdef.txt'' and then > ``grep my_needed_function /mingw/lib/libdef.txt''. > > Earnie. |
|
From: Don H. <do...@al...> - 2003-12-06 01:15:05
|
hi, I'm new in this mailing-list. I build my project with both VC++ 7 and MinGW v.3.1.0 + GCC v.3.2.3. And I'm supprised that the binary file generated by MinGW + GCC is mach bigger than the one generated by VC++ 7 (492 KB vs 340 KB)! Even I use "-Os -DNDEBUG" flag for compiling and linking! Is there something more that I can do to optimize maximum the generated binary? Don HO Je bouffe donc je suis |
|
From: Oscar F. <of...@wa...> - 2003-12-06 17:36:21
|
"Don HO" <do...@al...> writes: > I build my project with both VC++ 7 and MinGW v.3.1.0 + GCC v.3.2.3. > And I'm supprised that the binary file generated by MinGW + GCC is > mach bigger than the one generated by VC++ 7 (492 KB vs 340 KB)! > Even I use "-Os -DNDEBUG" flag for compiling and linking! IMHO that difference is not so important. Is it a C++ program or a C one? > Is there something more that I can do to optimize maximum the generated > binary? Try strip -s your_exe_file.exe for your MinGW-generated executable. -- Oscar |
|
From: Don H. <do...@al...> - 2003-12-06 22:43:16
|
Nop, 497 kb is definitively the minimum size of my exe(generated by GCC)! I did already strip all the symbol during the link procedure (LDFLAGS = -mwindows -Wl,-s -lcomctl32 -lshlwapi -Os) I guess the code of MinGW's libary is bigger than the one of M$, that's why there's so big different size (almost 140 KB!) Any idea? Don HO Je bouffe donc je suis Find a powerful free (and open source) multi-function editor at http://notepad-plus.sourceforge.net/ ----- Original Message ----- From: "Oscar Fuentes" <of...@wa...> To: <min...@li...> Sent: Saturday, December 06, 2003 6:36 PM Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 generated binary !!! > "Don HO" <do...@al...> writes: > > > I build my project with both VC++ 7 and MinGW v.3.1.0 + GCC v.3.2.3. > > And I'm supprised that the binary file generated by MinGW + GCC is > > mach bigger than the one generated by VC++ 7 (492 KB vs 340 KB)! > > Even I use "-Os -DNDEBUG" flag for compiling and linking! > > IMHO that difference is not so important. Is it a C++ program or a C one? > > > Is there something more that I can do to optimize maximum the generated > > binary? > > Try > > strip -s your_exe_file.exe > > for your MinGW-generated executable. > > -- > Oscar > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
From: Miroslav F. <cx...@nt...> - 2003-12-07 11:14:43
|
> Nop, 497 kb is definitively the minimum size of my exe(generated by GCC)!
> I did already strip all the symbol during the link procedure (LDFLAGS
> = -mwindows -Wl,-s -lcomctl32 -lshlwapi -Os)
> I guess the code of MinGW's libary is bigger than the one of M$, that's
why
> there's so big different size (almost 140 KB!)
> Any idea?
Yes. LD does not support elimination of dead code. It includes whole .c
/ .cpp files, whereas MSC includes files on per-function basis.
Mirek
|
|
From: Don H. <do...@al...> - 2003-12-07 14:25:47
|
Thanks Mirek, Is there a remedy for that? 160 KB (497 KB vs 340 KB) is really huge! Don HO Je bouffe donc je suis Find a powerful free (and open source) multi-function editor at http://notepad-plus.sourceforge.net/ ----- Original Message ----- From: "Miroslav Fidler" <cx...@nt...> To: <min...@li...> Sent: Sunday, December 07, 2003 12:24 PM Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 generated binary !!! > Yes. LD does not support elimination of dead code. It includes whole .c > / .cpp files, whereas MSC includes files on per-function basis. > > Mirek > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
From: Miroslav F. <cx...@nt...> - 2003-12-08 09:06:54
|
> Is there a remedy for that?
> 160 KB (497 KB vs 340 KB) is really huge!
Right now not. LD/Win32 would need to support --gc-sections switch -
that would probably solve the problem. Unfortunately, this option seems to
be unsupported now.
Mirek
|
|
From: Bert D. <be...@be...> - 2003-12-08 09:20:45
|
How much memory do you have in your computer? Is this really =
significant?
----- Original Message -----=20
From: Miroslav Fidler=20
To: min...@li...=20
Sent: Monday, December 08, 2003 3:15 AM
Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 =
generated binary !!!
> Is there a remedy for that?
> 160 KB (497 KB vs 340 KB) is really huge!
Right now not. LD/Win32 would need to support --gc-sections switch =
-
that would probably solve the problem. Unfortunately, this option =
seems to
be unsupported now.
Mirek
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for =
IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys =
admin.
Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
MinGW-users mailing list
Min...@li...
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
From: Miroslav F. <cx...@nt...> - 2003-12-08 09:43:53
|
I agree this is not the most important thing. Anyway, given two same =
executables doing exactly same thing, but one 4MB long and other 2.5MB, =
which one would you download and install ?!
Mirek
----- Original Message -----=20
From: Bert Douglas=20
To: min...@li...=20
Sent: Monday, December 08, 2003 10:20 AM
Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 =
generated binary !!!
How much memory do you have in your computer? Is this really =
significant?
----- Original Message -----=20
From: Miroslav Fidler=20
To: min...@li...=20
Sent: Monday, December 08, 2003 3:15 AM
Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 =
generated binary !!!
> Is there a remedy for that?
> 160 KB (497 KB vs 340 KB) is really huge!
Right now not. LD/Win32 would need to support --gc-sections =
switch -
that would probably solve the problem. Unfortunately, this option =
seems to
be unsupported now.
Mirek
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for =
IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys =
admin.
Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
MinGW-users mailing list
Min...@li...
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
From: Earnie B. <ea...@us...> - 2003-12-08 12:51:24
|
Perhaps you should GOOGLE. Try a search string of ``mingw size of exe'' to see if you can come up with the answer. I've given it before. C++ runtime is static for GCC and dynamic for VC++. Earnie. Miroslav Fidler wrote: > I agree this is not the most important thing. Anyway, given two same > executables doing exactly same thing, but one 4MB long and other 2.5MB, > which one would you download and install ?! > > Mirek > > ----- Original Message ----- > *From:* Bert Douglas <mailto:be...@be...> > *To:* min...@li... > <mailto:min...@li...> > *Sent:* Monday, December 08, 2003 10:20 AM > *Subject:* Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 > generated binary !!! > > How much memory do you have in your computer? Is this really > significant? > > ----- Original Message ----- > *From:* Miroslav Fidler <mailto:cx...@nt...> > *To:* min...@li... > <mailto:min...@li...> > *Sent:* Monday, December 08, 2003 3:15 AM > *Subject:* Re: [Mingw-users] Generated Binary is BIGGER than > VC++ 7 generated binary !!! > > > Is there a remedy for that? > > 160 KB (497 KB vs 340 KB) is really huge! > > Right now not. LD/Win32 would need to support --gc-sections > switch - > that would probably solve the problem. Unfortunately, this > option seems to > be unsupported now. > > Mirek > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up > for IBM's > Free Linux Tutorials. Learn everything from the bash shell to > sys admin. > Click now! > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > <http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click> > _______________________________________________ > MinGW-users mailing list > Min...@li... > <mailto:Min...@li...> > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users -- http://www.mingw.org <http://sourceforge.net/projects/mingw> |
|
From: Miroslav F. <cx...@nt...> - 2003-12-08 13:53:31
|
> Perhaps you should GOOGLE. Try a search string of ``mingw size of exe''
Did that. Tons of invalid answers, nothing that would lead to reducing
my .exe size.
> to see if you can come up with the answer. I've given it before. C++
> runtime is static for GCC and dynamic for VC++.
Not a cause. I can use about 100KB of runtime maximum. But my
application size is megabytes (1.9MB using VC++, 3.9 using GCC/LD). Plus, I
often link statically using VC++.
Problem really is missing per-function dead code elimination.
Mirek
|
|
From: jacob n. <ja...@ja...> - 2003-12-08 16:14:44
|
Do you have the object files? I would be interested in looking at the biggest one, for instance. Zip it and send it to ja...@ja... Thanks ----- Original Message ----- From: "Miroslav Fidler" <cx...@nt...> To: <min...@li...> Sent: Monday, December 08, 2003 3:03 PM Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 generated binary !!! > > Perhaps you should GOOGLE. Try a search string of ``mingw size of exe'' > > Did that. Tons of invalid answers, nothing that would lead to reducing > my .exe size. > > > to see if you can come up with the answer. I've given it before. C++ > > runtime is static for GCC and dynamic for VC++. > > Not a cause. I can use about 100KB of runtime maximum. But my > application size is megabytes (1.9MB using VC++, 3.9 using GCC/LD). Plus, I > often link statically using VC++. > > Problem really is missing per-function dead code elimination. > > Mirek > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
|
From: Bert D. <be...@be...> - 2003-12-08 16:15:36
|
I would be interested in the one with the best documentation, and the =
best features. But then again, I have DSL connection and 1 gig of =
memory.=20
There are times when it is worthwhile to shrink code to minimum size. I =
have done this for flash-memory systems. But for most typical pc =
applications, your time would be better spent on other tasks.
----- Original Message -----=20
From: Miroslav Fidler=20
To: min...@li...=20
Sent: Monday, December 08, 2003 3:53 AM
Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 =
generated binary !!!
I agree this is not the most important thing. Anyway, given two same =
executables doing exactly same thing, but one 4MB long and other 2.5MB, =
which one would you download and install ?!
Mirek
----- Original Message -----=20
From: Bert Douglas=20
To: min...@li...=20
Sent: Monday, December 08, 2003 10:20 AM
Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 =
generated binary !!!
How much memory do you have in your computer? Is this really =
significant?
----- Original Message -----=20
From: Miroslav Fidler=20
To: min...@li...=20
Sent: Monday, December 08, 2003 3:15 AM
Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 =
generated binary !!!
> Is there a remedy for that?
> 160 KB (497 KB vs 340 KB) is really huge!
Right now not. LD/Win32 would need to support --gc-sections =
switch -
that would probably solve the problem. Unfortunately, this option =
seems to
be unsupported now.
Mirek
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up =
for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys =
admin.
Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
MinGW-users mailing list
Min...@li...
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
From: jacob n. <ja...@ja...> - 2003-12-08 16:45:36
|
----- Original Message -----=20 From: Bert Douglas=20 To: min...@li...=20 Sent: Monday, December 08, 2003 5:15 PM Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 = generated binary !!! I would be interested in the one with the best documentation, and the = best features. But then again, I have DSL connection and 1 gig of = memory.=20 There are times when it is worthwhile to shrink code to minimum size. = I have done this for flash-memory systems. But for most typical pc = applications, your time would be better spent on other tasks This is the mentality of software progress. That is why my new AMD64 processor with 512 MB of RAM uses up 380 MB at = startup, with a single shell and the explorer running. Yes, I have to buy yet another = 512MB RAM to be able to start the compiler. Yes, the compiler. The compiler takes almost 15 seconds to start and load my project, more = or less the same time that took since I was running windows 3.1. All hardware performance gains are destroyed systematically by people = like you. WHO CARES? Nobody. This increases consumption (I need 512MB RAM), and reduces = mental effort of the developers. Who needs anything else? Why care if the application takes 4MB or 2MB? The IDE of lcc-win32 is 750K. This includes: o editor with syntax coloring o project generation and make o full windowed debugger o versioning system o software metrics module o syntax analyzer in real time This just can't be done with any other compiler around. I suspect that the problem is not only dead code elimination. Several = years ago I spotted a bug in gcc that increased the code bloat with unnecessary instructions = by 10-15%. I think I will look again at that compiler. jacob |
|
From: Oscar F. <of...@wa...> - 2003-12-08 17:22:15
|
"jacob navia" <ja...@ja...> writes: > I would be interested in the one with the best > documentation, and the best features. But then again, I have DSL > connection and 1 gig of memory. > > There are times when it is worthwhile to shrink > code to minimum size. I have done this for flash-memory systems. > But for most typical pc applications, your time would be better spent on other > tasks > This is the mentality of software > progress. > That is why my new AMD64 processor with 512 > MB of RAM uses up 380 MB at startup, with a > single shell and the explorer running. Yes, > I have to buy yet another 512MB RAM to be able > to start the compiler. Yes, the > compiler. You doubled the word size, so an increase is natural. However, I'm pretty sure you are exaggerating things here. > The compiler takes almost 15 seconds to > start and load my project, more or less the same > time that took since I was running windows > 3.1. What OS are you using? Are you sure your machine is not faulty (or that you are not using an emulator ;-) > All hardware performance gains are > destroyed systematically by people like you. > > WHO CARES? Certainly, not my customers. > Nobody. This increases consumption (I need > 512MB RAM), and reduces mental effort of the > developers. Who needs anything > else? The cost of 512 MB RAM amounts for a few hours work of a poorly paid programmer in Europe. No much more time on most countries. > Why care if the application takes 4MB or > 2MB? Who cares if the cost of the application is 10,000 euro or 30,000 euro? > The IDE of lcc-win32 is 750K. This > includes: Ah! so you are trying to advertise something! > o editor with syntax coloring > o project generation and make > o full windowed debugger > o versioning system > o software metrics module > o syntax analyzer in real time > > This just can't be done with any other > compiler around. What? The 750KB requirement? Congratulations! I won't use lcc, though. > I suspect that the problem is not only dead > code elimination. Several years ago I spotted > a bug in gcc that increased the code bloat > with unnecessary instructions by 10-15%. But it was a bug, wasn't it? Have you reported it? > I think I will look again at that > compiler. lcc? Have fun! -- Oscar |
|
From: jacob n. <ja...@ja...> - 2003-12-08 18:40:54
|
----- Original Message -----
From: "Oscar Fuentes" <of...@wa...>
To: <min...@li...>
Sent: Monday, December 08, 2003 6:22 PM
Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 generated
binary !!!
> > That is why my new AMD64 processor with 512
> > MB of RAM uses up 380 MB at startup, with a
> > single shell and the explorer running. Yes,
> > I have to buy yet another 512MB RAM to be able
> > to start the compiler. Yes, the
> > compiler.
>
> You doubled the word size, so an increase is natural. However, I'm
> pretty sure you are exaggerating things here.
>
Yes. I logged off administrator and restarted.
After I log on again, I start the task manager. It reports 277MB used only,
(not 380), with a "cmd" shell running and NOTHING ELSE.
I was confusing with windows advanced server 2003/64 bits.
Sorry. This system is the windows XP 64 bits.
But behind this figures is the whole concept of work well done,
of making things as efficient as they can be. Yes, your customers
do not care about your application taking 2MB or 20MB. Go ahead
then.
> > WHO CARES?
>
> Certainly, not my customers.
>
Then, just go on. Give them a 40MB executable, with 1GIG
memory requirements. Why stop at just 2MB?
> > Nobody. This increases consumption (I need
> > 512MB RAM), and reduces mental effort of the
> > developers. Who needs anything
> > else?
>
> The cost of 512 MB RAM amounts for a few hours work of a poorly paid
> programmer in Europe. No much more time on most countries.
>
No, because my motherboard will not go beyond some gigs.
> > Why care if the application takes 4MB or
> > 2MB?
>
> Who cares if the cost of the application is 10,000 euro or 30,000 euro?
>
Are you saying that a more efficient compiler would increase the
cost of the application?
A bug is a bug, even if you say it doesn't matter.
> What? The 750KB requirement? Congratulations! I won't use lcc, though.
Obviously, given that you prefer bloated software :-)
>
> > I suspect that the problem is not only dead
> > code elimination. Several years ago I spotted
> > a bug in gcc that increased the code bloat
> > with unnecessary instructions by 10-15%.
>
> But it was a bug, wasn't it? Have you reported it?
>
Yes, I reported it and they fixed it in the next release. The optimizer was
spewing sequences like
add $16,%esp
sub $16,%esp
or similar nonsense to keep the esp register 16 byte aligned for
floating point, even if no floating point was ever used. The faulty
stack alignment code added 10% to code size and slowed down
gcc to the same speed of lcc-win32. I was very happy of course, but
reported the bug nevertheless. The next version they got rid of it
and gcc was still slightly faster than lcc.
> > I think I will look again at that
> > compiler.
>
Gcc, of course. I will look at the offsets in indexed addressing, and in
general at the generated code.
|
|
From: Bert D. <be...@be...> - 2003-12-08 22:37:50
|
I would be interested in the one with the best documentation, and =
the best features. But then again, I have DSL connection and 1 gig of =
memory.=20
There are times when it is worthwhile to shrink code to minimum =
size. I have done this for flash-memory systems. But for most typical =
pc applications, your time would be better spent on other tasks
This is the mentality of software progress.
That is why my new AMD64 processor with 512 MB of RAM uses up 380 MB =
at startup, with a
single shell and the explorer running. Yes, I have to buy yet another =
512MB RAM to be able
to start the compiler. Yes, the compiler.
Life is short. There are only so many things I can pay attention to. =
You have to decide what you think is most important.
I used to spend a lot of time optimizing cycle counts and byte counts. =
It never paid off. It just took a lot of trouble and effort and made my =
source code messier. And when the next generation cpu/compiler comes =
along, you have to do it all over again.
Now I focus on keeping my source code clean and on algorithmic =
efficiencies, like using O(1) algorithms instead of O(n^2).
Optimizations that have an effect less than a factor of 10 are probably =
not worth worrying about. As Knuth said, "Premature optimization is the =
root of all error." I never optimize anything anymore until after the =
user/customer complains. And then I do focused, goal-directed =
optimization based on profiling.
|
|
From: Miroslav F. <cx...@nt...> - 2003-12-09 09:00:46
|
I think that what you fail to understand is that it is not YOU who =
should pay the attention. It is compiler / linker that should do the =
job.
It is like you would suggest that GCC team difinitely should not spent =
their time working on optimization - given your ideas, -O0 is good for =
everybody. And if it is slow, buy faster machine.
Mirek
----- Original Message -----=20
From: Bert Douglas=20
To: min...@li...=20
Sent: Monday, December 08, 2003 11:37 PM
Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 =
generated binary !!!
I would be interested in the one with the best documentation, and =
the best features. But then again, I have DSL connection and 1 gig of =
memory.=20
There are times when it is worthwhile to shrink code to minimum =
size. I have done this for flash-memory systems. But for most typical =
pc applications, your time would be better spent on other tasks
This is the mentality of software progress.
That is why my new AMD64 processor with 512 MB of RAM uses up 380 MB =
at startup, with a
single shell and the explorer running. Yes, I have to buy yet =
another 512MB RAM to be able
to start the compiler. Yes, the compiler.
Life is short. There are only so many things I can pay attention to. =
You have to decide what you think is most important.
I used to spend a lot of time optimizing cycle counts and byte counts. =
It never paid off. It just took a lot of trouble and effort and made =
my source code messier. And when the next generation cpu/compiler comes =
along, you have to do it all over again.
Now I focus on keeping my source code clean and on algorithmic =
efficiencies, like using O(1) algorithms instead of O(n^2).
Optimizations that have an effect less than a factor of 10 are =
probably not worth worrying about. As Knuth said, "Premature =
optimization is the root of all error." I never optimize anything =
anymore until after the user/customer complains. And then I do focused, =
goal-directed optimization based on profiling.
|
|
From: Don H. <do...@al...> - 2003-12-09 01:00:31
|
Yes it is really significant. 2 essential creterias for a compile : the size of generated code and its = execution speed. Do you agree? Don HO Je bouffe donc je suis Find a powerful free (and open source) multi-function editor at http://notepad-plus.sourceforge.net/ ----- Original Message -----=20 From: Bert Douglas=20 To: min...@li...=20 Sent: Monday, December 08, 2003 10:20 AM Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 = generated binary !!! How much memory do you have in your computer? Is this really = significant? ----- Original Message -----=20 From: Miroslav Fidler=20 To: min...@li...=20 Sent: Monday, December 08, 2003 3:15 AM Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 = generated binary !!! > Is there a remedy for that? > 160 KB (497 KB vs 340 KB) is really huge! Right now not. LD/Win32 would need to support --gc-sections = switch - that would probably solve the problem. Unfortunately, this option = seems to be unsupported now. Mirek ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for = IBM's Free Linux Tutorials. Learn everything from the bash shell to sys = admin. Click now! = http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick _______________________________________________ MinGW-users mailing list Min...@li... You may change your MinGW Account Options or unsubscribe at: https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
From: Greg C. <chi...@mi...> - 2003-12-09 04:07:44
|
"Don HO" <do...@al...> wrote: > > the binary file generated by MinGW + GCC is mach bigger than > the one generated by VC++ 7 (492 KB vs 340 KB) [...] > 2 essential creterias for a compile : the size of generated code > and its execution speed. Do you agree? There are many criteria. Some are readily quantifiable: (1) correctness of generated code (2) conformity to the language standard (3) execution speed (4) compilation and linking speed (5) size of final binary while others are less so: (a) license (b) quality of diagnostics (c) cost (d) quality of available support I've sorted each group in order of importance to me, though others might rank them differently or have additional criteria such as - portability to other platforms - integration with an IDE - compatibility with other tools - support for 80-bit long double For me, mingw gcc is strong on (1), (2), (3), and (a), and that's why I use it, even though it's weak on (4) and (5) if you use templates extensively. The size of the final binary is probably some constant for runtime library overhead, plus some function of code complexity, adjusted for the linker's efficiency e.g. in removing duplicate template instances. Here, I suspect you're measuring the constant, which becomes less important as complexity increases. Others who consider binary size important but write large programs may care little about the constant. |
|
From: Don H. <do...@al...> - 2003-12-10 00:43:34
|
Faire enough, Greg. Don HO Je bouffe donc je suis Find a powerful free (and open source) multi-function editor at http://notepad-plus.sourceforge.net/ ----- Original Message ----- From: "Greg Chicares" <chi...@mi...> To: <min...@li...> Sent: Tuesday, December 09, 2003 5:08 AM Subject: Re: [Mingw-users] Generated Binary is BIGGER than VC++ 7 generated binary !!! > "Don HO" <do...@al...> wrote: > > > > the binary file generated by MinGW + GCC is mach bigger than > > the one generated by VC++ 7 (492 KB vs 340 KB) > [...] > > 2 essential creterias for a compile : the size of generated code > > and its execution speed. Do you agree? > > There are many criteria. Some are readily quantifiable: > (1) correctness of generated code > (2) conformity to the language standard > (3) execution speed > (4) compilation and linking speed > (5) size of final binary > while others are less so: > (a) license > (b) quality of diagnostics > (c) cost > (d) quality of available support > > I've sorted each group in order of importance to me, > though others might rank them differently or have > additional criteria such as > - portability to other platforms > - integration with an IDE > - compatibility with other tools > - support for 80-bit long double > > For me, mingw gcc is strong on (1), (2), (3), and (a), > and that's why I use it, even though it's weak on (4) > and (5) if you use templates extensively. > > The size of the final binary is probably some constant > for runtime library overhead, plus some function of > code complexity, adjusted for the linker's efficiency > e.g. in removing duplicate template instances. Here, > I suspect you're measuring the constant, which becomes > less important as complexity increases. Others who > consider binary size important but write large programs > may care little about the constant. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
|
From: Alvin T. <al...@th...> - 2003-12-09 16:00:07
|
On Mon, 2003-12-08 at 20:00, Don HO wrote: > Yes it is really significant. > 2 essential creterias for a compile : the size of generated code and > its execution speed. > Do you agree? then perhaps you should do a more appropriate test? like checking compile size/speed of a program of a more realistic size/scope? saying that some one-line program differs in size by a few k isn't really saying anything. in addition, since your code is so small it's negligible, you may well be testing how efficiently the MinGW libraries are written instead of how efficiently the compiler compiles (at least as far as speed is concerned, if not size as well)... if you're really interested in making an evaluation worth reading and not cluttering my inbox with drivel, you will need to analyze the generated assembly code from both compilers. just a (half-baked) thought, alvin |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X