Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Chrome Microsoft Windows Linux

Chrome On Windows Ditches Microsoft's Compiler, Now Uses Clang (arstechnica.com) 94

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.
This discussion has been archived. No new comments can be posted.

Chrome On Windows Ditches Microsoft's Compiler, Now Uses Clang

Comments Filter:
  • 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)

    • 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.

      • This is some very poor guessing.

        • 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.
    • Why would a tool that emits x86 code on macOS do anything different on windows/x86?

      • 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.

        • 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

          • by e r ( 2847683 )

            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.

            • 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.

              • by e r ( 2847683 )
                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.
                • 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.
                  The calling conventions to the respective "kernels" might be different, the system libraries take care for that.
                  Well, in simple words :D

                  No offense taken if you misunderstood me, I was bad in explaining.

      • by tlhIngan ( 30335 )

        Why would a tool that emits x86 code on macOS do anything different on windows/x86?

        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 i

        • And a binary format again has what exactly to do with the llvm code or x86 code emitted by clang?

          • 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

            • 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.

              • 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 eith

                • 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

    • 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...
    • 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

    • by nadaou ( 535365 )

      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.

  • by TimSSG ( 1068536 ) on Tuesday March 06, 2018 @09:43AM (#56215953)
    http://blog.llvm.org/2018/03/c... [llvm.org]

    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.
  • by e**(i pi)-1 ( 462311 ) on Tuesday March 06, 2018 @09:59AM (#56216029) Homepage Journal
    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.
  • Vivaldi (Score:4, Informative)

    by ledow ( 319597 ) on Tuesday March 06, 2018 @10:15AM (#56216099) Homepage

    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... [vivaldi.com]
    Executable Path C:\Users\ldowling\AppData\Local\Vivaldi\Application\vivaldi.exe
    Profile Path C:\Users\ldowling\AppData\Local\Vivaldi\User Data\Default
    Compiler clang

  • by emil ( 695 )

    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.

  • 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

  • I was wondering why Microsoft would help Google help with PDB formats and explain the internals to make it inter operate with Clang. MS does not like other tools to interoperate with MS. It is always one way street,

    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 g

    • by fxbar ( 2627205 )
      Clang will become the standard on linux too I am sure. It is opensource, and the code has a nice modular architecture (gcc architecture is directly from hell, good luck if you want to reuse parts of it for something different, e.g. to create a static analyzer or a refactoring tool).
      Also compare template error messages between gcc/VC++ and Clang. It is just no competition.
      Finally a modular compiler chain so people with more complex problems can adapt the stack as needed. I am happy the 2 monolithic monst

"If it ain't broke, don't fix it." - Bert Lantz

Working...