We Keep Coding

Is Java a good choice for a streaming server application?

I'm facing a project with audio streaming, as a client and a server. Would Java be a good choice for the server app?
I've read in other questions that because of performance C++ is the best choice for this kind of app.

If you are more comfortable with C++ or Java, I would use that. You can write a low pause server in either language.
A streaming server is mostly about passing lots of data from A to B i.e. the I/O matters. Unless you plan to compress the stream on the fly, the CPU performance is unlikely to be important.
Even if you are doing on the fly compression and Java isn't fast enough for that, you can call a library (preferably one already written/tested) to do this via JNI and still write most of the server in Java.

shrug It's not a bad choice. While audio streaming does have a performance component, the algorithms/optimizations you make are going to have a much larger effect than the language you choose.
Not to mention the famous Knuth quote "Premature optimization is the root of all evil". Write in whatever you are most comfortable with and check if it's a problem later.

The biggest issue with Java performance, I think, is garbage collection. Without careful consideration to what you're doing, it's easy in Java to write code that needs to pause every so often to clean up. C++ doesn't have that problem. On the other hand, without consideration of what you're doing, it's easy to write C++ code that leaks heap memory (when you forget to delete something from the heap). This is really bad for a long-running process like a server. It's possible to leak memory in Java, but it's related to keeping references around too long, not to anything built into the language.
Although C++ tends to be faster, with modern just-in-time compilers for Java, the performance difference tends to be overstated. Overall Java is probably just as fine as C++ for a streaming audio server. If you find that there's a bottleneck in some compute-intensive section, you can always drop down to C++ using Java Native Interface. But that should only be after identifying a problem with profiling.

If you did want to use java, here would be a great place to find some uses and files for using media in java...

Java, JIT and Garbage Collector efficiency

I want to know about the efficiency of Java and the advantages and disadvantages of Java Virtual Machine and Android.
Efficiency is the low use of memory, low use of the processor and fast execution.
Mobile devices are simpler than PC, then the apps need to be more efficient. Servers receive many connections and they need to be very efficient. Many mobile devices use Android and Java apps, and many servers use PHP.
Can Java and interpreted languages, such as Java Script, Python and PHP, be more efficient than C and C++?
JIT (just in time) advantages:
It can optimize better, because it knows the value of some variables and where it is used or changed.
It knows the processor and can optimize with processor specific instructions.
It is easier to transform functions into inline function.
It can remove known conditional tests and remove blocks that will not be run.
Java disadvantages:
When the app run for the first time, the app will be very slow, because the bytecodes will be interpreted and JIT compiler will do many analysis to find good optimizations. The apps cannot use the maximum of the hardware power. If an app is a game or a real-time app, if it be run for the first successfully and with no delay, but it uses the maximum of the hardware power, then the next time the app be run, it will not use the maximum of the hardware power due to optimizations. The problem is the app cannot be designed to use the maximum of the hardware power after the optimization, because it will be too slow on the first run, and will not continue to run.
Java checks if the array index is not out of bounds, and it checks if the pointers are not null. It will add several internal "if"s to generated code.
All objects use garbage collector, including objects that are very easy to manually delete.
All instances of objects are created with dynamic memory allocation, including objects that can easily use the stack. If a loop iteration begins creating an instance of a class and ends deleting the created object, dynamic memory allocation will be inefficient.
The garbage collector needs to stop the app while it cleans the memory and it is very undesired for games, GUI apps and real-time apps. Reference counting is slow and it cannot handle circular references. Multi-threaded garbage collector is slower and it needs more use of the CPU.

Can Java and interpreted languages, such as Java Script, Python and PHP, be more efficient than C and C++?
It's very difficult to get more efficient than the best C and C++ programs. There's a lot of C and C++ programs that are nowhere near as efficient as that though, and beating them with (modern) Java code is quite practical if you're any good.
I've also heard good things about the current best-of-breed Javascript engines, but I've never studied them in detail.
With Python and PHP (and many other languages besides) it's a bit different. Those languages are written in C, so it's obvious they cannot be more efficient than C (follows by construction). Yet it's much easier to write efficient code in them (i.e., that uses what is in-effect a very well-written C library) than it is to start from scratch. In particular, it reduces the number of defects per program. That's a very important metric in practice; anyone can produce fast code if it's allowed to be wrong.
In general, I advise not worrying about getting maximal efficiency. You run up against the law of diminishing returns. Instead, use sensible overall algorithms (or, as a friend of mine once said to me, “look after the big O()s and let the constant factors look after themselves”) and focus on the question of whether the program is good enough in practice. Once it is, stop fiddling around and ship it!

Let's pick apart your claimed disadvantages:
When the app run for the first time, the app will be very slow, because the bytecodes will be interpreted and JIT compiler will do many analysis to find good optimizations. The apps cannot use the maximum of the hardware power.
JIT compilation is an implementation issue. Not all platforms do it. Indeed, the Android platform could be modified to 1) do ahead of time compilation, or 2) cache the native code produced by the JIT to give faster startup next time you run the app.
It is interesting that various Java vendors have tried these strategies at various times, and yet the empirical evidence is that plain JIT is the best strategy.
Java checks if the array index is not out of bounds, and it checks if the pointers are not null. It will add several internal "if"s to generated code.
The JIT compiler can optimize away many of these tests. For the rest, the overheads tend to be relatively small; e.g. a few percent difference ... not a factor of 2.
Note that the alternative to checking is the risk that typical application bugs will crash the android platform. Certainly, garbage collection becomes problematic if applications can trash memory.
All objects use garbage collector, including objects that are very easy to manually delete.
The flip-side is that it is easy to forget to delete objects, delete objects twice, use them after they have been deleted and so on. These mistakes all lead to bugs that tend to be hard to track down.
All instances of objects are created with dynamic memory allocation, including objects that can easily use the stack. If a loop iteration begins creating an instance of a class and ends deleting the created object, dynamic memory allocation will be inefficient.
Java dynamic memory allocation and object creation is FAST. Faster than in C++ for example.
The garbage collector needs to stop the app while it cleans the memory and it is very undesired for games, GUI apps and real-time apps.
Use a concurrent / low-pause garbage collector then. Another approach is to implement your app to not generate lots of garbage ... and seldom trigger garbage collection.
Reference counting is slow and it cannot handle circular references.
No decent Java GC uses reference counting. (On the other hand, a lot of C / C++ manual memory management schemes do. For instance, so-called smart pointer schemes in C++.)
Multi-threaded garbage collector is slower and it needs more use of the CPU.
You actually mean concurrent collection I think. Yes it does, but that's the penalty you pay for the extra responsiveness that you demand for interactive games / realtime apps.

What you describe as 'efficient' I would describe as 'ideal'. An application that requires little memory, little CPU time and runs quickly, put another way, is one that is good, fast, and cheap all at the same time. Never mind if it does anything useful or interesting.
The only comparison I'd view as reasonable, if all three goals are required, is among applications that produce a common result. In that case, it is unlikely, given a competing group of evenly-capable programmers, that any one implementation would excel on all three counts over the others.
That said, your question leaves out a key criterion to the mobile market: rate of application development. Mobile applications also profit far more from positive user experience than back-end optimization. Without that constraint, the question of efficiency as you put it, seems to me more of an ponderous consideration than a practical one.
But to the actual question: can a language like Java produce more efficient code than one that compiles statically to the instruction set of the target machine? Probably not. Can it be as efficient, or efficient enough? Absolutely. If we considered an execution platform with fixed, severely constrained resources that changes infrequently, it would be a different matter.

In any language, the way to get fast execution is to do the job with as little execution as possible, and as little garbage collection as possible.
That sounds like a vacuous generality, but what it means in practice, regardless of language, is
For the data structure design, keep it as simple as possible. Stay away from the fancy collection classes full of bells and whistles. Especially stay away from notifications as a way of keeping data consistent. If your data is normalized, it can never be inconsistent. If you can't normalize it, it's better to tolerate temporary inconsistency, than to try to keep it tight with notifications.
Performance problems creep in, even into the best code. You should try not to make them, but you will still make them. Most important is knowing how to find them, once made, and remove them. Here's a blow-by-blow example. If in doing this, you find you need a better big-O algorithm, then put it in. Putting one in without being sure it's needed is a recipe for slowness.
No language can rescue a program from non-removed performance problems. The language and its compiler, JITter, etc. are like a race horse. It's fine to want a good horse, but it's a waste if the jockey isn't as slim as possible.
Your program is the jockey, and it's your job to take it on a weight-loss program.

I will paste an interesting answer given by the James Gosling himself in the Book Masterminds of Programming.
Well, I’ve heard it said that
effectively you have two compilers in
the Java world. You have the compiler
to Java bytecode, and then you have
your JIT, which basically recompiles
everything specifically again. All of
your scary optimizations are in the
JIT.
James: Exactly. These days we’re
beating the really good C and C++
compilers pretty much always. When you
go to the dynamic compiler, you get
two advantages when the compiler’s
running right at the last moment. One
is you know exactly what chipset
you’re running on. So many times when
people are compiling a piece of C
code, they have to compile it to run
on kind of the generic x86
architecture. Almost none of the
binaries you get are particularly well
tuned for any of them. You download
the latest copy of Mozilla,and it’ll
run on pretty much any Intel
architecture CPU. There’s pretty much
one Linux binary. It’s pretty generic,
and it’s compiled with GCC, which is
not a very good C compiler.
When HotSpot runs, it knows exactly
what chipset you’re running on. It
knows exactly how the cache works. It
knows exactly how the memory hierarchy
works. It knows exactly how all the
pipeline interlocks work in the CPU.
It knows what instruction set
extensions this chip has got. It
optimizes for precisely what machine
you’re on. Then the other half of it
is that it actually sees the
application as it’s running. It’s able
to have statistics that know which
things are important. It’s able to
inline things that a C compiler could
never do. The kind of stuff that gets
inlined in the Java world is pretty
amazing. Then you tack onto that the
way the storage management works with
the modern garbage collectors. With a
modern garbage collector, storage
allocation is extremely fast.

Multicore programming: what's necessary to do it?

I have a quadcore processor and I would really like to take advantage of all those cores when I'm running quick simulations. The problem is I'm only familiar with the small Linux cluster we have in the lab and I'm using Vista at home.
What sort of things do I want to look into for multicore programming with C or Java? What is the lingo that I want to google?
Thanks for the help.

The key word is "threading" - wouldn't work in a cluster, but it will be just fine in a single multicore machine (actually, on any kind of Windows, much better in general than spawning multiple processes -- Windows' processes are quite heavy-weight compared to Linux ones). Not quite that easy in C, very easy in Java -- for example, start here!

You want Threads and Actors
Good point ... you can't google for it unless you know some keywords.
C: google pthread, short for Posix Thread, although the win32 native interface is non-posix, see Creating Threads on MSDN.
Java: See class Thread
Finally, you should read up a bit on functional programming, actor concurrency, and immutable objects. It turns out that managing concurrency in plain old shared memory is quite difficult, but message passing and functional programming can allow you to use styles that are inherently much safer and avoid concurrency problems. Java does allow you to do everything the hard way, where data is mutable shared memory and you desperately try to manually interlock shared state structures. But you can also use an advanced style from within java. Perhaps start with this JavaWorld article: Actors on the JVM.

Check out this book: Java Concurrency in Practice

I think you should consider Clojure, too. It runs on the JVM and has good Java interoperability. As a Lisp, it's different from what you're used to with C and Java, so it might not be your cup of tea, but it's worth taking a look at the issues addressed by Clojure anyway, since the concepts are valuable regardless of what language you use. Check out this video, and then, if you're so inclined, the clojure site, which has links to some other good screencasts more specifically about Clojure in the upper right.

It depends on what your preferred language is to get the job done.
Besides the threading solutions, you may can also consider
MPI as a possibility from Java and C --- as well as from Python or R or whatever you like.
DeinoMPI appears to be popular on Windows, and OpenMPI just started with support for Windows too in the current release 1.3.3.

A lot of people have talked about threading, which is one approach, but consider another way of doing it. What if you had several JVM's started up, connected to the network, and waiting for work to come their way? How would you program an application so that it could leverage all of those JVMs without knowing whether or not they are on the same CPU?
On a quadcore machine, you should be able to run 12 or more JVMs to process work. And if you approach the problem from this angle, scaling up to multiple computers is fairly simple, although you do have to consider higher network latencies when your communication is across a real network.

Here is a good source of info on threading in C#.

You need to create multithreaded programs. Java supports multi-threading out of the box (though older JVMs ran all threads on one core). For C, you'll either need to use platform specific code to to create and manipulate threads (pthread* for Linux, CreateThread and company for Windows). Alternatively, you might want to do your threading from C++, where there are a fair number of libraries (e.g. Boost::threads) to make life a bit simpler and allow portable code.
If you want code that'll be portable across a single machine with multiple cores AND a cluster, you might look into MPI. It's really intended for the cluster situation, but has been ported to work on a single machine with multiple processors or multiple cores -- though it's not as efficient as code written specifically for a single machine.

So, that's a very broad question. You can experiment with multithreaded programming using many different programming languages including C or Java. If you wanted me to pick one for you, then I'd pick C. :)
You want to look into Windows threads, POSIX threads (or multithreading in Java, if that's language). You might want to try to find some problems to experiment with. I'd suggest trying out matrix multiplication; start with a sequential version and then try to improve the time using threads.
Also, OpenMP is available for Windows and offers a much different view of how to multithreaded programming.

Even though you asked specifically for C or Java, Erlang isn't a bad choice of language if this is just a learning exercise
It allows you to do multiprocess style programming very very easily and it has a large set of libraries that let you dive in at just about any level you like.
It was built for distributed programming in a very pragmatic way. If you are comfortable with java, the transition shouldn't be too difficult.
If you are interested, I would recommend the book, "Programming Erlang" by Joe Armstrong.
(as a note: there are other languages designed to run on in highly parallel environments like Haskell. Erlang just tends to be more pragmatic than languages like Haskell which are rooted more in theory)

If you want to do easy threading, such as parallel loops, I recommend check out .NET 4.0 Beta (C# in VS2010 Beta).
The book chapter Joe linked to is a very good one I use myself and highly recommend, but doesn't cover the new parallel extensions to the .NET framework.

yes , many threads , but if the threads are accessing the same position in the memory only one thread will execute,
we need multi memory cores

By far the easiest way to do multicore programming on Windows is to use .NET 4 and C# or F#. Here is a simple example where a parallel program (from the shootout) is 7× shorter in F# than Java and just as fast.
.NET 4 provides a lot of new infrastructure for parallel programming and it is really easy to use.

That you say "take advantage" sounds to me as something more than doing just any multi-threading. Simulations in my book are computation-intensive and in that respect the most efficient language is C. Some would say assembly but there are very few x86 assembly programmers who can beat a modern C compiler.
For the Windows NT engine (NT4, 2000, XP, Vista and 7) the mechanisms you should look into are threads, critical sections and I/O completion ports (iocp). Threads are nice but you need to be able to synchronize them among themselves and with I/O which is where cs's and iocps come in. To make sure your wringing every last bit of performance out of your code you need to profile, analyze, experiment/re-construct. Lots of fun but very time-consuming.

Multiple threads can exist in a single process. The threads that belong to the same process share the same memory area (can read from and write to the very same variables, and can interfere with one another). On the contrary, different processes live in different memory areas, and each of them has its own variables. In order to communicate, processes have to use other channels (files, pipes or sockets).
If you want to parallelize a computation, you're probably going to need multithreading, because you probably want the threads to cooperate on the same memory.
Speaking about performance, threads are faster to create and manage than processes (because the OS doesn't need to allocate a whole new virtual memory area), and inter-thread communication is usually faster than inter-process communication. But threads are harder to program. Threads can interfere with one another, and can write to each other's memory, but the way this happens is not always obvious (due to several factors, mainly instruction reordering and memory caching), and so you are going to need synchronization primitives to control access to your variables.
Taken from this answer.

Performance of Java 1.6 vs C++?

With Java 1.6 out can we say that performance of Java 1.6 is almost equivalent to C++ code or still there is lot to improve on performance front in Java compared to C++ ?
Thanks.

Debian likes to conduct benchmarks on this sort of thing. In their case, it appears that Java is about half as fast and consumes 2-18 times as much memory as C++.

A well-written Java program is never going to be as fast as a well-written C or C++ program. The virtual machine is an irreducible overhead. However, most code is not well written.
Java is a simpler language than C++, and offers a more forgiving environment for inexperienced programmers - so if your programmers are inexperienced (and cheap), then Java will probably perform 'better' than C++.
shared_ptrs offer a similarly forgiving environment in C++, so they are very tempting for inexperienced programmers, or those migrating from Java, But their performance overhead is as bad or worse than Java's garbage collection. I've seen large C++ programs where every variable is a shared_ptr, and they perform terribly.
My opinion
Personally, I think that large projects need to choose an 'easy' programming language for the bulk of their code, and a 'fast' one for sections that need optimising. Java may be a good choice for the 'easy' language, especially since there is currently a plentiful supply of Java programmers - in the future, I think even easier languages such as Python will begin to take over.
C++ is a reasonable choice for a 'fast' language if you already know it, but I think it's over-complexity will eventually see it fall by the wayside, while C will continue to fulfill this role.

I would expect that most of the time for most applications C++ will be faster than Java.
In some cases there will be some C++ which is slower than Java for a given task. This is pretty rare and always a result for poor implemntation or more commenly poor refactoring of an application.
In the majority of cases the performance difference more than offset by the fexibility, ease of use, availability of libraries, and, portability that Java provides.
In a very few cases performance is so critical that developing in Java would be a poor choice <opinion><flame off>in these cases plain C is usually a better choice than C++ </flame></opinion>.
Currently the sweetspot in performance/ease of use/ease of development tradeoffs is C#. Portability is a big issues here though.

I find that Java performs very well.
However, why has no one ever fixed my biggest complaint?
Java uses FIVE TIMES as much memory as a C++ program doing the same job. At least!
And once it's used, Java keeps it!
Please, please, why won't anyone write a garbage collector for Java that uses minimum amounts of RAM? It could compact the heap and returns the memory to the OS. Instead of ridiculous piles of -Xm* options, use the memory needed and then give it back!
Actually I am sure some of the embedded system JVMs do this, but none of the desktop or server systems do.
This memory piggishness makes Java applications all want to act as if they own the entire computer system, that no one ever wants to run more than one application and that RAM is free and infinitely upgradable.
Therefore, no matter how great the performance, I would never write anything like a utility program in Java. Only gigantic server apps need apply.

What program are you developing?
Comparing C++ to Java speed is like comparing a screwdriver and a hammer, pointless. In the world we live in, where both supercomputers and toasters need to be programmed, you need to focus on your particular requirements.
I use C++ for hard realtime software running on embedded systems. I wouldn't dream of using the awfully broken Java for realtime spec for at least another 5 years, when it will hopefully be mature. I would be equally loath to use C++ for a database, cloud accessing middleware app (actually I have no Idea what I just said, but I know Java is good for 'that sort of stuff')
Would you use a ferrari with no trunk space to move your belongings? Would you bring a minivan to a drag race?
People have to understand that just because they are programming languages, does not mean they are comparable in a meaningful way.

No. Unless you measure it, you may not say it.

Performance is usually "good enough" for most purposes. The question is what you want to compare exactly, and if you have applied a profiler to find and fix the hotspots in your code.
JVM's based on Sun's code still pay a hefty startup-tax (I still wonder why they cannot snapshot that and restart from there) but Suns approach has been correctness first, speed second, and it's taken them 10 years to get up to par.
So the answer is "It depends" :)

For most applications it is almost certainly possible to write a C++ program which performs considerably better than a program to achieve the same thing in java.
However if the program isn't optimised for speed then java will likely be just as fast or faster because the compiler / JIT is able to make optimisations that a C++ environment can't.
Basically if you are willing to spend considerable time understanding and coding for performance you can probably do a considerably better job in c++ eventually than you could in java but for the same amount of time and effort it is quite likely that java will "win".
As usual though, algorithmic improvements tend to make as much if not more difference than the language.

Why Java programs?

I've had little exp. with java and since now i've worked with c++. what makes this one more special and preferred?
Moreover I would like to know about the use of System.in classes and parseInt classes.

Java is vastly easier to work with, especially when developing large programs.
Debugging: Java generates nice Stacktraces
Stability: You can catch every exception
Development Speed: you need no linker (which can take many minutes in C++); with a modern IDE (e.g. eclipse) you can edit code in-place while the program is running
Garbage Collection and run-time type safety eliminate whole classes of errors
really good free (as in beer) IDEs

In theory (and sometimes in reality) Java programs also run on multiple platforms, "write once - debug, er, run everywhere" type of thing. That makes it very useful for a variety of projects.
In my personal experience, while learning Java shortly after being introduced to C++, Java seemed simpler and easier to learn and understand, hence more productive, as was said before. While program structure and syntax is very similar, there is no need to worry about pointers and other potentially dangerous language features.

This is really very broad and I think these are really 2 or 3 different questions. I'll address the first one very briefly. Java utilizes garbage collection, or autmatic memory management. That is, arguably, the biggest difference between it from a language like C++. There are clearly some potential for increase in productivity in that you don't have to worry as much about memory, although in reality you do need to pay attention to your references. Perhaps you could refine your question a bit.

Java works in browsers! (Milpa for example). You can say Flash too, but with Java you can leverage the numerous classes coming with it (another advantage over C++, even if both languages has a good set of free libraries on the Net) and your knowledge of the language.
As said, Java is supported on many platforms with minimal adjustments, with a fast, efficient VM, from big servers to mobile phones.
OO support is arguably better designed, avoiding mistakes done in C++. Somehow, C# is to Java what Java is to C++ ^_^ (I won't argue on this, I don't know C# enough actually, it is just an historical point).
In the same spirit, Java is slightly more abstract, avoiding pointers, manual memory management and some other low level stuff.
That doesn't mean than one is better than the other, STL helps C++ for some of the issues above, etc.
I am not sure how to answer the last sentence, these are object and method respectively, not classes.
I never used System.in yet, I suppose it is usable if you feed the Java program with < or | on the command line. And parseInt is a static method of Integer class.

The language features have already been mentioned (GC, reflection etc.). But there is another major difference: Libraries. I know there is the STL and Boost and all kinds of libraries out there, but they are not all of a piece, they all feel different. Often you are forced to use all kinds of C-APIs (e.g. threading or sockets, just to mention two things). All the C++ evangelists will now jump in and tell about some kind of cool OO-socket or OO-threading library, but they are not part of the STL. They should be. Its almost 2009 and everything is networked and multithreaded. This ought to be part of the standard library.
Why is it bad to use those C-APIs? Because it is hard to use them in an object oriented programm. Try using Win32's CreateThread() with the listener-pattern (C#-users: read "delegates").
For a "rich client application", where performance is not a big deal, I would always use Java or C#. If I need raw speed (think signal processing or embedded applications), I would rather use C instead of C++.
BTW: I have used all four languages (C, C++, Java, C#) for a long time.

If you like to program really the object oriented way, then you need to go from C++ to Java. One of the problems with C++ is that most programmers actually use it as C and don't exploit all its OO features. Java is here stricter.

With C++ you're programming "on the metal", whereas with Java you're programming towards a virtual machine. The Java software stack all the way down to the VM is constructed to give a highly abstracted programming experience. This is most clearly apparent in the use of datatypes "that just are" (i.e. the programmers need no understanding of how they translate into memory areas), garbage collection "that just works" (the programmers don't have to deal with allocation and deallocation issues) and the ubiquity of exceptions for error handling and propagation. Pointers are not part of Java, the system takes care of where and how things are allocated.
From this, you might see that the design philosophy of Java is very different from C++: Java tries to enforce that the programmer should stick to certain ways of working which are considered to be safe and to make programming easier. Some people hate this aspect of Java, other people love it.

It really depends on what you're trying to do.
For a lot of higher level functionality where optimal performance may not matter, Java is easier and more reliable to use. For example, garbage collection, array checking, etc. It's also sandboxed, of course.
For me, another major benefit of Java is the use of reflection and of run time class loading. I write a lot of plugins within pluggable architectures, and can ensure I can add more new classes to a running program on any platform. Last time I tried to do that in C++, I had to mess with DLLs and COM.