| |||||||||||||
Day: GNOME OSDay: GNOME OSPosted Aug 8, 2012 17:59 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)In reply to: Day: GNOME OS by juliank Parent article: Day: GNOME OS
libstdc++ ABI is being addressed. It's already backwards-compatible, but not very developer-friendly for the new code.
Build time of QT-based software is not significantly greater than GTK-based software.
(Log in to post comments)
Day: GNOME OS Posted Aug 8, 2012 23:29 UTC (Wed) by Company (guest, #57006) [Link]
I am sorry?
C++ compilers are orders of magnitude slower and more memory-intensive than C compilers.
http://www.phoronix.com/scan.php?page=news_item&px=MT... builds Linux in less than 1 minute on a single core. A Firefox (which is less code size) build according to Firefox's build farm at https://tbpl.mozilla.org/ takes from slightly less than an hour to 2 hours.
Day: GNOME OS Posted Aug 9, 2012 0:05 UTC (Thu) by hummassa (subscriber, #307) [Link]
You just compared "You can run 5 km in two minutes in a Ferrari, but it takes more than one hour to run 30 km in a bycicle!"
Day: GNOME OS Posted Aug 9, 2012 2:37 UTC (Thu) by Company (guest, #57006) [Link]
I'm not sure how you got to that comparison, but I'm waiting for you to prove me wrong. Go ahead.
Day: GNOME OS Posted Aug 9, 2012 2:46 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
First, that's not single *core*, but *socket* for the kernel build. Second, it's a $1050 processor. That's the Ferrari. I couldn't see what the build farm was using, but it's not /that/ good.
Better would be to compare Koji's build times for the packages (though you'll need to factor out the root.log time due to different dependencies). Bonus points for getting builds from the same host at low load.
Day: GNOME OS Posted Aug 9, 2012 3:04 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
The build farm is also running tests which I can imagine taking a long time. In fact, looking at the logs, they're using ccache which tells me that its 60 to 120 minutes of running tests which is more than the kernel can say.
Basically, your comparison is: "more" C is compiled by a top-of-the-line CPU in one minute than some random build farm hardware can test "less" C++ code. Never mind that the build farm builds also start by doing lots of PyPI installs (mostly cached) whereas the kernel build goes straight to building stuff.
Day: GNOME OS Posted Aug 9, 2012 21:05 UTC (Thu) by ibukanov (subscriber, #3942) [Link]
Build farm is slow. On a 4-core Linux desktop (Core i5-2400 CPU @ 3.10GHz) Firefox builds in about 15-20 minutes depending on the build configuration. But I second the observation that extensive use of c++ makes things much slower.
SpiderMoneky, the JavaScript engine in Firefox, used to be written in C. The compilation of JS shell (that compiled only the engine without any other Firefox code) to test changes to the engine was fast. It was possible to develop it even on a netbook as the shell compiled under a minute there. Then the code switched to C++ and the build time deteriorated as more and more C++ features started to be used. In a less than a year one could forget to use netbook for any productive development and even using not the latest and greatest notebooks became problematic.
Day: GNOME OS Posted Aug 9, 2012 23:48 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
I agree that C++ is slower to compile, but as I said elsewhere:
> As for build times, yes, it's higher, but I don't really notice that much of a practical difference and what difference there is is well worth the extra safety the code has.
Unfortunately, a fair comparison can't be made without ensuring at least feature parity between the C and C++. You also have to compare bug counts and code ease-of-use (for users of the code/APIs, developers, and maintainers) and in this, C++ is a big win IMO.
The C++ SpiderMonkey has more features today than it used to have (I expect) and you have to weigh how long it took to code those features versus how long it would have taken with the C codebase to get the same features against the increased build times.
As for using a netbook, I don't know what my limits for patience would be anymore. After using my i7 and Xeon machines at work, even my Core 2 Duo was getting me impatient with builds. I don't do much beyond script-level stuff (usually Haskell, shell, or Python) or minor web development on the netbook anymore mainly due to the tiny screen (my terminals at work are 319 wide and 88 tall and netbooks just don't fit 3 80-wide Vim windows plus NERDTree on them at readable font sizes).
Day: GNOME OS Posted Aug 10, 2012 10:38 UTC (Fri) by jwakely (subscriber, #60262) [Link]
A large part of slower C++ build times is in the linker, not just the compiler. Using Gold makes a big difference.
Day: GNOME OS Posted Aug 10, 2012 20:05 UTC (Fri) by ibukanov (subscriber, #3942) [Link]
Surely C++ brought a lot of nice things like templates and destructors for automated cleanup significantly simplifying the code in SpiderMonkey. However, a significant compilation time increase also meant that hardware that developers use is way beyond capabilities of the most computers where Firefox runs. So it is much harder to extrapolate the effect of changes that looks nice on fastest CPU during development to the hardware that users will face.
|
|||||||||||||