Language Learning Material and Performance in Off Topic

Page: 1 2 3
ID:181411
 
Aug 1 2010, 9:56 am (Edited by moderator on Aug 1 2010, 10:29 am)
Edit: Continuation from a topic discussing good/poor documentation of languages and APIs.

Very right. C++, Java, etc. have a lot of good material out there. Java's API is actually so well put together that someone can learn the language after mastering basic programming logic just by looking at it.

As for Java, it's got an excellent tutorial trail, but C++... There's a lot of resources out there, but Microsoft's examples are flat-out terrible.

Let's be honest here, take a look at the MSDN resources and tell me BYOND's are bad, because I've actually had MSDN not only be poorly written, it's led me in the wrong direction pretty often. As for most C++ tutorials, I just wrote a skeletal animation library for a custom file format for my employer, and almost every resource that was out there was incorrect as hell. They were telling me it would be faster to do everything in two recursive loops to simplify the math, but I wrote my own low-level matrix math library and wrote a single iterative loop using look-forward transformations.

According to all the material out there on the internet, my program either A) will give inaccurate numbers, will consume more memory, and consume more CPU, or just plain won't work because it isn't recursive. None of these is the case.
#1 Aug 1 2010, 10:00 am (Edited on Aug 1 2010, 10:30 am)
The worst bit still with C++ tutorials is they teach you C + classes + basic STL use. The end result is you repeat the very C based pitfalls that C++ was designed to mitigate.
#2 Aug 1 2010, 10:11 am (Edited by moderator on Aug 1 2010, 10:30 am)
In response to Stephen001 (#1)
Stephen001 wrote:
The worst bit still with C++ tutorials is they teach you C + classes + basic STL use. The end result is you repeat the very C based pitfalls that C++ was designed to mitigate.

Yup, and the worst part is C programmers are now writing Java tutorials. I rewrote a file I/O system the other day that was still doing things byte-by-byte (which is horribly slow in java, and is the way things are handled in C). I then rewrote it to be a buffer using a tokenizer stream, and then benchmarked it against a similar byte-by-byte file reader written in C.

Interestingly enough, the Java program actually ran faster than the C program, because I was using a piece of the Java Natives that was written in a lower-level way than the C equivalent.

I find it immensely hilarious that most of the reason that Java is thought to be slower than C++ by a factor of ten is because C-methodology is simply holding the programming world hostage, and refuses to let go. In many cases, I've found Java to be faster than the equivalent C program at maximum efficiency.

I did almost get myself in trouble though, with one of my superiors at work... He told me that I was wrong about this, and then when I gave him a benchmark on disk to take back to his desk, and told him he just didn't know how to program properly (when he'd been programming three times longer than I have, and had a Master's...) Luckily, he was pretty good about eating his words or I probably would have made an enemy in one of my bosses...
#3 Aug 1 2010, 10:27 am
In response to Ter13 (#2)
Java interestingly will hold up well against even quite effective C and C++ too, thanks to HotSpot. HotSpot has the benefit of being able to JIT compile your Java bytecode for the exact CPU you are on, not just the general architecture. So it can fold into MMX / SSE registers unlike standard x86 could, for example. Your CPU has an unusually small L2 cache? No problem, HotSpot will just align the structures differently to avoid cache misses etc etc.

If you don't mind, I'll split this into a new topic, off in Computers and Technology.
#4 Aug 1 2010, 10:37 am
In response to Ter13 (#2)
As a matter of personal curiosity (being a software engineer myself), what do you develop?
#5 Aug 1 2010, 10:39 am
In response to Stephen001 (#3)
Not at all, I was starting to feel bad about the thread derail anyway, but it was too good a conversation to leave alone. Thanks!
#6 Aug 1 2010, 10:57 am
In response to Stephen001 (#4)
Well, I got hired pretty recently (still under NDA, and my name still hasn't been put forward as a part of the project, so I'm keeping the name of the company pretty well away from my tongue), because of something I sent the CEO of a company... A bit of a suggestion on their project (It's an MMO), and when the CEO responded, we got in this back and forth about methods of doing something that was in my suggestion... So after the conversation, he told me a bit about his system's architecture, and then told me that if I wanted to write the system, he'd be glad to consider it.

I've just finished my B.S. in Software Engineering, but my real focus is videogame development. I try to focus on server development, but right now I'm doing client work, mostly within an outdated 3D engine...

In my spare time, I've been working on a modern 3D engine in Java that uses a custom model format to allow for interactions that are very similar to the Emotion Engine and some of the Havok Behavior project's features.

I actually had a chance to work for RockStar (San Diego) a few years ago, but at the time, I was in the military, and my degree was still unfinished. Since I didn't have a degree, they were going to pay me less than the job offer was put out for (since they called me after I had talked to one of their Personellists asking about a job posting and their requirements). The pay was less than what I would have liked, though, for living in Sand Diego... So I likely wouldn't have been able to survive out there without a roommate.

Right now, though, I'm really just being "trained" to work within the existing tools and codebase for the client of an MMO. It's written in Java, and the company needs as much help with their graphics engine as they can get... Seeing as most of their programmers are C programmers who learned Java as a syntax instead of a language. Most of my "training" has been me asking "So... You know that there's far easier/faster ways of doing this, right?" or "Why the hell are you guys doing it this way?"

Most of the guys I work with don't actually understand Game development at all, and are from the application development field, and the CEO started out as an indy developer whose first pet project was so wildly successful that he thought how he'd done things was the correct way, and never met the brick wall of failure like most programmers do.

I don't work in C very often anymore, and if I do, it's to work on a JNI module... I really want to actually work on a Java Interface that's essentially a 3D scenegraph tool for OpenGL/DirectX, but I've got too much work on my plate at the moment to start on that. JOGL is fast enough for my tastes when done right. Until the day comes that we're using some really advanced techniques, it's not going to be necessary to write my own interface.
#7 Aug 1 2010, 8:20 pm
In response to Ter13 (#2)
Ter13 wrote:
Interestingly enough, the Java program actually ran faster than the C program, because I was using a piece of the Java Natives that was written in a lower-level way than the C equivalent.

Depends on programmer actually, but C/C++ is faster than Java, because Virtual Machine can't be faster than original system.
#8 Aug 1 2010, 8:48 pm
In response to Ripiz (#7)
This is actually quite untrue, and is only widely considered to be true because it's widely considered to be true.

Java actually has a JIT compiler that actively compiles the program as it runs. into a processor-specific set of instructions for the user's machine. C actually compiles down to assembly.

Java's JIT compiles down into Machine code, and caches functions on demand, so that the entire instruction set can actually be interpreted only once, but run many, many times.

Machine code is actually a degree faster than Assembly. Why is this? Because an Assembler is used to translate assemly language into the machine-specific byte code at runtime, wheras Java automatically does this for specific methods.

Basically, here's the rub:

Java has an initial speed loss from the runtime compiling and interpretation. It also doesn't access OS-specific data very well the first time. JIT actually secures OS-dependent calls and speeds them up after the first time, having passed all the JVM security checks once already.

However, over a significant period of time (after about ten seconds or so), I've seen Java not only perform comparably to C, but outstrip it given the most efficient methods in either language.
#9 Aug 1 2010, 8:49 pm
In response to Ripiz (#7)
It's important to note that half the time Java isn't executed in the JVM, but is JIT compiled. In some cases, this does result in a faster solution than C++, as the JIT compiler can make use of CPU specific features that the C++ compiler can't guarantee will be there ahead of time, like SSE, SEE2, SSE3 etc.

For a C++ programmer to use these features he must build drop-in replacement object code specifically for such a CPU, or risk losing architecture ABI compatibility.

Add to that the ability of HotSpot (the JIT compiler) to do escape analysis, site activation profiling etc and optimise further from being able to see the Java byte-code get executed before converting it into binary for subsequent executions.

Here's a few recent(ish) shootouts that demonstrate HotSpot's ability to produce faster code than C++ for some patterns. Interestingly all of the people doing these tested hit optimisation issues because HotSpot noticed how trivial some of the tests were and optimised them away, a trick that even profile-assisted C++ can't do.

http://zi.fi/shootout/
http://scribblethink.org/Computer/javaCbenchmark.html
http://www.stefankrause.net/wp/?p=4
http://www.javaperformancetuning.com/news/qotm042.shtml (some talk on why this happens)

Again I'm keen to point out that this phenomenon is a result of the fact the common notion of "Java runs in a VM" isn't actually true for many usage scenarios.

The more you know...
#10 Aug 1 2010, 8:53 pm
In response to Stephen001 (#9)
I'm quite partial to the "The Java is Faster than C++ and C++ Sucks Unbiased Benchmark"

Quite tongue-in-cheek, that.
#11 Aug 1 2010, 8:56 pm
In response to Ter13 (#10)
Heh. I suppose to be fair to C++ you can perform template meta-programming to shift some static analysis of some specific problems over to the compiler to optimise. But I'll be damned if I've met anyone else that can do it.
#12 Aug 1 2010, 8:58 pm
In response to Stephen001 (#9)
Using optimizations in Java and not using them in C++, then saying Java is faster is just stupid. All those tests optimized only Java. Also those tests seem to use gcc, which outdated last century, while they use latest available Java version.
#13 Aug 1 2010, 9:05 pm
In response to Ripiz (#12)
This is untrue, once again.

GCC was updated less than 48 hours ago, as it so happens.

Ripiz, not to be rude, but you are better off not making statements that are clearly untrue here.

Also, GCC has compiler optimizations. Look at the links Stephen posted. They used multiple methods of Optimization.

Perhaps you would have been better off pointing out that Java on average uses between 3 to 6 times as much memory as C. Surely you don't imply that Visual C++/C# has replace GNU C++ as the primary development environment for C programmers? If so, you're going to have the majority of the programming world shouting things about Linux and compilers not costing money.

We're not saying Java is better than C, merely that it has been slandered over and over again by C programmers who do not understand the unique quirks of Java, and how to work within them.
#14 Aug 1 2010, 9:19 pm
In response to Ter13 (#13)
I used gcc before myself, it was not only slower at compiling than Visual C++, but execution too.

Memory is different thing, maybe programmer/Java doesn't free unused memory so it doesn't waste time removing bits, which C++ does right away unless it's pointer.
#15 Aug 1 2010, 10:38 pm
In response to Ripiz (#14)
Actually, garbage collection in C++ is not done automatically. However, deallocation of data can be much less efficient in Java, since there is no direct method of control, and Java doesn't support block-based memory allocation with all datatypes. However, this can be gotten around with buffers. Buffers are a much more C-like method of memory allocation.

Part of the problem of Java in reference to memory is that Java relies heavily on a fully class-based model, and there are no memory pointers in Java. Booleans in Java take up 8 bits of space in memory as well, so there are a lot of problems with benchmarks that rely on binary mathematics.

Actually, interestingly enough, there are several benchmarks that still attempt to unfairly compare binary math in Java, when it's actually much more efficient to store bits in a larger datatype and then do the calculations 8/16/32/64 bits at a time.

But that's a story for a different day.

As for Java's garbage collector, it's convenient, but it can cause some serious issues if you don't force it to act regularly, and you have to be much more careful with your data, as Java's heap tends to get a little cluttered if you aren't keeping Java's memory-gobbling habits in mind when utilizing it.

For instance, if you have allocated an Array of Objects in Java, the garbage collector will run through the collection, and deallocate all objects inside of the collection (including all the members of this class, and their members and their members ad infinitim, and then it drops the array itself.) Whereas C++ would simply drop the memory location completely, then snips any hanging references that are members of the class. It cuts out a significant bit of work compared to the Java machine.

So yes, garbage collection is something of an issue in Java, and yet another reason Java is oft-slandered unfairly, as most of this can be gotten around just by planning ahead.
#16 Aug 1 2010, 10:50 pm (Edited on Aug 1 2010, 11:00 pm)
In response to Ripiz (#12)
You may not have noticed, but the third link uses Intel's C++ compiler on Intel hardware, which is pretty much the best compiler out there for CPU-specific optimisation on that platform.

Te13 already covered the obvious issue with your statement about GCC as well. Ironically GCC's 3.8.x line (which is much older than Java 1.6uX) is actually a much better performer than GCC's much newer 4.4.x line, almost on par with Intel's ICC. So using the older compiler line is actually a good attempt to be more fair to C++.
#17 Aug 1 2010, 11:29 pm
In response to Stephen001 (#16)
I'd like to point out something both fitting and anecdotal.

We, as humans tend to make most of our conclusions based upon our first impressions. This is not only true of our impressions of people, but of everything we encounter.

This is a huge problem in the software world. If a videogame, library, platform, etc. Flops on a user's first go, it's going to forever taint their experience with that product. Since Java started out with many of the problems Ripiz pointed out, and Ripiz likely understands most of these problems by hearsay, it's permanently tainted his impression of the language itself. (For instance, most people see BYOND's game selection being a bunch of god-awful Zeta clones, and assume the development tools are equally as clunky and broken as the games themselves, and are forever turned away, even after years of progress and development on the engine.)

Further evidence of this having occurred is Ripiz's misconceptions about GCC, which are once again, based on prior experience, and not experience with the current product, as well as gross misrepresentation of the paid-software world (often the loudest shouter in the throng, while not always the most correct.)

Despite the fact that we know that something we are expected pay for is likely to be in some way sensationalized or misrepresented in order to increase sales, we still cling to the oftentimes wrong impression that monetary value implies craftsmanship, when in fact, craftsmanship is the only thing that implies craftsmanship.

Now, back to the Java problem. Java especially suffers, because it's under constant development, and it's always getting better, but early on, most of your "paid software folks" were pretty brutally digging at it, and those who used it. Calling Java developers "Weekend Programmers", "paid amateurs", or just plain "backwards".

I would also like to point something about about the backwards point of view. Java is pretty prevalent in today's business market, professional gaming is rapidly moving to Java, military and government sectors are readily using SUN and Java technologies, application developers are jumping on board because of the cross-platform workflow, and there are now more people learning Java at a much more rapid rate than there are learning C++ in most fields. If you still want to make the argument that Java is indeed, as yesterday's programmers have said, "backwards", I would argue that you are turned around, and trying to find tomorrow's technology in yesterday's world.
#18 Aug 2 2010, 12:17 am (Edited on Aug 2 2010, 3:16 am)
In response to Stephen001 (#9)
At least the first of those shootouts demonstrated that C++ is faster than Java excepting stupid examples geared specifically towards Java.

Java will never catch up to a real programming language for any serious task. It's not just the VM issues, although those apply and, despite JIT, are real. Further issues are the terrible mess that is the Java API, which appears to be designed by someone who'd just read a book about patterns and felt compelled to use them everywhere (Why are there so many factories?), the difficulty of writing fast Java relative to the difficulty of writing fast C, and last but not least, because it's a bloody frustrating bondage-and-discipline language. If I'm paying the price of running on a VM and losing low-level control of my code, I want to get something out of it - specifically, I want dynamic typing.

(Also, well-written C is so much more portable than Java of any stripe. I can recall a number of Java programs I ran into at uni that wouldn't run properly on one of Linux or Windows because the API did things slightly different on each platform. GUI is a particular problem here.)

Maybe it's time for someone to write "Why Java is Not My Favourite Programming Language"

EDIT, MUCH LATER:
Also, JIT techniques are just as applicable in C++. See, for example, the software renderer being developed by Michael Abrash, which dynamically compiles sections of its rendering pipeline at startup to suit your machine.
#19 Aug 2 2010, 12:33 am
In response to Ripiz (#14)
I use visual C++ regularly at work. It drives me absolutely bonkers on a regular basis, for a number of reasons:

- Lack of C99 support. This one hits me again and again and again. You never really realise how much of C you use on a regular basis until you discover that you don't have snprintf, isnan, or a bevy of similarly innocuous little functions.

- Deliberate incompatibility. There are a number of functions that the compiler will throw a hissy fit about, like snprintf, claiming that they're terribly unsafe and you should use the (microsoft-specific) blahblah_s function instead. Right. You're just looking after my safety. Fortunately, you can toggle a switch to shut the compiler up, but it's still incredibly annoying.

- Intellisense is great when it works, but it usually doesn't. Personal favourite errors include showing me a function signature consisting of about 160 commas and nothing else, showing an entire header as greyed-out because it was under the impression that the include guard was preventing it being compiled (this wasn't the case), and generally being useless the instant you type a few characters.

- It's terrible at resolving ambiguous overloads. If it has to cast to work it out, it doesn't seem to be able to work out:

<pre> class A { A(char*) {} }; class B { }; class Test { void foo(A param){} void foo(B param){} Test() { foo("Some text"); // Ambiguous or not? } }; </pre>

I've seen no speed benefit from Visual C++ (actually, GCC seemed to produce better code), with the specific task being to draw ESRI shapefiles containing millions of points.

GCC compiled faster, too, although there wasn't enough code that it would be that much of a benchmark.

Minor gripes: Max level warnings are impossibly pedantic (Yes, I know it's an unused parameter. I meant to not use it.)

Considering that the previous mandated IDE was DevCPP, Visual C++ is a definite improvement, but it has some serious issues. Personally, I'd be happier with a text editor, GNU make, and gcc.
Page: 1 2 3