7 ms·

There are a lot of poor or outdated answers to the question (arguing a lack of accelerated graphics, for example). The number one reason current browsers are i

There are a lot of poor or outdated answers to the question (arguing a lack of accelerated graphics, for example). The number one reason current browsers are implemented in C++ is momentum. A browser has a lot of parts that do a lot of things; they're big code bases. JIT compilation technology on the JVM (and elsewhere) these days is pulling within 20-50% of static C/C++ code. If you were coding from scratch these days, would you start with C/C++? I doubt it, especially when you know you can get most of the same performance with other platforms. By far the most important reason to choose a modern VM environment is security. Except in a vanishingly small number of cases, everything should always be bounds checked. The "native" part of a browser should be as small as possible, with a highly constrained and thoroughly checked API. Take away manual memory allocation and use after free goes away. Take away pointers and buffer overflows go away. You want as much of the browser code as possible to be running in a managed environment. In my opinion every line of native code carries risks that don't exist in managed environments. Yes, properly written C code won't exhibit those problems -- but it seems to be extraordinarily difficult to do that. Security flaws are still being found in browsers, decades later. And yes, security flaws exist in systems like the JVM. Those mostly come from native code as well, but some of them are because of the design. The JVM's "native part" is just too big. Too much is done there that doesn't need to be. With a massive native code base it's just a huge problem to verify everything. So Rust and Go are quite interesting. It's critically important that these languages remove "unsafe" features from something like C/C++, and lose almost nothing in the process. And around the corner, environments like the JVM can auto-vectorize on the fly (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116452 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7116452), knocking down yet another performance-parity barrier.

kintamanimatt 13y ago
Performance doesn't just include CPU time, but also memory footprint. You might eat a similar amount of processor time, but you're not going to have a similar memory footprint with any kind of GC'd language, and if the GC happens to be a stop the world GC, you're likely to see pauses in the browser that will irritate the user. Before the inevitable "memory is cheap" argument is made, I'd rather have my client app be a good neighbor. Having a GC'd process on a client munch through memory like it's infinite is just bad manners and makes some bad assumptions. (On the flip side, a GC'd process that tries to be a good neighbor by freeing memory aggressively becomes a bad neighbor in terms of CPU time, which has additional consequences in terms of battery life.) The JVM, for example, tends to only run its GC when it needs to. It is a horrible neighbor in this respect because it just takes all the memory it needs and only runs its GC when it really, really has to. This is one of the reasons it's relatively fast, but as a consequence puts a lot of pressure on the system. In such a scenario it's possible other processes will OOM and be killed, or the system will start swapping memory pages, or other processes will have to run their GC more aggressively (as V8 does in low memory conditions) which puts even more pressure on the system. All this adds up to very selfish apps that bog down a system and can become virtually unusable. These selfish apps are also unsuitable for use in poorer parts of the world where incomes are lower and additional memory is potentially unaffordable. I think it's probably okay to take the attitude that memory is cheap when you control the environment and you're paying for the memory, but in any other circumstance, shipping software that gluttonously gobbles memory is probably unacceptable and the #1 reason why C++ makes good sense as a language choice for writing a browser.
- asveikau 13y ago
  I found this whole discussion irritating because not a single person mentioned that with the memory demands of a web browser that you might not want GC. You can say all this BS about momentum but in my mind avoiding GC is probably the best and most relevant reason in 2013. Thank you for mentioning it. Shows how dependent on GC a large part of the community of developers have become - they are incapable of imagining a world without it. (PS: I am amused when people mention that being 20-50% slower is described as fixing the performance gap.)
  - marpalmin 13y ago
    I see your point, but even if you avoid GC you have other alternatives nowadays.
    - kintamanimatt 13y ago
      Such as?
      - yareally 13y ago
        Probably referring to reference counting, but that's not exactly a new idea. Still makes for a performance hit using reference counting all over the place.
        kintamanimatt 13y ago
        I hope not! Reference counting is horrible in terms of CPU time!
        aktau 13y ago
        Citation?
        kintamanimatt 13y ago
pohl 13y ago
Here's an old, but good thread relevant to the discussion: http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html
tdees40 13y ago
Keep in mind though that a 20-50% slowdown is pretty big in the browser world, especially given that those numbers represent a lower-bound for how much slower a GC browser would be. Would you trade your Chrome/Firefox browser for something 20-50% slower? I wouldn't, and I don't think anyone else would.
- zurn 13y ago
  Keep in mind that using a less hostile language boosts the performance returns you get from optimization work per work-hour spent. And reduces risks of breaking stuff while doing so.
- hfsktr 13y ago
  "Would you trade your Chrome/Firefox browser for something 20-50% slower?" IE? I'm just kidding. I found after I upgraded from IE 7/8 (only had for testing) that 9 was pretty usable (haven't used past that). Just out of curiosity though...depending on where it slowed down would people notice? If it still displayed as quickly but was slower to startup (or other examples). I admit I don't know much about how browsers actually work (I am assuming it is more than just displaying html).
- rossjudson 13y ago
  In the context of a browser, I doubt that the standard 20-50% difference applies. That difference is what you see when measuring JVM code against optimized C++. In the browser world, that kind of pure speed doesn't happen because achieving security means layering all of the bounds checking and such back into the code, erasing one of the major reasons why the JVM code is slower. In C/C++ you have the option of not performing those kinds of checks to get speed. In a secure browser, you don't want to take that risk unless it's absolutely necessary.
tosseraccount 13y ago
I disagree. There's a reason your OS, your browser, your shell, your word processor, etc. are written in C and or C++ not to mention your JVM, python, perl, your favorite libraries, etc. It's not "momentum", it's "track record". Yes, you can shoot yourself in the foot with C/C++. Experts know this and manage not to maim themselves. Java has improved ... a lot ... no doubt but the " 20-50%" is a tad hyperbolic. Yes, repeatedly calling the same function (who's internals are in C) with Java sometimes you can get to with 20%. And , of course, carefully crafted java routines can beat naive, sloppy C sometimes. Back in the day, Java proponents promised us the Javagator [ http://www.wired.com/science/discoveries/news/1998/04/11458 http://www.wired.com/science/discoveries/news/1998/04/11458 ]. Don't hold your breath for a competitive Java browser. The speed and small foot print of C/C++ will continue to be edge giving it almost all the market share.
- greenyoda 13y ago
  There's another huge problem with writing a browser in Java (or any other JVM-based language), which is that your browser would be dependent on the user installing the JVM, which is a separate product from a separate company that has a separate release cycle (and lots of security updates to deal with). It's hard enough to support a browser like Firefox or Chrome without dealing with issues like the user having Java 1.5 installed but the current version of the browser requires Java 1.6 or above. For a non-technical user who barely knows the difference between their browser and their operating system, there are huge obstacles in supporting software built on top of the JVM.
  - Arelius 13y ago
    I feel that additionally there is some user resistance to installing and using the JVM. It may be minor, but I do know some people that won't touch eclipse with a 10 foot pole due to that.
  - Gravityloss 13y ago
    You could just supply the jvm with the browser. Most browsers autoupdate nowadays silently in the background anyway.
zanny 13y ago
> I doubt it I do, I like writing C++. The toolchains and infrastructure around it support really concise clean code since C++11. I wouldn't probably want to do job-work with it, because it is easy to fuck up C++ (ie, the unsafe features) and trying to debug someone else's incompetence is a pain in the butt. But I really like qt / kde and its support libraries and if you use a modern IDE, at least cmake-quality build systems, a memory profiler + debugger, and the modern language and syntax, it isn't any harder than Java or C#. I'd say its easier, lambdas and global scope let you do non-OO when it is appropriate. Though I'd rather have Rust / its successor where you get something like C++-- where you add the good stuff (smart pointers, lambdas, generics) and remove the bad stuff (point mangling, ugly syntax, unexpected behavior, the horrible char/string format the standard uses, textual inclusion). D is close, but since the entire std depends on garbage collection and it uses a runtime to enable mixins and other fancy features it isn't a drop in replacement. You need deterministic compile time assembly generation that does the minimum magic behind the scenes. You don't want the compiler to hide anything, but you also want it to present everything intuitively with a bend towards naturally promoting best practices, rather than crazy hacks in the C++ world like #ifdef <this header> etc #endif, d pointers, and its ilk. I think that is actually the flaw in the Rusts / Gos / etc. When you put in garbage collection, mixins (or other code generation at runtime) you obfuscate the implementation which instantly makes it unsuitable for a lot of the reasons you use native code in the first place. The processor pipelines and assembly architectures themselves are already vague and unintuitive enough, throwing on language runtime features that you have to debug make it a much more difficult proposition. I think inheritance is basically the limit of how much behind the scenes magic you can do (complexity wise) and still expect people to use it like its just a fancy assembly. It is easy to understand and debug vtables - it is much less easy to debug the generational shifting aspects of a good GC. It is even harder to debug the code generator making your runtime injected code. Those kinds of things make great libraries to link in knowing they aren't in the base language and aren't cluttering up your execution space with pervasive hooks everywhere to support a "clean" language syntax. Yeah, it means using a gc in C++ requires you to write things like gc::new(<construct object here>) when you want to construct it, and the gc itself requires an initializer (ie, in main, gc::start();) since C++ doesn't have autorun at start (which is good, in my book, it means the code running under the hood is only the code you say to run).
aboodman 13y ago
If by "these days" you mean ~6 years ago, then the answer is "yes, you'd start with C/C++". At least, that is what the Chrome team did.
- tosseraccount 13y ago
  Actually, webkit dates to 1998.
  - yuhong 13y ago
    KHTML dates to 1998.
  - oscargrouch 13y ago
    but the chrome effort started in 2006 to finish in 2008..
  - aboodman 13y ago
    Chrome contains millions of lines of code, not counting WebKit. Almost all of that is C++ and was started 6-7 years ago.
yk 13y ago
I think all of your arguments go precisely into the other direction, at least at the moment. Browsers are huge code bases, and have at least at their core very high quality code. So for starters, the security advantages are actually on the side of low level languages, since you do not import the problems of the VM. ( Granted most VMs are also really high quality code, but if you do your memory management yourself, you can fine tune it for your use case.) Additionally, the 20-50% speedup are perhaps not the factor of 10 of yonder years, but they are still a speedup. And last but not least, a browser is a runtime environment. You need to do the memory management for JS anyhow, so you can also use the memory management for the rest of your code. So it is possible that at some point other languages than C/C++ will be the languages of choice for large projects. But frankly I think that these will not be GC languages, but languages were you get the GC somehow from the paradigm. ( I am currently thinking of Haskell. Functional languages can do really interesting things with GC, since all their data is local. )
Arelius 13y ago
> So Rust and Go are quite interesting. It's critically important that these languages remove "unsafe" features from something like C/C++, and lose almost nothing in the process. I have no idea why people keep bringing up Go as a C++ replacement language. I feel any C/C++ programmers that see Go suitable for their needs, would have already moved on to Java or C#. Can anybody explain to me what makes Go favorable to a C++ programmer?
- elsif1 13y ago
  I agree. I saw mandatory GC in Go and ruled it out as a potential C++ replacement. Rust may be on the right track though.
- azth 13y ago
  Indeed. I was about to make a similar comment. I think this comes from the hype that surrounds Go, that it is a "systems" language. In reality, it is no more a "systems" language than Java. These days, it seems that Go lays somewhere between the Perl/Python/Ruby bunch, and Java. It is not a replacement for C and C++ in their domains (OS; kernels; file systems; embedded; high performance games; etc.). Rust is attempting to take on C++ in those segments, as you pointed out.

kintamanimatt 13y ago

Performance doesn't just include CPU time, but also memory footprint. You might eat a similar amount of processor time, but you're not going to have a similar memory footprint with any kind of GC'd language, and if the GC happens to be a stop the world GC, you're likely to see pauses in the browser that will irritate the user. Before the inevitable "memory is cheap" argument is made, I'd rather have my client app be a good neighbor. Having a GC'd process on a client munch through memory like it's infinite is just bad manners and makes some bad assumptions. (On the flip side, a GC'd process that tries to be a good neighbor by freeing memory aggressively becomes a bad neighbor in terms of CPU time, which has additional consequences in terms of battery life.) The JVM, for example, tends to only run its GC when it needs to. It is a horrible neighbor in this respect because it just takes all the memory it needs and only runs its GC when it really, really has to. This is one of the reasons it's relatively fast, but as a consequence puts a lot of pressure on the system. In such a scenario it's possible other processes will OOM and be killed, or the system will start swapping memory pages, or other processes will have to run their GC more aggressively (as V8 does in low memory conditions) which puts even more pressure on the system. All this adds up to very selfish apps that bog down a system and can become virtually unusable. These selfish apps are also unsuitable for use in poorer parts of the world where incomes are lower and additional memory is potentially unaffordable. I think it's probably okay to take the attitude that memory is cheap when you control the environment and you're paying for the memory, but in any other circumstance, shipping software that gluttonously gobbles memory is probably unacceptable and the #1 reason why C++ makes good sense as a language choice for writing a browser.

asveikau 13y ago
I found this whole discussion irritating because not a single person mentioned that with the memory demands of a web browser that you might not want GC. You can say all this BS about momentum but in my mind avoiding GC is probably the best and most relevant reason in 2013. Thank you for mentioning it. Shows how dependent on GC a large part of the community of developers have become - they are incapable of imagining a world without it. (PS: I am amused when people mention that being 20-50% slower is described as fixing the performance gap.)
- marpalmin 13y ago
  I see your point, but even if you avoid GC you have other alternatives nowadays.
  - kintamanimatt 13y ago
    Such as?
    - yareally 13y ago
      Probably referring to reference counting, but that's not exactly a new idea. Still makes for a performance hit using reference counting all over the place.
      - kintamanimatt 13y ago
        I hope not! Reference counting is horrible in terms of CPU time!
        aktau 13y ago
        Citation?
        kintamanimatt 13y ago

pohl 13y ago

Here's an old, but good thread relevant to the discussion: http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html http://gcc.gnu.org/ml/gcc/2002-08/msg00552.html

tdees40 13y ago

Keep in mind though that a 20-50% slowdown is pretty big in the browser world, especially given that those numbers represent a lower-bound for how much slower a GC browser would be. Would you trade your Chrome/Firefox browser for something 20-50% slower? I wouldn't, and I don't think anyone else would.

zurn 13y ago
Keep in mind that using a less hostile language boosts the performance returns you get from optimization work per work-hour spent. And reduces risks of breaking stuff while doing so.
hfsktr 13y ago
"Would you trade your Chrome/Firefox browser for something 20-50% slower?" IE? I'm just kidding. I found after I upgraded from IE 7/8 (only had for testing) that 9 was pretty usable (haven't used past that). Just out of curiosity though...depending on where it slowed down would people notice? If it still displayed as quickly but was slower to startup (or other examples). I admit I don't know much about how browsers actually work (I am assuming it is more than just displaying html).
rossjudson 13y ago
In the context of a browser, I doubt that the standard 20-50% difference applies. That difference is what you see when measuring JVM code against optimized C++. In the browser world, that kind of pure speed doesn't happen because achieving security means layering all of the bounds checking and such back into the code, erasing one of the major reasons why the JVM code is slower. In C/C++ you have the option of not performing those kinds of checks to get speed. In a secure browser, you don't want to take that risk unless it's absolutely necessary.

tosseraccount 13y ago

I disagree. There's a reason your OS, your browser, your shell, your word processor, etc. are written in C and or C++ not to mention your JVM, python, perl, your favorite libraries, etc. It's not "momentum", it's "track record". Yes, you can shoot yourself in the foot with C/C++. Experts know this and manage not to maim themselves. Java has improved ... a lot ... no doubt but the " 20-50%" is a tad hyperbolic. Yes, repeatedly calling the same function (who's internals are in C) with Java sometimes you can get to with 20%. And , of course, carefully crafted java routines can beat naive, sloppy C sometimes. Back in the day, Java proponents promised us the Javagator [ http://www.wired.com/science/discoveries/news/1998/04/11458 http://www.wired.com/science/discoveries/news/1998/04/11458 ]. Don't hold your breath for a competitive Java browser. The speed and small foot print of C/C++ will continue to be edge giving it almost all the market share.

greenyoda 13y ago
There's another huge problem with writing a browser in Java (or any other JVM-based language), which is that your browser would be dependent on the user installing the JVM, which is a separate product from a separate company that has a separate release cycle (and lots of security updates to deal with). It's hard enough to support a browser like Firefox or Chrome without dealing with issues like the user having Java 1.5 installed but the current version of the browser requires Java 1.6 or above. For a non-technical user who barely knows the difference between their browser and their operating system, there are huge obstacles in supporting software built on top of the JVM.
- Arelius 13y ago
  I feel that additionally there is some user resistance to installing and using the JVM. It may be minor, but I do know some people that won't touch eclipse with a 10 foot pole due to that.
- Gravityloss 13y ago
  You could just supply the jvm with the browser. Most browsers autoupdate nowadays silently in the background anyway.

zanny 13y ago

> I doubt it I do, I like writing C++. The toolchains and infrastructure around it support really concise clean code since C++11. I wouldn't probably want to do job-work with it, because it is easy to fuck up C++ (ie, the unsafe features) and trying to debug someone else's incompetence is a pain in the butt. But I really like qt / kde and its support libraries and if you use a modern IDE, at least cmake-quality build systems, a memory profiler + debugger, and the modern language and syntax, it isn't any harder than Java or C#. I'd say its easier, lambdas and global scope let you do non-OO when it is appropriate. Though I'd rather have Rust / its successor where you get something like C++-- where you add the good stuff (smart pointers, lambdas, generics) and remove the bad stuff (point mangling, ugly syntax, unexpected behavior, the horrible char/string format the standard uses, textual inclusion). D is close, but since the entire std depends on garbage collection and it uses a runtime to enable mixins and other fancy features it isn't a drop in replacement. You need deterministic compile time assembly generation that does the minimum magic behind the scenes. You don't want the compiler to hide anything, but you also want it to present everything intuitively with a bend towards naturally promoting best practices, rather than crazy hacks in the C++ world like #ifdef <this header> etc #endif, d pointers, and its ilk. I think that is actually the flaw in the Rusts / Gos / etc. When you put in garbage collection, mixins (or other code generation at runtime) you obfuscate the implementation which instantly makes it unsuitable for a lot of the reasons you use native code in the first place. The processor pipelines and assembly architectures themselves are already vague and unintuitive enough, throwing on language runtime features that you have to debug make it a much more difficult proposition. I think inheritance is basically the limit of how much behind the scenes magic you can do (complexity wise) and still expect people to use it like its just a fancy assembly. It is easy to understand and debug vtables - it is much less easy to debug the generational shifting aspects of a good GC. It is even harder to debug the code generator making your runtime injected code. Those kinds of things make great libraries to link in knowing they aren't in the base language and aren't cluttering up your execution space with pervasive hooks everywhere to support a "clean" language syntax. Yeah, it means using a gc in C++ requires you to write things like gc::new(<construct object here>) when you want to construct it, and the gc itself requires an initializer (ie, in main, gc::start();) since C++ doesn't have autorun at start (which is good, in my book, it means the code running under the hood is only the code you say to run).

aboodman 13y ago

If by "these days" you mean ~6 years ago, then the answer is "yes, you'd start with C/C++". At least, that is what the Chrome team did.

tosseraccount 13y ago
Actually, webkit dates to 1998.
- yuhong 13y ago
  KHTML dates to 1998.
- oscargrouch 13y ago
  but the chrome effort started in 2006 to finish in 2008..
- aboodman 13y ago
  Chrome contains millions of lines of code, not counting WebKit. Almost all of that is C++ and was started 6-7 years ago.

yk 13y ago

I think all of your arguments go precisely into the other direction, at least at the moment. Browsers are huge code bases, and have at least at their core very high quality code. So for starters, the security advantages are actually on the side of low level languages, since you do not import the problems of the VM. ( Granted most VMs are also really high quality code, but if you do your memory management yourself, you can fine tune it for your use case.) Additionally, the 20-50% speedup are perhaps not the factor of 10 of yonder years, but they are still a speedup. And last but not least, a browser is a runtime environment. You need to do the memory management for JS anyhow, so you can also use the memory management for the rest of your code. So it is possible that at some point other languages than C/C++ will be the languages of choice for large projects. But frankly I think that these will not be GC languages, but languages were you get the GC somehow from the paradigm. ( I am currently thinking of Haskell. Functional languages can do really interesting things with GC, since all their data is local. )

Arelius 13y ago

> So Rust and Go are quite interesting. It's critically important that these languages remove "unsafe" features from something like C/C++, and lose almost nothing in the process. I have no idea why people keep bringing up Go as a C++ replacement language. I feel any C/C++ programmers that see Go suitable for their needs, would have already moved on to Java or C#. Can anybody explain to me what makes Go favorable to a C++ programmer?

elsif1 13y ago
I agree. I saw mandatory GC in Go and ruled it out as a potential C++ replacement. Rust may be on the right track though.
azth 13y ago
Indeed. I was about to make a similar comment. I think this comes from the hype that surrounds Go, that it is a "systems" language. In reality, it is no more a "systems" language than Java. These days, it seems that Go lays somewhere between the Perl/Python/Ruby bunch, and Java. It is not a replacement for C and C++ in their domains (OS; kernels; file systems; embedded; high performance games; etc.). Rust is attempting to take on C++ in those segments, as you pointed out.