From: Dimitry K. <dim...@gm...> - 2006-08-26 19:14:58
|
Hello, I have a large project that is built as a set of static libraries. At the very end of the build, all the libraries are linked with the main module to construct the final executable. This last step takes very large amount of time. Is it possible to speed-up that last stage? Would turning all the static libs into dlls, be better? I am running gcc 3.4.2 and ld 2.15.91. Thanks -- Dima |
From: Michael G. <mg...@te...> - 2006-08-26 19:53:31
|
> I have a large project that is built as a set of static libraries. > At the very end of the build, all the libraries are linked with > the main module to construct the final executable. This last step > takes very large amount of time. Is it possible to speed-up that > last stage? Would turning all the static libs into dlls, be better? > I am running gcc 3.4.2 and ld 2.15.91. Newer version of binutils (which ls is part of) do provide better algorithms. Check the archive for details. I'd suggest using binutils-2.16.91 or even 2.17.50 (both of which I have used for production code for a really long time now). Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Michael G. <mg...@te...> - 2006-08-26 19:57:03
|
Of course this should have been > Newer version of binutils (which ls is part of) do provide better =2D----------------------------------^^ (which ld is part of) -- in case the typo wasn't obvious anyway. Best, Michael =2D-=20 Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: <cx...@nt...> - 2006-08-29 08:20:43
|
Tomas Rylek of U++ team developed mingw/ld-ar drop-in replacements, which are significantly faster (about 10 times) and implements dead section removal (-> smaller executable). You can download it at upp.sf.net, package "uldar". Mirek Dimitry Kloper wrote: > Hello, > > I have a large project that is built as a set of static libraries. > At the very end of the build, all the libraries are linked with > the main module to construct the final executable. This last step > takes very large amount of time. Is it possible to speed-up that > last stage? Would turning all the static libs into dlls, be better? > I am running gcc 3.4.2 and ld 2.15.91. > > Thanks > -- > Dima > >------------------------------------------------------------------------ > >------------------------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > >------------------------------------------------------------------------ > >_______________________________________________ >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...> - 2006-08-29 11:55:43
|
Quoting Mirek F=EDdler <cx...@nt...>: > Tomas Rylek of U++ team developed mingw/ld-ar drop-in replacements, > which are significantly faster (about 10 times) and implements dead > section removal (-> smaller executable). > How does this advertisement answer the OP question? I gave your ld drop-in a go once and it didn't understand the switches so it wasn't really a drop in. You are off-topic and are being asked to not advertise here. Earnie Boyd http://shop.siebunlimited.com |
From: Keith M. <kei...@to...> - 2006-08-29 11:57:23
|
Mirek Fidler wrote: > Tomas Rylek of U++ team developed mingw/ld-ar drop-in replacements, > which are significantly faster (about 10 times) and implements dead > section removal (-> smaller executable). How do they stack up against our own binutils-2.17 implementations? AIUI these are also significantly faster than earlier incarnations. Regards, Keith. |
From: <cx...@nt...> - 2006-08-29 12:57:33
|
OK. Downloaded 2.17.50 for benchmarks. Test project consists of 163 .cpp files (U++ Puzzle example). U++ linker takes 1.14s to link debug version, 0.56s to link release version with executable size 1392640 bytes. 2.17.50 mingw/ld takes 5.37s to link debug version, 1.17s to link release version with executable size 1724416 bytes. Test procedure: I have taken our "production" mingw directory tree, created identical copy and replaced our ld.exe and ar.exe with those from binutils. Then created new build method with this mingw tree, build the application using TheIDE and both methods. Tested on socket 754 AMD64 CPU @2.4Ghz / 1GB RAM. To Earnie Boyd: I think you are overreacting. We do not sell U++/ld.exe, it is BSD licensed software, part of sf.net project, available with complete sources. Original poster complained about mingw/ld speed. U++/uld might or might not help him. U++/ld might not support all options of mingw/ld, but it most likely supports enough to solve his problem (static link). Moreover, if there is enough interest, we can add missing options. Now tell me what exactly is off-topic here.... Mirek Keith MARSHALL wrote: >Mirek Fidler wrote: > > >>Tomas Rylek of U++ team developed mingw/ld-ar drop-in replacements, >>which are significantly faster (about 10 times) and implements dead >>section removal (-> smaller executable). >> >> > >How do they stack up against our own binutils-2.17 implementations? >AIUI these are also significantly faster than earlier incarnations. > >Regards, >Keith. > >------------------------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >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: Keith M. <kei...@to...> - 2006-08-29 14:28:19
|
Mirek F=EDdler wrote: > To Earnie Boyd: > I think you are overreacting. We do not sell U++/ld.exe, it is BSD=20 > licensed software, part of sf.net project, available with complete > sources. > > Original poster complained about mingw/ld speed. U++/uld might or > might not help him. U++/ld might not support all options of mingw/ld, > but it most likely supports enough to solve his problem (static link).=20 > Moreover, if there is enough interest, we can add missing options. Well, you can't realisticly expect us to condone advertising of a competing product, on *our* mailing list, regardless of whether it is commercial or FLOSS. Moreover, if it doesn't fully support *all* the features of our own product, as it stands *today*, then your advert was misleading, for you claimed it to be a `drop-in replacement', which it clearly is not. Earnie has asked you to desist from advertising this competing product on our mailing list. As co-administrator, I fully support him in that request. If you believe that you know any techniques for improving the performance of any official MinGW tool, then please contribute patches, rather that tout competing alternatives. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-08-30 13:20:31
|
Quoting Mirek F=EDdler <cx...@nt...>: > To Earnie Boyd: > > I think you are overreacting. We do not sell U++/ld.exe, it is BSD > licensed software, part of sf.net project, available with complete source= s. > Keith has already responded to this rant. > Original poster complained about mingw/ld speed. U++/uld might or might > not help him. U++/ld might not support all options of mingw/ld, but it > most likely supports enough to solve his problem (static link). > Moreover, if there is enough interest, we can add missing options. > The OP was asking for help because his ld wasn't finding crt2.o. Clearly an indication of an environment issue. > Now tell me what exactly is off-topic here.... > You didn't help the OP to resolve his issue and your intent was clearly one to promote your product. You even said that it was a "drop-in replacement" which may be the eventual intention but it isn't yet and therefore a miscommunication to the user and causes even more frustration on the part of the person having issues. Both Keith and I have now asked that you not promote this product as a resolution to issues with MinGW. Earnie Boyd http://shop.siebunlimited.com |
From: <cx...@nt...> - 2006-08-30 17:05:53
|
>>Original poster complained about mingw/ld speed. U++/uld might or might >>not help him. U++/ld might not support all options of mingw/ld, but it >>most likely supports enough to solve his problem (static link). >>Moreover, if there is enough interest, we can add missing options. >> >> >> > >The OP was asking for help because his ld wasn't finding crt2.o. >Clearly an indication of an environment issue. > > Well, that might explain the overreaction. The OP massage did not mentioned crt2.o: "I have a large project that is built as a set of static libraries. At the very end of the build, all the libraries are linked with the main module to construct the final executable. This last step takes very large amount of time. Is it possible to speed-up that last stage? Would turning all the static libs into dlls, be better? I am running gcc 3.4.2 and ld 2.15.91. Anyway, sorry for upsetting you. Next time I will use direct email. I thought you are doing this (working on FOSS) to help users. I do. I just noticed somebody has problem we had to solve (because ld.exe speed was unacceptable for U++ users), so I tried to help. I promise not to do it again this way. Have a good time, Mirek |
From: Earnie B. <ea...@us...> - 2006-08-30 18:37:34
|
Quoting Mirek F=EDdler <cx...@nt...>: > > Well, that might explain the overreaction. The OP massage did not > mentioned crt2.o: > Oh, sorry, I was thinking we were in a different thread. > "I have a large project that is built as a set of static libraries. > At the very end of the build, all the libraries are linked with > the main module to construct the final executable. This last step > takes very large amount of time. Is it possible to speed-up that > last stage? Would turning all the static libs into dlls, be better? > I am running gcc 3.4.2 and ld 2.15.91. > Patches to binutils for speed improvement would be a more appropriate method of helping MinGW users. > Anyway, sorry for upsetting you. Next time I will use direct email. > Do not SPAM the MinGW users privately either. If I hear that you do I will ask SF for help in stopping you. > I thought you are doing this (working on FOSS) to help users. I do. I > just noticed somebody has problem we had to solve (because ld.exe speed > was unacceptable for U++ users), so I tried to help. I promise not to do > it again this way. > Actually, I'm in this for my benefit; helping others is just happens because I'm a nice guy. ;) However, I do not go promoting my projects in others groups. It is really bad taste and causes the users confusion. > Have a good time, > I usually do. Earnie Boyd http://shop.siebunlimited.com |
From: <cx...@nt...> - 2006-08-30 19:04:38
|
>Patches to binutils for speed improvement would be a more appropriate >method of helping MinGW users. > > I wish that would be possible, unfortunately it is not, unless you are able to force scratching current binutils C implementation and replacing it with C++ implementation using fast container libraries. Even if that would be possible, somebody else would have to be responsible, right now this is out of our focus (problem is solved for us). >>Anyway, sorry for upsetting you. Next time I will use direct email. >> >> >> > >Do not SPAM the MinGW users privately either. If I hear that you do I will ask SF for help in stopping you. > > > Actually, I am barely reading this mailing list. Did not reacted to anything in last 2 years. Just accidentaly noticed ask for help that could be very likely satisfied. Anyway, be sure that if I will feel to contact anybody on this mailing list by email, I will simply do it. Ask for help whomever you want. Sending email is not spaming. >However, I do not go promoting my projects >in others groups. It is really bad taste and causes the users >confusion. > > I am sorry, after spending time in our forum, I am just used to different kind of attitude. People are regulary suggesting other options on our forum. If somebody suggest solution that he claims to be superior to ours, we carefuly investigate it and if claims are proved, we try to adapt or improve ours to match it. Actually, if you would come there and suggested some faster compiler to ship with our package, you would be very welcome :) (We can reimplement ld, but the compiler itself is a little bit too much work to be done.) Regards, Mirek |