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.
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.
The GNU folks have been too ambitious in their vision and many of its leaders didn't want to reconcile with its own problems in its vision. It was too easy to call people who disagreed with some of the GNU greedy corporate shills, where many the people were mostly on board however they had a few issues.
The biggest issue I have with GNU is the lack of respect of the time and effort it goes into coding. It seemed that if you wanted to make money off of GNU software you were limited to Distributions and Consulting support. Other methods that followed the rules have been frond on or caused the GPL to change to prevent such actions (With the IBM Exception). So for many businesses who in general supported open source principals tend to shy away from GNU software as it may bite them in the future.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
I never met a time traveler before. How is life in 2004 treating you? If my computer has 16Gb of memory why should I be upset that programs take advantage of it? Is that bragging rights or something? Oh look I have 64Gb and never use more than 6!
Only the State obtains its revenue by coercion. - Murray Rothbard
no, that's mostly because of shitty javascript on the whiz-bang web-2.0 sites you're browsing.
All of those videos on pornhub take up a lot of ram.
My computer has 16GB of memory and keeps killing Chrome for using most of it. Shrug.
Support my political activism on Patreon.
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.
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"
Tablets and netbooks still usually come with 1-2GB of non upgradeable ram. Even the Surface Laptop, a relatively expensive laptop comes with only 4.
The biggest issue I have with GNU is the lack of respect of the time and effort it goes into coding.
The biggest problem I've had with GNU/GPL software is two fold:
On top of that it seems like a lot of tools were developed in a weekend by a single individual to scratch an itch and move on. GNUMake seems to be one of the biggest ones that everyone runs into. No one wants to make any changes that break stuff because then people will complain, and at this point so much needs to be 'fixed' that it'll never happen. And no one wakes up thinking "I'll take time to do this right" because they won't ever get paid for any improvements they make.
When I started doing FreeBSD development and working with BSD userspace it felt 'broken' at first, but after sitting down and RTFM, it feels like they actually put thought into some design decisions. And yes, sometimes stuff breaks. But they seem to give a fairly big heads up of any breaking changes.
And if something is up to date and maintained it appears that people are being paid to fix it and keep it working. I dig through BSD project commits and a lot of individuals at big companies making small tweaks to keep things running. The nature of the license doesn't scare away the lawyers and when I see a BSD binary that does everything I need it to I kind of tell myself "This is what I'm *allowed* to see, the cool stuff must still be behind closed doors".
How much cruft and dead weight is in GCC because of the myriad of platforms it needs to support and the way in which it supports them?
LLVM started off as a graduate project where it looks like someone actually sat down and thought about use cases. If I want to port a new language to a platform I just have to make a $LANG to intermediate representation (IR) parser.
The same thing goes for porting LLVM to a new architecture, I just need to make the IR to byte code part. I don't have to waste my time working out the C, C++, Fortran bits and can concentrate on supporting my architecture.
I'm sure that Apple, IBM and Google have some incredibly awesome tools they can't or wont show us. Probably some stuff highly specific to what ever they need to support. And if that's what puts food on their table, it works for me.
Use Firefox, apply the proper config options for memory use limitation? (At least that's what worked for me in the moderately distant past...)
Ezekiel 23:20
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.
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!
Why would google care? The entire point is to support more platforms.
Why guess when you can know? Measure!
I tried that last year and that's how I ended up using Chrome.
Support my political activism on Patreon.
They've chosen Clang over GCC for political reasons: despite a codebase without historical baggage, Clang is at least several percent slower than GCC, it only compiles faster. A good rule of thumb is that Clang-built code executes as GCC at one optimization level less, with compilation speed being likewise faster. Obviously, this wildly differs per test case.
Also, Clang's portability is pretty bad.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
You one of those nutjobs that keeps 400 tabs open? Chrome never uses more than 2-3Gb for me.
Only the State obtains its revenue by coercion. - Murray Rothbard
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.
It's important to be able to be able to run the edit-compile-test cycle rapidly
Please remind me: which company has the biggest computing power on the planet? And even on a single beefy machine, you can have enough cores to make final link the slowest part. Chrome still uses system linker both on Linux and Windows.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
According to Judy Garland, the trolley. The trolley went clang, clang, clang.
I have, unfortunately, met people like you before. People like you are the reason why it costs a gigabyte of RAM and requires a VM being spun up just to plop "Hello World" on a screen. Why am I upset when your inefficient program eats my RAM? I am upset because my computer's resources are not yours to waste. Read that again to yourself a few times for emphasis please.
Good code is efficient with memory, CPU, and any other resource it makes use of. This is just simply programming best practice. Wasting resources because you have them to waste makes for programs that don't play well with others and it leads to a lackadaisical attitude in more than just resource usage. Plus, as much as you might think you've invented hard AI, or the software cure for cancer, people are going to want to run more than just your precious little brain child. In response to the Amiga, Bill Gates famously said "who will ever want to run more than one program at a time?". You seem to have that mentality. I like to use my RAM for my purposes. I load up huge images to photo edit while a kernel compiles in a virtualbox session and while I re-encode a video with a codex that works with my BlurRay player. I am also someone that likes to have 30+ tabs open as I work, and a browser built with an efficient compiler is appreciated.
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.
Well, for one thing, it's nice to be able to run something besides a web browser in that 16GB of RAM at the same time. Like maybe an over-bloated email cllient. Or an over-bloated messaging app. Maybe even an application to get actual work done.
We've had multitasking for over 30 years now, are you suggesting that we step back to the days of the Apple II and the original IBM PC? Except with pretty graphics and untold waste of system resources?
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
I use tab discarding. Certain web sites seem to pile up the JavaScript if left open for a long time.
Support my political activism on Patreon.
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!
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
It's not about Clang, it's about LLVM.
Google wants to commence re-implementing their browser in Rust, a thread-safe functional language. By using LLVM, they can cherrypick any code from the Servo project for incorporation into Chromium. And they save on R&D costs by letting Mozilla employees do most of the work.
Also gcc's optimizer is notorious for bugs and undefined behaviors. Just try this in optimized mode with any gcc version and compare it with other compilers:
Your code is buggy; gcc notices the bug and issues a diagnostic, while clang happily produces incorrect output.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
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.
There will be many more users than developers, wasted processor cycles have to be multiplied by the number of users out there...
This translates to a significant amount of power wasted when spread over millions of devices.
This also adds up in virtualized environments, if you're running many instances of something than any inefficiencies are multiplied.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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!
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.