Slashdot Mirror
Chrome On Windows Ditches Microsoft's Compiler, Now Uses Clang (arstechnica.com)
An anonymous reader quotes a report from Ars Technica: Google's Chrome browser is now built using the Clang compiler on Windows. Previously built using the Microsoft C++ compiler, Google is now using the same compiler for Windows, macOS, Linux, and Android, and the switch makes Chrome arguably the first major software project to use Clang on Windows. Chrome on macOS and Linux has long been built using the Clang compiler and the LLVM toolchain. The open-source compiler is the compiler of choice on macOS, making it the natural option there, and it's also a first-class choice for Linux; though the venerable GCC is still the primary compiler choice on Linux, by using Clang instead, Google ensured that it has only one set of compiler quirks and oddities to work with rather than two. But Chrome on Windows has instead used Microsoft's Visual C++ compiler. The Visual C++ compiler is the best-supported, most widely used compiler on Windows and, critically, is the compiler with the best support for Windows' wide range of debugging and diagnostic tools. The Visual Studio debugger is widely loved by the C++ community, and other tools, such as the WinDbg debugger (often used for analyzing crash dumps), are core parts of the Windows developer experience.
So that's why Chrome's taking up 2GB or RAM and always running at 30% CPU?
Because the GNU folks screwed themselves over with their pompous, obstructive, anti-technical-excellent zealotry. They've since changed their ways a bit, but it's too late. People want freedom not "Freedom".
Being that Google Chrome is in a constant speed race with Edge and Firefox all trying to be the fastest full featured browser out there. These guys need every advantage they can get to inch out on the benchmarks to claim they are the fastest. The general rule of thumb is tools made to run on many platforms tend to run more slowly then tools made for a particular platform.
Is Google going to stop in the benchmark war? Is CLang optimized enough for windows platforms to allow time saved in compiler compatibility to be used in better speed algorithms. Is CLang objectively equal or better then Visual C++ (As Microsoft sometimes sacrifices performance, for legacy support that Chrome may not be worried about)
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Yes.
Otherwise I will always recommend using more than one compiler to help standardize the code.
Of course, when you have automatic CI it sucks also having to have Windows build servers and not just Unix, depending on your build system. You still need Windows test machines for automated testing, though.
They probably want to have a more consistent build environment to reduce the impact of compiler bugs and differences in standard support. Also, automatic test suites are likely cheaper to build and run with Clang than with any commercial compiler. This should make the Chrome Experience(tm) more consistent across the platforms in terms of speed as well.
Commercial software is written for profit; the programmers don't do shit to improve it unless there's a paying customer.
In contrast, open-source programs are written largely by people who are trying to scratch their own itches, including performance itches.
Good luck re-programming Microsoft Edge when you're unhappy with its performance.
Just guessing here, but I doubt the compiler makes any difference to speed whatsoever. Why? Because modern javascript browsers are just-in-time compiling the javascript into native code. So the native code is 2 levels removed from the C++, and the code your compiler generated.
http://blog.llvm.org/2018/03/c...
I read LLVM Project Blog; I think it said it was done partly for code maintenance issues. As, in it should be faster to add patches for Windows using the same Compiler over all platforms.
Note: They are still using Microsoft linker.
Tim S.
Does Clang support Windows SEH (a proprietary feature of Windows NT)? I have to admit I don't see that used very often, but I bet they use it all the time in Redmond.
Google is using inline asm for those parts where CLang is falling behind, so it's not an issue.
Sounds like some kind of Klingon name.
Why would a tool that emits x86 code on macOS do anything different on windows/x86?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Not on debian -- chrome only updates when i run apt-get update. just like everything else. Why give any program permission to overwrite itself?
Open source projects like Clang is what brings us forward. Especially in the long term. Open source has enabled and improved many commercial products. The current case that Microsoft uses it as part of their development illustrates this very well.
What?
Google said that Clang vs MSVC is within 5% performance (faster in parts, slower in parts). And that's Clang without PGO vs MSVC with PGO, so enabling PGO in Clang might make the Clang version even faster.
It's also much easier to optimize for a single compiler - e.g. they were already using Clang for some libraries, because Clang does inline x64 assembly, which MSVC doesn't support, and that brings significant performance gains to certain bits of code.
Er... Vivaldi has used Chrome as a base and been compiled with clang for a while now, I think:
Vivaldi 1.14.1077.55 (Stable channel) (32-bit)
Revision 46ff8f974f033190bbae67a70c7809ee15bc2353-
OS Windows
JavaScript V8 6.4.388.46
Flash (Disabled)
User Agent Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.189 Safari/537.36 Vivaldi/1.95.1077.55
Command Line "C:\Users\ldowling\AppData\Local\Vivaldi\Application\vivaldi.exe" --always-authorize-plugins --enable-blink-features=ResizeObserver --flag-switches-begin --flag-switches-end https://vivaldi.com/newfeature...
Executable Path C:\Users\ldowling\AppData\Local\Vivaldi\Application\vivaldi.exe
Profile Path C:\Users\ldowling\AppData\Local\Vivaldi\User Data\Default
Compiler clang
This is some very poor guessing.
"Old man yells at systemd"
Hes not wrong though. The place where you could maybe see a difference is in the layout and rendering engines, but even then i doubt clang is any noticeable faster OR slower than msvc.
In the article they talk about how updating to a new release of MSVC takes them a year, because their huge codebase full of cutting-edge complicated code usually triggers lots of bugs (internal compiler errors etc) in new MSVC releases. They have to report them and get them fixed.
Clang probably has the same number of bugs - writing a good compiler is hard - but Clang is open source so Google set up a build server to compile the latest dev version of Chrome with the latest dev version of Clang, so such bugs get caught straight away and fixed quickly.
Sometimes ya gotta just shit your pants and jump into the water. Google can afford that.
Agree with you "buggy" comment.
Maybe poor guessing but correct reasoning. If a large portion of the performance of a modern browser depends on its Javascript implementation, then switching C++ compilers makes much less difference because it doesn't change the Javascript compiler's logic. You'd have to rewrite the JS implementation instead of compiling it with a different compiler.
Ezekiel 23:20
A big part of a browser is its displaying of the page and details. A lot of this is actually calling the OS layers to do the work. Input Output, Drawing graphics, handling fonts, mouse input... All this stuff is on the OS layer which different compilers may have different tricks to call.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
There is no trick in calling OS layers.
How should that work?
If your C++ code says: drawRect(r); assuming r is of type Rect, it will be the exact same code regardless what OS.
For everything that actually is calling the OS a thin C layer in the libraries is used, because it is a difference if you need to to do an "interrupt" or some other way to call the kernel.
Above the C layers, there is hardly any reason to arrange code different because of different OS's
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
They're all optimized for x86...the opsys less so - what func to call in what library to do something is likely done by #ifdef, certainly not the compiler. To the extent there's more than one way to do it, my bet is that the code organization is optimized for Windows, at a design level well above the compilation stage. You might more-usefully wonder how compilers compare on say, ARM...
Why guess when you can know? Measure!
The choice to use clang makes sense if the following 2 statements are both true:
* Most end users have more computing power than is being utilized; they won't notice less optimized code.
* It's important to be able to be able to run the edit-compile-test cycle rapidly; this includes being able to concentrate on ONE development environment.
Isn't that how it's usually been done? I vaguely remember installing an old version of SunOS and, by default, it came with a linker (maybe even an assembler) but no compiler, which was sold separately.
Google ought to pour a LOT of love into a SPARC port. The best-situated would be OpenBSD.
Why, you ask? For the same reason that Microsoft's original target for the NT kernel was MIPS, and x86 was specifically secondary - oddball architectures will force you to clean up your code.
OpenBSD is also vicious in showing you your use-after-free mistakes since malloc() uses mmap() instead of sbrk() on their platform.
What kind of analogy is that?!
Calling conventions are different for Windows and Mac OS. This may make some difference in register allocations.
... so many options and it makes such little difference.
Because there are platform dependencies. The LLVM backend and annotators are different for Linux, macOS and WIndows, because they use different executable formats (ELF, MachO, and PE). And likewise, debug symbols are stored differently in each format - ELF can be self-contained, I believe MachO has external symbols, and PEs use PDBs (program database) generated during the build.
PDB support is interesting, because apparently it wasn't well documented, yet used by practically every debugger available for Windows. This resulted in Microsoft actually documenting the format and releasing PDB source code implementation for Clang/LLVM so it can generate files that any Windows debugger can use.
And there are plenty of Windows debuggers out there so being able to leverage them is quite useful on the platform.
For everything that actually is calling the OS a thin C layer in the libraries is used, because it is a difference if you need to to do an "interrupt" or some other way to call the kernel.
There's absolutely zero need to use C. C++ will do exactly the same things (possibly in exactly the same ways) with absolutely no extra overhead compared to C and C++ will do so in an easier, safer, and more readable fashion than C.
Do not misconstrue my statements to be derogatory toward C or C programmers! I'm simply trying to pedantically point out that there's no need to have a "thin layer of C" between C++ and the kernel.
I suspect the ability to optimize/fix anything they want with the compiler is a needed feature for them. They can do the same thing with gcc? Not really as it takes a major act of blood sacrifice to change things with gcc.
Well, there's spam egg sausage and spam, that's not got much spam in it.
And a binary format again has what exactly to do with the llvm code or x86 code emitted by clang?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Ofc. C and C++ are the same in that area.
But the libraries wrapping system calls are usually C because they then link with both.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
There always was a plethora of compilers on Microsofts operating systems: Watcom, Intel, Borland, Digital Mars, various gcc ports, and many others long forgotten, not to mention Microsoft's offerings.
But these days people seem to have borrowed a notion from Unix: "The platform compiler", and have gotten into their heads that Microsoft(tm) Visual Studio(tm) is just that.
But it isn't! There's no such thing! You just pick whichever compiler you feel feeds the needs of your project. For all the things that suck about Windows development, this is not one of them. There's choice and competition and that is a thing to rejoice about. Do not succumb to the fallacy that because Linux is good, then the cathedral of Linux compiler monoculture is also good.
And yes, I realise that a lot of these compilers also run on Linux, including Clang, which is sort of the point of the article. I'm just ranting because I'm getting sick and tired of OSS projects that on Windows only works with the latest edition of Microsoft(tm) Visual Studio(tm), because that's what the lead developer happens to use, and the lead developer can't be bothered to write portable code, because apparently Windows is such a magical special case that the normal rules of good software development practices don't apply.
End of rant. Diversity good! Monoculture bad! Ugh!
About 1/4 the way down the page in that link is "Performance" where they talk about a +/- 5% performance difference depending on the benchmark. So if you trust what they said the performance trade-offs are negligible.
I found Google's motivations here to be a bit interesting. They apparently wanted to use Clang across all their platforms.
I'm writing a cross-platform PC game using my own game engine. It runs natively on Windows desktop, UWP, Mac, and Linux. About 95% of it is written in portable ANSI C++, and the other 5% interfacing with native APIs. I actually use three different compilers, one for each OS, and I consider this a GOOD thing, not a bad thing. Compiling the same code against three compilers gives me a lot of confidence that when I hit a bug, it's because of my code, not some weird compiler-specific thing. The different compilers also have very minor differences in conformance to the standard, so again, I like having three different compilers check my code for conformance and correctness.
I understand that it may be nice to be able to use the exact same tools across platforms, but there are also some benefits to avoiding homogeneity.
Note: as to your question:
We conducted extensive A/B testing of performance. Performance telemetry numbers are about the same for MSVC-built and clang-built Chrome – some metrics get better, some get worse, but all of them are within 5% of each other. The official MSVC builds used LTCG and PGO, while the Clang builds currently use neither of these. This is potential for improvement that we look forward to exploring. The PGO builds took a very long time to build due to the need for collecting profiles and then building again, and as a result, the configuration was not enabled on our performance-measurement buildbots. Now that we use Clang, the perf bots again track the configuration that we ship.
Irony: Agile development has too much intertia to be abandoned now.
Now the strategy is clearer. It is an attempt to dislodge gcc from its perch in the Linux world. One of the very few standard things in Linux is the gcc. Fragment it, tout, one source both linux and windows as target binaries as benefit to woo people away from gcc. They think they MsDev is so good it can take Clang.
Clever move by Microsoft.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
So by "thin C layer" you meant the libs that the OS comes with not a layer within the program?
I guess I misunderstood you. I'm sorry.
Want to know the answer? There's an easy way. RTFA and find out! Amazing but true!
tl;dr +/- 5%. In some areas Clang does better, in others worse.
~.~
I'm a peripheral visionary.
Yes, suppose you call fopen() in the C library, that boils down to an system call in unix/linux, not sure if they call it system call in Windows, too. :D
The calling conventions to the respective "kernels" might be different, the system libraries take care for that.
Well, in simple words
No offense taken if you misunderstood me, I was bad in explaining.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The point is that chrome dev's can write *and debug* code using visual studio if that's what they prefer. While developers for all supported platforms can submit patches that are less likely to break when compiled for another platform, as they are using the exact same compiler.
Writing C++ code that works with microsoft's compiler on windows and clang on other platforms adds significant overheads. Microsoft has historically been slow to implement new C++ features completely and correctly in the past, making it much more likely that developers will submit patches that fail to compile on windows.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
You don't need to do anything special to be able to debug any program with visual studio. The binaries only ned debug info.
Writing C++ code that works with microsoft's compiler on windows and clang on other platforms adds significant overheads.
For whom? The Clang developers, no.
The Chrome developers, yes. But that has nothing to do with Clang but with the names of the functions of the system libraries and their parameters.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The binaries only need debug info
Yes they do, and now clang can produce that debug info in a format that visual studio can read. That was a key piece of development that allowed this change to happen.
but with the names of the functions of the system libraries and their parameters
Any developer should be hiding platform differences in isolated code that is only compiled for that platform. If you aren't touching that kind of code, your patch shouldn't break any other platform. The problems of supporting multiple compilers can be much more subtle than that.
C++ is a complex language, with many small behaviour details either left up to the compiler to define or deliberately left undefined. If you are restricting your code to behaviour that is well defined, you should be fine. However, different compilers sometimes interpret the language spec differently, and exploit the freedom that undefined behaviour gives them in different ways. Code that works fine when compiled with MSVC, might raise an error when compiled with clang, breaking the build for other developers. Developing any large C++ software, and supporting compiling it with multiple different C++ compilers, adds overhead to the day-to-day development of that software.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Which makes for less portable code...
You'll have to maintain multiple versions for different architectures (x86, amd64, arm, arm64 etc), and it won't support other architectures unless you also implement a C version as well. Porting to a new architecture becomes a lot more work.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
You're not wrong, it just doesn't matter to Google.
Compare template error messages between VC++ and Clang and you will never want to use VC++ again. Also MS is notoriously slow in getting the new C++ standards implemented right (but at least they got much better at it).
Finally a modular compiler chain so people with more complex problems can adapt the stack as needed. I am happy the 2 monolithic monstrosities (gcc & VC++) we had for at least 10 years too long are finally dying.
C++ will do so in an easier, safer, and more readable fashion than C.
You have never actually used C++ apparently and you most certainly haven't had to deal with other people's C++ code. Readability is not a strong point of C++ and is not actually easier to do anything meaningful compared to C.
Code that works fine when compiled with MSVC, might raise an error when compiled with clang, breaking the build for other developers. Developing any large C++ software, and supporting compiling it with multiple different C++ compilers, adds overhead to the day-to-day development of that software.
Yes, and that is why many companies actually do compile the code with different compilers on build farms to see if it compiles and run the tests against different binaries. Heck, many even use just one compiler but try to see if the tests run on all optimization levels.
My point was: as soon as you have a platform specific binary (e.g. windows or linux), then all debuggers on that platform can debug it. So there is nothing special missing or suddenly there.
Clang runs in windows since quite a while, probably since 2014 or even before. That was not the news.
The news is: Chrome is now build with Clang and no longer with MVC++ ...
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.