24-core CPU and I can’t move my mouse

Post by hinkley » Mon, Jul 10, 2017, 4:13 PM UTC

andrepd wrote: post #193

mpweiher wrote: post #105

Earlier quoted context omitted.

> Damn, are we doing this wrong? Yes, and I mean "we" as in "this industry". I just recently talked to someone whose Swift framework(s) were compiling at roughly 16 lines per second. Spurred on by Jonathan Blow's musings on compile times for Jai[1], I started tinkering with tcc a little. It compiled a generated 200KLOC file (lots of small functions) in around 200 ms. Then there are Smalltalk and Lisp systems that are…

Are you serious? You want to make a product: a Web browser. What technology are you going to choose? The one that makes your browser fast but gives you more work, or the one that makes your browser slower but makes compilation less of a nuisance to you ? It's mind boggling that some would openly say that, hey, who cares about performance that much, these compilation times bother me, the developer. On a browser of all…

Post by pjmlp » Mon, Jul 10, 2017, 4:16 PM UTC

bonzini wrote: post #110

rurban wrote: post #97

Earlier quoted context omitted.

just use zapcc, and compile-time will be down. it's basically clang-4.0 so it's safe to use.

If it's basically clang 4.0, why is it not part of clang? Projects like zapcc remind me of why the GPL is a good thing. (I predict that in 10 years all the various soft cores will be variants of RISC-V each with its own old, unmaintained and proprietary fork of LLVM).

Post by deong » Mon, Jul 10, 2017, 4:16 PM UTC

phaedrus wrote: post #298

titzer wrote: post #45

Full disclosure: I work for Google on Chrome. A Chrome build is truly a computational load to be reckoned with. Without the distributed build, a from-scratch build of Chrome will take at least 30 minutes on a Macbook Pro--maybe an hour(!). TBH I don't remember toughing out a full build without resorting to goma. Even on a hefty workstation, a full build is a go-for-lunch kind of interruption. It will absolutely own a…

Yes, you're doing it wrong. The trick is you've got to reduce your "saturation level" of #includes in header files, by preferring forward declarations over #includes, and using the PIMPL pattern to move your classes' implementations into isolated files, so that transitive dependencies of dependencies don't all get recursively #included in. When it comes to templates, one has to be very aggressive in asking "Does this…

Post by naasking » Mon, Jul 10, 2017, 4:18 PM UTC

captainmuon wrote: post #342

titzer wrote: post #45

Full disclosure: I work for Google on Chrome. A Chrome build is truly a computational load to be reckoned with. Without the distributed build, a from-scratch build of Chrome will take at least 30 minutes on a Macbook Pro--maybe an hour(!). TBH I don't remember toughing out a full build without resorting to goma. Even on a hefty workstation, a full build is a go-for-lunch kind of interruption. It will absolutely own a…

Could it be that we are doing the web browser wrong? I think large parts of chrome actually belong into the OS. The network parts, the drawing library (skia), the crypto implementation, the window and tab management, and so on. The javascript engine could be factored out, too, so more apps could benefit from it (without bundling a whole frickin Chromium). Video and audio would be deferred to DirectShow, Quartz, VLC,…

Post by wglb » Mon, Jul 10, 2017, 4:19 PM UTC

vidarh wrote: post #119

lucian1900 wrote: post #93

Earlier quoted context omitted.

Unfortunately that's not feasible for highly performance-sensitive projects like browsers or games.

It absolutely is. If most of your time is spent on calls traversing large portions of a code-base that size, then you have a far bigger problem in that you'll be blowing your cache all the time. Fix that problem, and you're halfway there to creating better separated modules that can be encapsulated the way I described.