• Quick note - the problem with Youtube videos not embedding on the forum appears to have been fixed, thanks to ZiprHead. If you do still see problems let me know.

C/C++ vs. Java vs. C#

I use Python (with Numpy/SciPy/Matplotlib) for damn-near everything.

But, then again, my most of my codes have a very small distribution and are internal to my work projects.
 
roger said:
<snip>
C++ has the 'problem' of pointers and unchecked casts, a problem that never materializes if you use them appropriately, and use other features of the language intended to avoid the real problems of pointers and unchecked casts.
Click to expand...

C++ also has dynamic_cast, which does type-checking at runtime. Never used it though ;)

Great posts roger, you make my posting here quite obsolete, as our thoughts are mostly the same on these matters.
 
I'm not very familiar with Java, but as far as I know it offers some native threading support. I can imagine that this offers benefits in situations like on server applications.

I'm working in a division that develops some (soft) realtime telco server applications. Most of the codebase is in C++, but one newer application is written entirely in Java. This team claims much faster development cycles, but that's hard to compare directly.

One thing that struck me though was when we got to test out the newest Sun server with their 32-core T1 processor (codename Niagara). All our apps were running on quad processor UltraSparc machines before, so they are all multiprocess or multithreaded. The C++ apps got something like twice the performance compared to the old boxes. The Java app ran at least 8 times quicker. The Java team claimed this was due to the native threading that allowed them to write the application to scale well from the start. On the other hand they've had to search for a decent third-party garbage collector to avoid heavy load spikes when the standard one kicked in every once and a while.

So I'm not sure whether any language is really superior for server apps, but I'm wondering if anyone has more experience with this native threading support in comparison with C++?
 
lauwersw said:
I'm not very familiar with Java, but as far as I know it offers some native threading support. I can imagine that this offers benefits in situations like on server applications.
Click to expand...

I imagine it does, but Java for server applications? I fold.

lauwersw said:
I'm working in a division that develops some (soft) realtime telco server applications. Most of the codebase is in C++, but one newer application is written entirely in Java. This team claims much faster development cycles, but that's hard to compare directly.

One thing that struck me though was when we got to test out the newest Sun server with their 32-core T1 processor (codename Niagara). All our apps were running on quad processor UltraSparc machines before, so they are all multiprocess or multithreaded. The C++ apps got something like twice the performance compared to the old boxes. The Java app ran at least 8 times quicker. The Java team claimed this was due to the native threading that allowed them to write the application to scale well from the start. On the other hand they've had to search for a decent third-party garbage collector to avoid heavy load spikes when the standard one kicked in every once and a while.
Click to expand...

All I have to add to that is that the C++ apps must have been written wrong.

lauwersw said:
So I'm not sure whether any language is really superior for server apps, but I'm wondering if anyone has more experience with this native threading support in comparison with C++?
Click to expand...

Who says C++ doesn't have native threading support? What do you mean by native?
 
laca said:
All I have to add to that is that the C++ apps must have been written wrong.
Click to expand...

Probably :) Some part of the core was even written for VMS and scalability was kinda bolted on later. So the comparison is maybe not entirely fair.


laca said:
Who says C++ doesn't have native threading support? What do you mean by native?
Click to expand...

C++ threading mainly comes from the Posix API. It's workable, but you have to be careful to protect all your data with locks, avoid deadlocks and so on. If you try to apply that to some of the STL containers, you always end up writing wrapper classes, so you must always put your concurrency at a high logical level. I was wondering whether Java has improved on that in some way (or any other language)?

If not yet, I feel like native threading and support for scalable data containers could be a major benefit to any langauge. The first language to get that completely right will be a winner in the serer space. It's much more likely to end up in Java than in C++.
 
Er? C++ doesn't have threading, that is provided by an operating system API (or a wrapper for that). Threading is very low-level though, so unless the goal is to manually squeeze out every last cycle you can, we're really approaching a point where even lower level languages like C++ require parallelism libraries that let you abstract the dirty work away so that you can just (for instance) call parallel_foreach() and have the iteration split up into several threads and managed automatically.
 
lauwersw said:
C++ threading mainly comes from the Posix API. It's workable, but you have to be careful to protect all your data with locks, avoid deadlocks and so on.
Click to expand...
As jsiv noted, C++ itself has no threading. And strictly speaking, C++ cannot even have threading. The library function strtok is not re-entrant, and errno is useless too if taken literally from the standards definitions in a multi-threaded environment. I know, nitpicking, but the C-standard was not written with multi-threading in mind and C++ inherited that.

lauwersw said:
If you try to apply that to some of the STL containers, you always end up writing wrapper classes, so you must always put your concurrency at a high logical level. I was wondering whether Java has improved on that in some way (or any other language)?

If not yet, I feel like native threading and support for scalable data containers could be a major benefit to any langauge. The first language to get that completely right will be a winner in the serer space. It's much more likely to end up in Java than in C++.
Click to expand...
The Java collections framework (the equivalent to C++'s STL) has many containers in two versions: a thread-safe version and a non-thread-safe version (HashMap versus HashTable for instance).

However, I think the need for a thread-safe collection/container is relative. When you properly design your app, you don't end up with using a bare collection, but using it inside another class anyway - which doesn't just expose all the possible methods of the collection class, but only those aspects of it you actually want to be used. For instance, when you need a stack of some objects, you only expose the pop() and push() methods.

In such a case, you don't want a thread-safe collection, you want the thread-safety on the methods of your own wrapper class.
 
jsiv said:
Er? C++ doesn't have threading, that is provided by an operating system API (or a wrapper for that). Threading is very low-level though, so unless the goal is to manually squeeze out every last cycle you can, we're really approaching a point where even lower level languages like C++ require parallelism libraries that let you abstract the dirty work away so that you can just (for instance) call parallel_foreach() and have the iteration split up into several threads and managed automatically.
Click to expand...

Exactly what I mean in half the amount of text!

So does Java have any parallelism libraries or anything native to abstract the dirty work? Or C#?
 
jsiv said:
Er? C++ doesn't have threading, that is provided by an operating system API (or a wrapper for that).
Click to expand...

That is why I asked what he means by native. Native to the language or native to the OS? The language has no built-in support for threads. But it has access to, well, basically anything from the OS.
 
ddt said:
As jsiv noted, C++ itself has no threading. And strictly speaking, C++ cannot even have threading. The library function strtok is not re-entrant, and errno is useless too if taken literally from the standards definitions in a multi-threaded environment. I know, nitpicking, but the C-standard was not written with multi-threading in mind and C++ inherited that.
Click to expand...

Yes, it can. Even strictly speaking. strok may not be reentrant, but strtok_r is. All library functions which were designed as not reentrant have counterparts that are. And also, there is TLSWP for errno and such.
 
If I remember right, the upcoming C++ standard will have some threading features. Downloading the latest draft to make sure...

The Visual Studio 2010 beta may have basic support for the new standard already.

As for the OP: C? C++? Java? C#? Easy - whatever the company's code is already written in. So for me, C/C++ and Java.
 
Wowbagger said:
I do have more to say about ASP.NET. But, this isn't an ASP.NET thread. So, I'm not sure I should respond to that, here, or start a new one. Hmmmm.... I'll decide a little later.
Click to expand...

A new thread would be awesome. I couldn't get bored debating this.
 
dasmiller said:
A great programmer... [is] ...
enormously more productive than a huge team of average programmers with a few mediocre team leads..
Click to expand...
This is something I was never able to figure out. A supercoder can be easily 20x more productive than an average programmer and churn out much cleaner code. So what's the secret, and how do you find them? I eventually gave up entirely on interviews, qualifications and experience, and just said "show me your code". The great coders whip out 100,000 lines they wrote at home and the not so great mumble something about 'proprietary'. Unfortunately when you impose this filter employment agencies stop sending you people.

RussDill said:
I think the most dangerous individual is one that determines that a large, functioning code base, needs to be rewritten in some other language in one go.
Click to expand...
That's how you recognize a moron.

lauwersw said:
I feel like native threading and support for scalable data containers could be a major benefit to any langauge.
Click to expand...
There's a problem: it doesn't make sense. For example, a thread-safe implementation of STL map<> in C++ runs 100 times slower than a non-thread safe version. But most of the time you want to perform say 10 operations on a map at any one time, and usually you want to access a couple of related data structures as well. It's much more efficient to lock a mutex once, do your operations, and then release. So 99% it doesn't make sense to make containers thread-safe; it's up to the programmer. And in C++ it's foolproof:

void myfunc()
{
guard _g(mutex); // constructor of guard locks mutex
// ..do your stuff...
// ... destructor of guard release mutex, works even if exception is thrown
}

Just two rules: never make external calls with a mutex locked, and always lock multiple mutexes in the same order. This is where Windows' event queue falls down with a big soggy splat.
 
dahduh said:
This is something I was never able to figure out. A supercoder can be easily 20x more productive than an average programmer and churn out much cleaner code. So what's the secret, and how do you find them? I eventually gave up entirely on interviews, qualifications and experience, and just said "show me your code". The great coders whip out 100,000 lines they wrote at home and the not so great mumble something about 'proprietary'.
Click to expand...

The only reliable way I know of is to get students. If by the time they go back to Uni you panic because their hand-over notes are inadequate, you know you've found someone.

dahduh said:
Unfortunately when you impose this filter employment agencies stop sending you people.
Click to expand...

Does it also stop them cold-calling you? We once tried convincing Manpower we only recruited people if they (a) were foreign, (b) had funny names, but it was of no use, they just don't get hints.
 
dasmiller said:
Absolutely. A great programmer with a mediocre language & environment is much more productive than an average programmer with a great language & environment.

And enormously more productive than a huge team of average programmers with a few mediocre team leads working to a schedule developed by a marketing group.
Click to expand...

Absolutely. I was in complete awe of a small team I worked with who built code that was more stable than the base it ran on (somwg which shreiked and died at a minor kernel panic and treated kill -1 as kill -9).
A very few people are like that and can transfer it. I have met many people who were fantastic on a platform that, if you know what I mean, worked the way they thought and were absolute crap on other platforms because "it shoudn't work that way". My current job is salvaging the crap one such wrote and making it work right while still processing the original stuff. I am but a programmer for the working day...
 
You must log in or register to reply here.

Back
Top Bottom