vb.net ... why bother?

[razzle]

this is quite contradictory ...

No it's not. The performance of Java or C++ (or any language) is unrelated to any sub-systems you may use.

For example if you use OpenGL with Java or C++ that may improve the 3D graphics performance of a program written in one of those languages but it won't improve the performance of the language per se.

[superbonzo]

ouch, yet another ruzzle-misses-the-point-moment ... silly me that I always get into these discussions ...

[OReubens]

Well, if someone claimed Java is faster than C++ (and everything else is BS) I would've asked them to prove that too. When you make a claim you have the burden of proof.

the analogy is flawed.
I can show you an example that will have C++ perform better than java. That doesn't actually proove the general case.

Prooving a truth is often extremely hard or even impossible. Usually it boils down to "general acceptance", "dogma", "axiom" or however you want to call something that is simply taken as a fact.

However it is easier to DISPROOVE a theorem by showing a single example of the countrary.
As I said, NOBODY has to date been able to show me a satisfactory case where Java was faster for an equivalent implementation in C/C++. Show me a case that does, and I'll show you a flawed implementation in C++.
Yes, there's been bad examples enough but for various reasons they didn't qualify. Like I said, the only case that will fly is if you HAVE TO do a lot of interfacing with other java code, then writing the code in java will win simply because of not needing to marshal between native and vm and datatypes.
So I'll stand by my case.

And I would say that if performance matters... 10% is significant and not unimportant.

I'm not saying languages like Java and C# have no reason to exist, they obviously do, and I pointed out that easer integration and faster UI development are part of it (mainly because both C# and java are application frameworks, wheras C++ is "only" a language with a basic library).

Please feel free to provide just one single recent article or blog or test or scientific paper to the contrary.

Someone already did so.


and if you want to throw "big names" around. here's one by Andrei Alexandrescu:
“The going word at Facebook is that ‘reasonably written C++ code just runs fast,’ which underscores the enormous effort spent at optimizing PHP and Java code. Paradoxically, C++ code is more difficult to write than in other languages, but efficient code is a lot easier.”


Quite frankly,
- VM code needs to be interpreted and will be slower, period.
- While JIT compilation has evolved, it can't possibly compete with native compilation. JIT compilers have other requirements and other compromises that juwt "by design" will make them produce less efficient code than a static compiler can produce.
- The garbage collector, while it may make your life easier for some bits. It's the biggest problem when you're dealing with performance because you simply cannot control when it can't do a maintenance cycle.
- and YES, I am aware that there are a very small amount of programming challenges where a GC allows you to approach it conceptually different and seemingly pull ahead of 'something similar' in C++. But then the flawed C++ idiom is obviously that you should have written a GC for C++.

Maybe it's because everybody knows you don't know any Java so no one bothers to ask you about it.

Actually I do.
And I have done plenty of jobs at performance boosting java, C# and VBS apps. IN a few cases this involved writing parts in native and linking to it, but more often than not, it's about avoiding the very same kind of bottlenecks as I have to deal with when doing the same for C++.

However, for performance projects were I was involved at the start "it needs to be in java/C#" just never occurs. "it has to be in C/C++ or Fortran or ...." otoh DOES occur.

There are many reasons to pick one language over the other but in my book it roughly boils down to this: Java is easier to program and maintain whereas C++ is easier to use with all sorts of sub-systems.

I'm not disputing this. (Though I do have reservations about the "easier to maintain").

Performance wise they're equivalent.

They aren't. For some cases they're close.
Sometimes it may seem that way because of the framework.

but to date I have not seen actual proof otherwise. But I have seen more than one case where C++ flat out beat the pants off java.

[razzle]

ouch, yet another ruzzle-misses-the-point-moment ... silly me that I always get into these discussions ...

It would be more upstanding of you to just admit you have been wrong.

[razzle]

So I'll stand by my case.

By all means, keep standing while the rest of us are moving forward.

There are areas where C++ outperforms Java, notably scientific style number crunching where Fortran traditionally has been used. Another area where C++ clearly beats Java is systems programming where C++ basically is used as C with classes. It's not for nothing most Java virtual machines are written in C++.

But Java is not far behind and sometimes even ahead of C++ as recent micobenchmarks show. These benchmarks have become fewer and fewer though. It's not so fun anymore now that Java, the former punch bag, is standing up and hitting back.

In most other areas do Java and C++ perform equally well. The reason is the enormous research and development effort that has gone into mainly three parts of Java: the static Java compiler (from Java to bytecode), the dynamic JIT compiler (from bytecode to native code) and the garbage collector. I come to that next.

Quite frankly,
- VM code needs to be interpreted and will be slower, period.
- While JIT compilation has evolved, it can't possibly compete with native compilation. JIT compilers have other requirements and other compromises that juwt "by design" will make them produce less efficient code than a static compiler can produce.
- The garbage collector, while it may make your life easier for some bits. It's the biggest problem when you're dealing with performance because you simply cannot control when it can't do a maintenance cycle.
- and YES, I am aware that there are a very small amount of programming challenges where a GC allows you to approach it conceptually different and seemingly pull ahead of 'something similar' in C++. But then the flawed C++ idiom is obviously that you should have written a GC for C++.

What you say was true 20 years ago when Java was introduced but not today.

Java today essentially is a compiled language. Java applications execute native code where it counts. The static Java compiler is as good as any C++ compiler and the dynamic JIT compiler can perform additional optimizations based on runtime characteristics that's out of reach for a C++ compiler (even though attempts have been made to come close by way of so called Profile-Guided Optimization).

The Java garbage collector is extremely sophisticated and fast today. There are no long pauses. And clever compiler techniques such as Escape Analysis even allow the garbage collector to be bypassed altogether in many allocation scenarios.

As you may have noted C++ has introduced reference counting smart pointers. One big reason is that to be palatable, object orientation and functional programming require dynamic memory. Of course garbage collection takes time but so does C++ style dynamic memory management. You mentioned Andrei Alexandrescu. He has recently abandoned C++ for a language he considers to be better namely D and can you imagine, it has a built-in garbage collector!

To summarize my view:

* C++ is faster and better than Java in scientific style programming where it competes with Fortran and in systems programming where it's used as C with classes. This is why so many subsystems are written in C++.

* In all other cases, the majority of applications, Java is as fast as C++. The Java advantage is that it's easier to program in the object oriented and functional paradigms. The main reason to still use C++ is because it's easier to integrate with external subsystems.

* And last but not least, Java has a greater potential than C++ for automatic multicore utilization without any active measures taken by the programmer. This free lunch situation gives Java a clear performance edge over C++. Already today a C++ programmer must be more highly skilled than a Java counterpart for the same result and with multiple cores in the equation this gap is likely to widen.

[superbonzo]

wait, I got it it's a joke, like the Chuck-Norris-Facts meme ... now, my turn, ehm ...

Java makes you feel better
Java makes you more attractive to the best girls
Usain Bolt used Java to outperform his opponents at the last olympics
the FED helped US economy by injecting billions of Java in the private sector, the EU sadly used C++ instead
Beyonce wrote her last hit with Java
whatever C++-conspiracy theorists say, no moon landing would have been possible without Java
...


sorry, but ruzzle's contribution to this thread is so full of non sequitur, ex falso and all sort of unchecked/uncheckable statements/facts to be impenetrable to any form of intelligible counterargumenting. Resistance is futile

[razzle]

sorry, but ruzzle's contribution to this thread is so full of non sequitur, ex falso and all sort of unchecked/uncheckable statements/facts to be impenetrable to any form of intelligible counterargumenting. Resistance is futile

The Java vs. C++ question is never going to be settled by a mathematical proof as you seem to think. It's a complex situation involving many conflicting and disparate factors.

In this thread I've argued from the standpoint of someone who has actually made a decision as to which of the languages to use. Not just in theory but for an actual very important and big project. It doesn't happen every day. Most of the time the language is a given.

I've used both languages extensively and equally much so I know it's not as simple as "C++ is faster than Java and if you don't agree you're full of BS" as someone argued in this thread. I really get pissed off by such simplistic and ignorant arguments.

I don't prefer Java as you seem to assume. I'm completely neutral to the languages and I have no external concerns or obligations to weight in. I just wanted the best language and contrary to what you might have expected, after a long decision process I picked C++. So you were wrong even this final time, weren't you.

Judged by your last post you seem somewhat wanting when it comes to complex decision making. Why don't you buy a season of The Batchelor on DVD and binge-watch it. You may learn a thing or two. Good luck.

[VB6 Programming]

I have spent the last 4 months converting my project from VB6 to vb.net and expect it to take almost to the end of 2014 to complete the conversion.

I have done this because all the propaganda tells me that I should. And because I am concerned that at some point in the future Microsoft will abandon vb6

VB6 programming is fine on the Windows 10 technical preview. Both the runtime and the VB6 IDE work. Obviously we will have to wait until the final release of Windows 10 to be certain, but it looks like VB6 programming has a future well beyond the current 2024 end-of-support date.