Why is C++ So Fast?

by

I had to respond to John Cook’s blog post,

My response was so long, I thought I’d repost it here.

I didn’t understand the answer properly six months ago, despite spending a couple years as a professional C coder (when I did speech recogntion) and having spent the past ten or so years writing Java. C++ is enough different than either of these to be a completely different sort of beast.

C++ is Faster than C!

At least, it’s easier to write fast code in C++ than in C these days. In fact, these days, C++ is the language of choice for optimization, not plain old C. The reason it’s so efficient is twofold.

Reason 1: Tight Data Structures

First, C++ is intrinsically stingy with memory (unlike Java objects, a C++ struct has no memory overhead if there are no virtual functions [modulo word alignment issues]). Smaller things run faster due to caching, and are also more scalable. Of course, this is true of C, too.

Reason 2: Template Metaprogramming

What makes C++ both hard to debug and understand and even more efficient than C is the use of template metaprogramming.

In particular, there’s huge gains to be made with the kind of lazy evaluation you can implement with expression templates and the kind of memory and indirection savings you get by avoiding virtual functions with the curiously recurring template pattern.

[Update: 28 July 2011: I thought an example would help, and this was the original one motivating template expressions.]

Suppose you have a scalar x and two m by n matrices a and b. Now suppose you want to evaluate d = a + (x * b). The standard non-lazy approach would be to create an intermediate matrix c representing the scalar-matrix product (x * b) and then add that to a. Basically, what’d happen is the same as if you’d coded it like this:

matrix c(m,n);
for (int m = 0; m < M; ++m)
    for (int n = 0; n < N; ++n)
        c[m,n] = x * b[m,n];
matrix d(m,n);
for (int m = 0; m < M; ++m)
    for (int n = 0; n < N; ++n)
        d[m,n] = a[m,n] + c[m,n];
return d;

With clever template expression programming, you can get around allocating an intermediate value, so that the resulting computation would amount to the same thing as coding it as follows.

matrix d(m,n);
for (int m = 0; m < M; ++m)
    for (int n = 0; n < N; ++n)
        d[m,n] = a[m,n] + x * b[m,n];
return d;

This saves the allocation and deallocation of matrix c. Memory contention is a huge problem with numerical code these days as CPU speed and parallelism outstrips memory speed, so this is a very large savings. You also save intermediate index arithmetic and a number of sets and gets from arrays, which are not free.

The same thing can happen for transposition, and other operations that don’t really need to generate whole intermediate matrices. The trick’s figuring out when it’s more efficient to allocate an intermediate. The Eigen matrix package we’re using seems to do a good job of this.

[end Update: 28 July 2011]

Voting with Their Code

I just visited Google NY lat week, where some of my old friends from my speech recognition days work. Upon moving to Google, they reimplemented their (publicly available) finite state transducer library in C++ using expression templates (the OpenFST project).

You’ll also see expression templates with the curious recurrence in the efficient matrix libraries from Boost (BLAS level only) and Eigen (also provides linear algebra). They use templates to avoid creating intermediate objects for transposes or scalar-matrix products, just like a good Fortran compiler.

But Wait, C++ is also More Expressive

Templates are also hugely expressive. They lead to particularly neat implementations of techniques like automatic differentiation. This is what roused me from my life of Java and got me into C++. That, and the need for good probability and matrix libraries — why don’t these things exist in Java (or where are they if I missed them?).

The Future: Stochastic Optimization

What’s really neat is that there are now stochastic optimizers for C++ that can analyze your actual run-time performance. I really really really like that feature of the Java server compilers. Haven’t tried it in C++ yet.

PS: So Why is LingPipe in Java?

Ability to write fast programs isn’t everything. Java is much, and I mean much, easier to deploy. The whole jar thing is much easier than platform-specific executables.

Java’s code organization is much cleaner. None of this crazy header guard and .hpp versus .cpp stuff. No putting namespaces one place, code another place, and having them completely unrelated to includes (you can be more organized, but this stuff’s just much easier to figure out in Java because it’s conventionalized and everyone does it the same way). The interfaces are simpler — they’re explicit, not undocumented pure abstractions (where you have to look at the code of what they call an “algorithm” to see what methods and values it requires of its objects).

Java has support for threading built in. And a great concurrency library. There are web server plugins like servlets that make much of what we do so much easier.

There’s also programming time. I’m getting faster at writing C++, but there’s just so much more that you need to think about and take care of, from both a system author and client perspective (mainly memory management issues).

Many people don’t realize this, but C is pretty much the most portable language out there. As far as I know, there’s no place Java runs that C won’t run. C++ is a different story. The compilers are getting more consistent, but the texts are still fraught with “your mileage may vary due to compiler” warnings, as are the mailing lists for the different packages we’re using (Eigen, Boost Spirit, Boost Math), all of which lean heavily on templates.

36 Responses to “Why is C++ So Fast?”

  1. John Says:

    Good points. I’m glad you made this it’s own post.

    Someone might object that C beats C++ by the “voting by their code” criteria since many open source projects are written in C. I would reply that C may be a better choice for open source projects because it’s a lowest-common-denominator language. C++ supports many styles of programming, and a small team can agree on a way of using the language. It would be harder for a world-wide volunteer effort to agree on and enforce a set of C++ standards.

    • Bob Carpenter Says:

      That’s exactly what freaked me out about reading other people’s C++ code. It often doesn’t even look like C++. Especially with liberal use of the preprocessor and extensive operator overloads.

      Writing pretty vanilla C++ seems safer for managing memory. But indeed, C is definitely lower on the common denominator front. It just doesn’t support much of what we expect from a higher-level language.

  2. Toby Says:

    “there’s no place Java runs that C won’t run”

    That’s because Java (like most higher level languages we use) is coded in C.

    But in all seriousness, C/C++ should be considered niche languages, not for general purpose programming – and I say that as somebody who’s been writing C for more than 25 years. They are at the wrong level of abstraction for most problems, as you argue.

  3. Frode T Says:

    Sorry. The speed of a program is a property of the compiler, not the language. C++ fails big time when it comes to maintainability. Even though a compiler might produce decent speedy code, say 10% faster, from some incomprehensible C++ source, years (or even weeks) from now, you won’t be able to make heads or tails of a team effort C++ code, port it to some other target or maintain it for any considerable time without significant effort. And it is probably littered with impossible to find errors. C is a very nice library level programming language as most (all?) other languges around have some way of calling C functions, but are otherwise fraught with the same problems as C++.

    • Bob Carpenter Says:

      I don’t know what you mean by speed being a property of the compiler. Other than in a sense that every property of a language depends on the compiler, which defines what the language actually does.

      What I was saying is that there are patterns in C++ like expression templates that make it relatively easy to write code that’s much much more than 10% faster in many cases than what you could easily write in Java or C.

      Yes, maintenance and understanding can be a pain. That’s what people told me about Java. What’s odd is that no matter what language you’re working in (and I have active projects in Java, Python and C++ at the moment), that you should be using something else (most recently, in no particular order, Scala, Python, Haskell).

      What I forgot to mention in the article is that there’s huge prejudice out there. We’ve had many customers tell us they wouldn’t even look at our software because it’s in Java and therefore must be slow. At the level of optimization we’re working at, it’s mostly just simple stuff and algorithms. That’s why we’re using Java.

      I’ve also been told that Java’s too complex for one of our intended audiences, natural language processing researchers. Apparently they want Matlab or Python depending on whether they came to programming through engineering or linguistics.

      This is also related to John’s comment above, and is largely about how you write your C++. It’s much better now than it was even ten years ago, when the compilers all varied tremendously in what they supported and how they compiled.

      • Frode T Says:

        @Bob: Yes, I agree that some patterns in C++ might generate faster code, in the same way that hand coding them in C (or assembler), taking care of register usage, pipelining, contention, etc. of the target platform, might produce even faster code (at the cost of portability/generalisation).

        The cost that C++ incurs is the cost of maintainability. I know I write awful C++ code, but all consultants we’ve had also write awful C++ code. And I have spent a lot of time debugging this awful code, lastly when porting from SPARC Solaris to x86 Linux.

        What I’m trying to convey is that the most important performance factor is the performance of the development and maintenance effort. I my experience C++ never gained us any speed, neither in development nor in actual program performacen.

      • Bob Carpenter Says:

        I agree with the first part of what you wrote, namely that using templates poorly can lead to unmaintainable code. And incomprehensible code if the reader isn’t used to that kind of programming style.

        Programmer time’s important, as is ease of use. We did write LingPipe in Java, after all.

        I think it’s kind of a horses-for-courses argument

        I can’t agree with the second point. C++ templating is a huge win in terms of efficiency.

        Also, there are things we’re doing like algorithmic differentiation, which can’t be easily or efficiently represented in Java.

        As far as the code looks, the optimizations wind up looking more like they would in a typed lazy functional programming than they do like what you’d see in a call out to assembly. I’m sure there are people doing both for complementary reasons. The problem with assembly, of course, is that it’s not very portable. Whereas C++ is pretty portable these days if you’re on a platform supporting g++. (This was not at all the case 10 years ago.)

  4. Eamon Nerbonne Says:

    @Frode: the language makes a huge difference to the ability of the compiler to remove redundant code, however. Java-style everything is a reference semantics make it for instance difficult to avoid pointers everywhere. These take up space, and they can easily reduce memory locality, which reduces performance. This is the reason that porting to 64-bit generally leads to improved performance in C++ (more registers, wider registers), but worse to comparable performance in java (more bytes in pointers).

    Then there’s stuff like aliasing and more complex dependancy analysis: such operations aren’t cheap; although in theory the JVM could do some of these, you’ll find better implementations in C++ compilers simply because they can afford to take the time and memory overhead to actually run them. It’s also the reason why fortran for a long time outperformed C++ in some numeric code: detecting and dealing with aliasing isn’t easy.

    Finally, I don’t think you appreciate how much more powerful C++ templates are than java generics. In particular numeric code can easily be more maintainable and easier to read in C++ because of the high-level coding style – which comes at no runtime performance cost in C++ (and indeed may even be faster than handrolled loops in practice) when compared to a solution in java which frequently by necessity needs to use hand-rolled loops due to the very real abstraction penalty you pay for generic solutions.

    I’m kind of wishing something like D or even google’s Go might someday take some of java’s good parts (a cleaner type system, fewer historic warts, and the huge one: GC) and put them into semantics more amenable to machine optimization.

    • Bob Carpenter Says:

      @Eamon: Much better put than I could’ve done. I saw you were contributing to Eigen, which is a great example of this kind of programming. As you point out, it’s partly about the static analysis. Which is why very high-level languages like ML or Haskell and low-level languages like Fortran are so efficient.

      The size is mainly what kills me in Java. And as you point out, 64-bit Java just compounds their first mistake to put a lock on every object and a handle. I’ve been pining for C-style structs for years. I wind up coding around them using parallel arrays in Java — you’ll see that all over LingPipe. Objects are just way too heavy. That leads to less than idiomatic Java. But hey, the language was intended for web apps, not operating systems, so it’s amazing they’ve made such heroic strides with the compiler.

      P.S. Crazy small world. I’ve known your dad, John, since the mid-80s when we were both hanging out at CSLI working on event semantics. We spent hours at the whiteboard together working through semantic models. You and I last met in Groeningen right after your family moved there.

    • Frode T Says:

      @Eamon: I was not comparing Java and C++. Java (or .Net in some variation) is quite all right when you already have the cost of a VM and know you won’t run out of memory anytime soon. The “everything is an object” and size is also what kills me in Java. Everything kills me in C++. ;-)

      A GC is not necessarily the wholly grail to programming. I remember having to debug a program which used SUN Java’s CORBA implementation which, when a CORBA exception occurred leaked memory faster than the GC would collect it, accelerating the rate of CORBA excpetions. I prefer RAII to GC.

      C++ templates may be powerful, but also very complex. See my answer to Bob above.

  5. Friday miscellany — The Endeavour Says:

    [...] Why is C++ so fast? Why C++ sometimes outperforms C [...]

  6. Geeks3D Programming Links – July 08, 2011 - 3D Tech News, Pixel Hacking, Data Visualization and 3D Programming - Geeks3D.com Says:

    [...] Why is C++ So Fast? [...]

  7. Frattanto nella blogosfera #14 « Ok, panico Says:

    [...] il C++ è tornato sexy, ecco un post che ci spiega perché è così veloce. Qui un [...]

  8. Twitted by paramaatman Says:

    [...] This post was Twitted by paramaatman [...]

  9. John Ortega Says:

    Hi Bob,

    I totally agree with you on this matter.

    I like Java for the portability also.

    I think C/C++ is the closest thing to native code that you can work with these days (apart from asm). And, the fact that it links code using a dynamic linker at run time to point to the pre-compiled libraries for the specific CPU architecture makes it all the more better.

  10. José Says:

    C++ is not faster than C, is slower, in every single aspect. More important than raw program speed (faster in c anyway) is the development speed, since the most simple program you can write in C++ turns immediately in a gigantic unmantainable mountain of pure shit. C++ should be called C– in fact, since it didn’t improve C in the least, nothing less than the worst programming language in history. Please don’t write code in C++, with my luck probably i will be the one mantaining that titanic mountain of shit that could perfectly be written in a really beautiful and mantainable programming language, like Smalltalk or Clos.

    Alan Kay:
    “Actually I made up the term “object-oriented”, and I can tell you I did not have C++ in mind. “

    • Bob Carpenter Says:

      See my reply to the next comment about why C++ can be faster than C.

      Object-oriented C++ isn’t that fast. It has similar size and speed penalties as Java due to vtable pointers and virtual function resolution. Java uses 4 bytes more than C++ per object because it stores an extra 4-byte reference (for object relocation/synch) in addition to the class pointer, for a total of 8 bytes in addition to the data (assuming a 64-bit JVM). Because Java doesn’t guarantee memory layout, it can reorder the declared class member variables to optimize the amount of padding needed to maintain alignment; in C++, this is up to the programmer to do properly.

      It’s template-oriented C++ that’s fast. I have to agree with you that it’s difficult to understand the library code. But the client code can be very clean.

      Sometimes you just need the speed, so the difficulty of writing the code in the first place is justified. For casual projects, I wouldn’t recommend C++ to anyone.

      If you don’t understand C++ or why it’s so fast, I wouldn’t recommend taking a job maintaining it.

      Why does everyone think Google uses C++ for their search engine? Because they’re idiots? I don’t think so. Because it’s easy to maintain? Nope. Because it’s the fastest thing going and they’re trying to save money on their gazillion-machine server farms and at the same time increase responsiveness to users? Hmm, that sounds about right.

  11. Daniel Kubec Says:

    I really would like to see code in C++ much much more than 10% faster in many cases than what you could easily write in Java or C.

    It’s simply nonsense.

    • Bob Carpenter Says:

      I must not have been very clear about why C++ is faster than C or Java. It’s not because arithmetic is faster (Java used to be terrible, but it got faster; C and C++ are the same) or even array access is slower (again, Java’s gotten way better; C and C++ are comparable). So if you’re talking about writing a bunch of code that only uses arithmetic and array access, you’re right — there’s only about a 10% penalty for Java over C or C++.

      C and C++ have an enormous advantage when it comes to compound data types. For instance, consider writing a complex-number data type. In C or C++, you can use a struct, which is way way faster than a Java object. There’s zero memory overhead for a struct, whereas in Java, there’s a huge cost to allocate, extra memory used for the reference and class pointer (equivalent to a C++ vtable, which you don’t get in a struct), and extra time to deallocate with garbage collection (which can often be done in a second thread, but it’s still consuming system resources if you want to go all out in a multi-threaded environment).

      But C++ really shines when it comes to complex expression evaluation. It’s not really possible to write an efficient matrix arithmetic library in either Java or C.

      Until Veldhuizen introduced expression templates into C++ circa 1995, nobody knew how to do it in C++ either. With expression templates, you can implement efficient versions of matrix operations like a + (b * c), where a is a vector, b is a scalar, and c is a vector. (Think add(a,mult(b,c)) in Java or C, neither of which let you overload built-in operators.) In C and Java, you are going to have to have an allocation on the heap for the result of (b * c), which is going to dominate the cost of the entire evaluation. In C++, you can use expression templates to get around the allocation. It costs an extra constructor, but only uses the stack, and it’s WAY more than 10% faster.

      To see example code, look at the Eigen library’s implementations of matrix operations. There’s really nothing similar in Java or C to compare to, because everyone writes their serious math libs in C++ these days for the reasons outlined above. (Some people still use Fortran, whose static optimizer can do a lot of the same optimizations because the language is less expressive.) Many many many systems still use the Fortran implementations of BLAS because they’re so much faster than C or Java alternatives (for example, NumPy in Python).

      It’s also lots of little things. In C++ (and probably C), you can provide branch prediction suggestions to speed things up. We got around a 10% boost in our algorithmic differentiation library doing that.

      Writing fast C++ takes a lot of effort. Naively written C/C++ won’t be any faster than Java, and can actually be much slower than Java because of Java’s runtime stack-trace-based optimizer (aka HotSpot).

  12. Bob Carpenter Says:

    For more information on optimizing C/C++, I would highly recommend:

    http://www.agner.org/optimize/optimizing_cpp.pdf

    The author has great suggestions for optimizing and explains how the code compiles down to machine code and how the optimizing compilers work.

    He’s anti-templates, though, which he describes as being for eggheads. I’ll cop to that. The beauty of templates is that they move computation from run time to compile time.

  13. Artificial Intelligence Blog · More Machine Learning Blogs Says:

    [...] Bob Carpenter’s LingPipe Blog Natural Language Processing and Text Analytics – Full of interesting stuff [...]

  14. Arturo Says:

    There are at least two things you didn’t mention and that also make C++ faster than C.

    The first one is function inlining, and the second is that C++ is much more strongly typed than C, which provides far more information to the compiler, which is able to optimize code regions that would be impossible with C.

    • Symbo1ics Ideas (@Symbo1ics) Says:

      C has had function inlining for decades. C and C++ have always been compiled by essentially the same compiler, even in the CFront days.

      • Bob Carpenter Says:

        C and C++ compilers may share a great deal of functionality, but every legal C program is not legal C++. For instance, see:

        http://www.cprogramming.com/tutorial/c-vs-c++.html

        Unfortunately, C++ isn’t that strongly typed. It’s hardly Fortran or ML/Haskell. The lack of strong typing gives you a lot of control in how the bit/byte-level code plays out and lets you manipulate it in the programs, but it does inhibit what you can optimize.

        Inlining is something both C and C++ do.

        Java’s HotSpot compilers can even figure out what to inline at runtime based on performance profiling.

        There are now some adaptive C++ compilers that can choose what to inline based on profiling runs.

      • Symbo1ics Ideas (@Symbo1ics) Says:

        I’m aware of all that, especially its typing and abstraction limitations, which is why I prefer modern languages with more expressive type systems for almost all tasks. C/C++’s last niche is an ice floe and the oceans are getting hotter.

        Strong typing has compelling benefits for low level work as well. See: BitC, Idris, Epilogue, and many other modern systems aimed at systems programming. The idea that “C is ideal for kernels and drivers” is something we will find as laughable in 20 years as kids today find it hard to believe that business applications were commonly written in assembler—as recently as the early 1980s.

      • Bob Carpenter Says:

        I’m not sure which languages you mean — ML or Haskell or similarly strongly typed functional languages?

        What depresses me is just how much people love untyped (or at least undeclared type) languages like Python and R and MATLAB.

        I don’t know that anyone thinks C is ideal for kernels/drivers, just that all things considered (like can you find a Haskell programmer who wants to develop a kernel), it beats the alternatives.

        People were saying the same thing about C more than 20 years ago, but it’s still here. Assembly language is still here, too. I think I read somewhere recently that the Visual Basic share of the app market is growing.

  15. studentri23 Says:

    Wow really nice blog. I’m impressed. I’ve just started to write C++ Tutorials so if you are interested please check my blog. Thanks in advance. http://megacplusplustutorials.blogspot.com

  16. SusanR Says:

    Java can be very fast but also fast at much less development cost than C or C++ programs, but one area where C and C++ always win over Java (at least in my benchmarks) is memory usage – if use of memory must be minimised then C/C++ programs can often be made that use half the memory of an equivalent Java program. Personally, I’m ok with that trade-off: Memory is cheap and abundant for most purposes whereas development time is a big deal.

    • Bob Carpenter Says:

      I think there are three reasons for Java being heavier in memory.

      1. There’s no Java equivalent of the lightweight C++ non-virtual struct/class. This has been one of my biggest gripes with Java to begin with. What we do in LingPipe to mitigate this issue is to use parallel arrays. So where in C++ you might have an array of complex numbers, in Java, you’d want two arrays, one of the real component and one of the imaginary component. At that point, if the arrays are any length at all, the memory’s roughtly the same.

      Also, packages like java.util are very object heavy, whereas the equivalent in C++, the STL, lets you have collections with primitive types. Of course, you can use a Java primitive type collection lib (I don’t know of good, liberally licensed ones, though — only the GNU stuff).

      2. The Java virtual machine allocates some memory for itself, which only makes a difference for very small programs.

      3. The Java virtual machine allocates arenas for memory for garbage collection to make GC faster. This usually also isn’t an issue if the program is large and uses simple data structures like arrays.

      Once you start having to work around Java’s limitations, development time in Java can actually exceed that in C++.

      I’m OK with the tradeoff, too — LingPipe is Java, and I don’t regret that decision. It’s not just dev time, but the portability (I guess these are related if you’re trying to write portable C++). Also the library availability for web-related and text-related processing sealed the deal for Java. Not to mention a good threading model.

  17. Christian Says:

    Firstly; great blog, and nice discussions!

    Secondly; there is one more area where the limitations of Java are starting to shine through: parallel programs.

    Since the Java compiler is free to decide data layout, you can end up with compiler-induced false sharing. This can take your performance from near-linear scalability to a full-blown slowdown. In some cases it’s even unresolvable without redesigning your program, usually killing the “natural” object structure.

    In C/C++ false sharing can always be resolved, even if it may need padding. False sharing scenarios also clearer than in Java, especially to newcomers of parallel programming.

    Furthermore, Java seriously lacks a alternative to OpenMP, where you can parallelize small, but important, blocks of code with nothing more than a couple of pragmas. Parallelism in Java is almost as fiddly as going straight to Pthreads.

  18. Bob Carpenter Says:

    This wasn’t meant to be a “limitations of Java” post!

    I’m not sure what you mean by “false sharing”. Is there a simple example or a reference to something more tutorial I could follow?

    I like the fact that Java has a built-in notion of thread (though putting a lock on every object seems like madness from a memory perspective). And I really like util.concurrent way more than anything I’ve seen in C++, such as the Boost thread libs. But I haven’t done as much threading in C++ as I’ve done in Java.

  19. R McRee Says:

    Bob–false sharing is cache contention due to data structure layout:

    http://en.wikipedia.org/wiki/False_sharing

  20. stereomatching Says:

    Nice post, but the title “C++ is Faster than C!” is a little bit misguided.The speed of c and c++ should be equal(+-5%).
    TMP is cool, stl is amazing, boost is splendid, but we could use c
    to produce the same result, same speed with more hand written codes.

    But I do agree that c++ is easier to write fast codes than c, it is hard to find a c programmers who is capable to write the codes efficient than stl(or other c++ standard library), even an expert of c.But any average progammers of c++(like me) can generate fast codes with the helps of stl and other neat features by c++ without mess up with those ad-hoc programming skills of c(especially macro, c progammers like to use macro to mimic template, but macro is harder to maintain and read than template)

    • Bob Carpenter Says:

      It’s the “more hand written codes” that’ll get you every time.

      The issue’s really that there’s no way within the object language of C to express a lot of these concepts. So you can’t write a fast templated matrix lib the same way as you can in C++. At least not without writing your own preprocessor.

      Going one level up, there are constructs in functional languages such as functions-as-first-class-objects and lazy evaluation that are really hard to code in C++ because you can’t do it directly in the object language. You wind up with something like the Phoenix lib in Boost, which is limited because you’re essentially overloading parts of C++ for expression templates, compared to a functional language just having it all in one go.

  21. Scott Meyers Says:

    Very good article. Very nice observations. C++ is way faster, Java is way faster to code your application on.

    • Bob Carpenter Says:

      I would’ve said the same thing when I started. And of course, others will say that Python is to Java in this respect as Java is to C++.

      Now that I’m a few years into C++, I’m no longer finding it takes so long. And I think the auto typing in C++11 is goig to be a game changer, makig it easier to write templated C++ code types than Java generic types.

      The Java libs are great, and there’s really no equivalent in C++, either — Boost is good, but compared to the Javadocs and tutorials for Java, it’s very inscrutable.

      Also, you have to be careful in order to write a C++ program that’s faster than Java. This wasn’t always the case with Java, and I think Java’s bad rep from the first few releases have dogged it through its lifecycle. But Java 1.7 is a whole different beast, and for naively written programs is as fast or faster than C++ (the hotspot unfolding the JIT does is just awesome in Java).

      The one thing I can say is that Java is way better for portability. Not deep-down portability, as in “can I port program X to platform Y”, but in terms of how easy it is to make something and distribute it that works cross-platform. Porting C++ programs is a huge pain, especially for Windows because the toolchain there (make, compiler, assembler, linker) are way more brittle and resource-hungry than on Linux or Mac OS X.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

Join 811 other followers