Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
|
|
10-27-2024, 12:50 PM
|
#16
|
Senior Member
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 1,038
Original Poster
|
I was citing kicad as an example. I switched my programs to Meson and Ninja a few years ago.
Here is what I have found:
-ftime-report tells me that "phase opt and generate" and "callgraph functions expansion" are taking disproportionately long on large files.
g++ and clang++ are within 20% of each other on compilation times, and within 10% of each other on run times. I suspect that both projects benchmark themselves against the other.
The compilation time difference between -O1 and -O3 is about 2x.
A build script needed little less serialization (15% improvement).
Ed
|
|
|
10-28-2024, 03:57 AM
|
#17
|
LQ Addict
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 23,009
|
Quote:
Originally Posted by EdGr
I was citing kicad as an example. I switched my programs to Meson and Ninja a few years ago.
Here is what I have found:
-ftime-report tells me that "phase opt and generate" and "callgraph functions expansion" are taking disproportionately long on large files.
g++ and clang++ are within 20% of each other on compilation times, and within 10% of each other on run times. I suspect that both projects benchmark themselves against the other.
The compilation time difference between -O1 and -O3 is about 2x.
A build script needed little less serialization (15% improvement).
Ed
|
It is still nonsense. You need to check more than one software, not only kicad.
-O is the optimization, the time difference again is not 2x, but depends on the code itself. Some codes can be better optimized, some others cannot.
What is the goal of this rash generalization?
Last edited by pan64; 10-28-2024 at 10:13 AM.
|
|
|
10-28-2024, 09:14 AM
|
#18
|
Senior Member
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 1,038
Original Poster
|
pan64 - You are on my ignore list.
I came up with a workaround.
Normally, when shared libraries are built and installed, all dependent programs need to be rebuilt.
However, in the special case of the library headers not being changed, the rebuild of dependent programs can be omitted. This is often true for the edit-compile-run cycle on libraries.
Ed
|
|
|
10-28-2024, 10:25 AM
|
#19
|
LQ Addict
Registered: Mar 2012
Location: Hungary
Distribution: debian/ubuntu/suse ...
Posts: 23,009
|
Quote:
Originally Posted by EdGr
pan64 - You are on my ignore list.
|
It is your problem, not mine.
Quote:
Originally Posted by EdGr
I came up with a workaround.
|
Workaround for what?
Quote:
Originally Posted by EdGr
Normally, when shared libraries are built and installed, all dependent programs need to be rebuilt.
However, in the special case of the library headers not being changed, the rebuild of dependent programs can be omitted. This is often true for the edit-compile-run cycle on libraries.
Ed
|
This is how c/c++ works. We have internal headers and external headers (sometimes called interfaces). If those interfaces are changed all the dependent apps should be recompiled. These are usually functional changes. If they remain intact the shared object can be replaced without any issue. These are usually bug fixes. Build systems can handle both cases automatically.
|
|
|
11-06-2024, 06:13 PM
|
#20
|
Member
Registered: Dec 2020
Location: South Australia
Distribution: slackware64-current
Posts: 97
Rep:
|
Looks about right to me. I have a gentoo machine so end up compiling a lot of C++ applications and libraries and they take considerably longer than any C ones, the only thing worse is anything rust. It just takes orders of magnitude more cpu cycles and memory compared to C to compile, that's a simple fact.
C++ despite it's name and some shared syntax is a completely different language to C - it's not even a very good super-set, it's trivial to create simple valid C programmes that aren't C++ (the 'extern "c"' thing just sets the ABI). Toy examples that are only using the C-like part of the language are not representative of the features of C++ that are used exhaustively by C++ programmers. Just look at how much longer and (much) more memory gcc itself took to compile after they moved the codebase to C++, and that uses C++ features quite frugally for exactly this reason.
The biggest culprit is templates, defining them and parsing them is a messy big task, resolving them up is a big search task, expanding them is a big task, tracking them (for debug or symbols) is a huge task. Even optimisation passes become slower (albeit potentially more effective) simply because there's more code and context to optimise. C has a bad enough problem compared to some other languages (e.g. Java, python) of header files needing to be compiled and recompiled many times in a given application, C++ only makes this problem considerably worse. And all of the complex and the obscure features encourage otherwise smart people to waste so much of their time on perfecting rather than producing, only magnified by the slow compilation times.
Can't stand it myself and think it's a pretty poor language[1], but fortunately in 25 years of being a Computer Systems Engineer I've barely had to touch it other than compiling applications and interfacing to some libraries.
[1] https://en.wikipedia.org/wiki/Criticism_of_C%2B%2B
|
|
1 members found this post helpful.
|
11-07-2024, 02:53 AM
|
#21
|
Senior Member
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 1,038
Original Poster
|
notzed - It is good to hear from someone with similar experience.
I prefer C++ because well-written C++ code is clearer and more robust than C. However, poorly-written C++ can take the obfuscated code contest to the next level. C++ features must be used selectively.
I looked into ccache as another way to speed up compilation. It addresses the problem that generated headers trigger rebuilds even if nothing had changed. I think that manually building the packages being debugged is the right amount of workaround.
Ed
|
|
|
11-07-2024, 08:32 PM
|
#22
|
LQ Guru
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,933
|
Perhaps diverting this conversation, but – the "C++" language has "evolved considerably" over these many years, and not necessarily in a "good" way.
The "templates" system is unfortunately a prime example. In my view, "the farther away 'the source-code directly in front of you' strays away from 'what is ultimately going to happen' – and your certainty of what that will be – the more the language fails to serve your actual needs. You shouldn't be questioning nor fighting against your tool, no matter how "kewel" somebody somewhere thought that the new "fee-chur" would be. The "C++" language today is anything but "stable" between one language-release to the next. And, today, I would hate to be forced to be a "compiler implementor."
When I write in the language today, I very purposely avoid as many "modern-day 'fee-churs'" as possible. And yet, I still get work done. My mantra is that stuff should be: "stupid simple." (Because: much of the source-code that I myself wrote is, today, "the work of a complete stranger." Only my "copious comments" enable me to understand it.)
Long ago someone actually constructed a "programming language" called (I think ...) WADUZITDO? (Oh, wait: it still has a website!!) Well, I simply think that, whenever someone looks at a piece of production source-code, they should never have to ask themselves that question. Unfortunately, I opine that they very often do.
Last edited by sundialsvcs; 11-07-2024 at 08:42 PM.
|
|
|
Yesterday, 10:00 AM
|
#23
|
Senior Member
Registered: Dec 2010
Location: California, USA
Distribution: I run my own OS
Posts: 1,038
Original Poster
|
We have talked about C++'s feature creep.
I use C++98 because code does not rewrite itself, and tracking language revisions is not on my list of important problems to solve.
Ed
|
|
|
All times are GMT -5. The time now is 10:07 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|