Related
In many languages, for me specifically, Java and C++, there is an massive standard library. Many classic problems in computer science, search, sorting, hashing etc etc... are implemented in this library. My question is, are there any benefits of say implementing one's own algorithm versus simply using the library's version? Are there any particular instances were this would be true?
I only ask because in school a huge deal of time is spent on say sorting, however in my actual code I have found no reason to utilize this knowledge when people have already implemented and optimized a sorting algorithm in both Java and C++.
EDIT: I discussed this at length with a professor I know and I posted his response, can anyone think of more to add to it?
Most of the time, the stock library functions will be more performant than anything you'll custom code.
If you have a highly specific (as opposed to a generic) problem, you may find a performance gain by coding a specialized function, but as a developer you should make a conscious effort to not "reinvent the wheel."
Sorting is a good example to consider. If you know nothing whatsoever about the data to be sorted, except how to compare elements, then the standard sort algorithms fare well. In this situation, in C++, the STL sort will do fine.
But sometimes you know more about your data. For example, if your data consists of uniformly distributed numbers, a radix sort can be much faster. But radix sort is 'invasive' in the sense that it needs to know more about your data than simply whether one number is bigger than another. That makes it harder to write a generic interface that can be shared by everyone. So STL lacks radix sort and for this case you can do better by writing your own code.
In general, standard libraries contain very fast code for very general problems. If you have a specific problem, you can in many cases do better than the library. Of course, you may eventually come across a complex problem which is not solved by a library, in which case the knowledge you have gained from studying solutions to solved problems could prove invaluable.
In college, or school, or if learning as a recreational programmer, you will be (or in my strident opinion, you should be) encouraged to implement a subset of these things yourself. Why? To learn. Tackling the implementation of an important already invented wheel (the B-Tree) for me was one of the most formative experiences of my time in college.
Sure I would agree that as a developer you should make an effort not to reinvent the wheel, but when learning through formative experiences, different rules apply. I read somewhere else on this forum that to use something at abstraction level N, it is a very good idea to have a working knowledge of abstraction level N-1, and be familiar with level N-2. I would agree. In addition to being formative, it prepares you for the day when you do encounter a problem when the stock libraries are not a good fit. Believe me this can happen in your 50 year career. If you are learning fundamentals such as data structures, where the end goal is not the completeness of your finished product but, instead, self improvement, it is time well spent to "re-invent the wheel".
Is pre-algebra/algebra/trigonometry/calculus worth learning?
I can't tell if this is a "am I wasting my time/money in school" aimed question or if this is a sincere question of if your own version is going to be better.
As for wasting your time/money in school: If all you want to do is take pot shots at developing a useful application, then you're absolutely wasting your time by learning about these already-implemented algorithms -- you just need to kludge something together that works good 'nuff.
On the other hand if you're trying to make something that really matters, needs to be fast, and needs to be the right tool for the right job -- well, then it often doesn't exist already and you'll be back at some site like Stack Overflow asking first or second year computer science questions because you're not familiar enough with existing techniques to roll your own variations.
Depending on my job, I've been on both sides. Do I need to develop it fast, or does it have to work well? For fast application programming, it's stock functions galore unless there's a performance or functionality hindrance I absolutely must resolve. For professional game programming it has to run blazing fast. That's when the real knowledge kicks into memory management, IO access optimization, computational geometry, low level and algorithmic optimization, and all sorts of clever fun. And it's rarely ever a stock implementation that gets the job done.
And did I learn most of that in school? No, because already knew most of it, but the degrees helped without a doubt. On the other hand you don't know most of it (otherwise you wouldn't be asking), so yes, in short: It is worthwhile.
Some specific examples:
If you ever want to make truly amazing games, live and breath algorithms so you can code what other people can't. If you want to make fun games that aren't particularly amazing, use stock code and focus on design. It's limiting, but it's faster development.
If you want to program embedded devices (a rather large market), often stock code just won't do. Often there's a code or data memory constraint that the library implementations won't satisfy.
If you need serious server performance from modest hardware, stock code won't do. (See this Slashdot entry.)
If you ever want to do any interesting phone development the resource crunch requires you to get clever, even often for "boring" applications. (User experience is everything, and the stock sort function on a large section of data is often just too slow.)
Often the libraries you're restricted to using don't do what you need. (For example, C# doesn't have a "stable" sort method. I run into this annoyance all the time and have since written my own solution.)
If you're dealing with large amounts of data (most businesses have it these days) you'll end up running into situations where an interface is too slow and needs some clever workarounds, often involving good use of custom data structures.
Those libraries offer you tested implementations that work well, so the rule of thumb is to use those implementations. If you have a very particular/complex problem where you can use some domain knowledge you have a case were you will need to implement your own version of an algorithm.
I remember an example Bill Pugh gave in his programming languages class where they analyzed the performance of a complex application and they realized a faulty custom implementation of a sorting algorithm by a programmer (that code was used many times in the real runs of the application) was responsible for 90% performance decrease!
After discussing this at length with professor of Computer Science, here were his opinions:
Reasons to Use Libraries
1. You are writing code with a deadline.
There is no sense in hampering your ability to complete a project in a quick and timely manner. That's why libraries are written after all, to save time and avoid "reinventing the wheel"
2. If you want to optimize your code fully.
Chances are the team of incredibly talented people who wrote the algorithm in Java or C++'s or whoever's library did a far better job at optimizing their algorithm for that language in however long it took them than you can possibly do in an hour or two. Or four.
3. You've already done previously solved this problem.
If you have already solved this problem and have a good complete understanding of how it is designed you don't need to labor over a complex solution as you don't stand to gain much benefit.
That being said, there are still many reasons to make your own solution.
Reasons to Do It Yourself
1. A fundamental understanding of problem solving techniques and algorithms are completely necessary once you reach a problem that is better optimized by a non-library solution.
If you have a highly specified problem, such things often come up when working with networking or gaming or such. It becomes invaluable to be able to spot situations in which a specific algorithm will outperform the libraries version.
2. Having a very good understanding of algorithms and their design and use makes you much more valuable in the work place.
Any halfway decent programmer can write a function to compare two objects and then toss them into a library function, however the one that is able to spot a situation and ultimately improve the programs functionality and speed is going to be looked upon well by management.
3. Having the concept of how to do something is often just as, if not more so, valuable than being able to do it.
With an outstanding knowledge of Java's libraries and how to use them, chances are you can field any problem in java with reasonable success. However when you get hired to work in erlang you're going to have some rough times ahead. Where if you had known how and not merely what Java's libraries did, you could move those ideas to any language.
4. We as programmers are never truly satisfied with merely having something "work".
Chances are that you have an itch to understand why things work. It was this curiosity that probably drove you to this area of study. Don't deny this curiosity! Encourage it and learn to your hearts content.
5. Finally, there is a huge feeling of success and accomplishment that comes with creating your own personal way of sorting or hashing etc.
Just imagine how cool your friends will see you when you proclaim that you can find the shortest path between 2 vertices in n log(n) time! On a serious note, it is very rewarding to know that you are completely capable of understanding and choosing an optimum solution based on knowledge. Not what some library gives you.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I want to write a backend system for a web site (it'll be a custom search-style service). It needs to be highly concurrent and fast. Given my wish for concurrency, I was planning on using a functional language such as Haskell or Scala.
However, speed is also a priority. http://benchmarksgame.alioth.debian.org results appear to show that Java is almost as fast as C/C++, Scala is generally pretty good, but Haskell ranges from slower to a lot slower for most tasks.
Does anyone have any performance benchmarks/experience of using Haskell vs Scala vs Java for performing highly concurrent tasks?
Some sites I've seen suggest that Scala has memory leaks which could be terrible for long running services such as this one.
What should I write my service in, or what should I take into account before choosing (performance and concurrency being the highest priorities)?
Thanks
This question is superficially about performance of code compiled with GHC vs code running on the JVM. But there are a lot of other factors that come into play.
People
Is there a team working on this, or just you?
How familiar/comfortable is that team with these languages?
Is this a language you (all) want to invest time in learning?
Who will maintain it?
Behavior
How long is this project expected to live?
When, if ever, is downtime acceptable?
What kind of processing will this program do?
Are there well-known libraries that can aid you in this?
Are you willing to roll your own library? How difficult would this be in that language?
Community
How much do you plan to draw from open source?
How much do you plan to contribute to open source?
How lively and helpful is the community
on StackOverflow
on irc
on Reddit
working on open source components that you might make use of
Tools
Do you need an IDE?
Do you need code profiling?
What kind of testing do you want to do?
How helpful is the language's documentation? And for the libraries you will use?
Are there tools to fill needs you didn't even know you had yet?
There are a million and one other factors that you should consider. Whether you choose Scala, Java, or Haskell, I can almost guarantee that you will be able to meet your performance requirements (meaning, it probably requires approximately the same amount of intelligence to meet your performance requirements in any of those languages). The Haskell community is notoriously helpful, and my limited experience with the Scala community has been much the same as with Haskell. Personally I am starting to find Java rather icky compared to languages that at least have first-class functions. Also, there are a lot more Java programmers out there, causing a proliferation of information on the internet about Java, for better (more likely what you need to know is out there) or worse (lots of noise to sift through).
tl;dr I'm pretty sure performance is roughly the same. Consider other criteria.
You should pick the language that you know the best and which has the best library support for what you are trying to accomplish (note that Scala can use Java libraries). Haskell is very likely adequate for your needs, if you learn enough to use it efficiently, and the same for Scala. If you don't know the language reasonably well, it can be hard to write high-performance code.
My observation has been that one can write moderately faster and more compact high-performance parallel code in Scala than in Haskell. You can't just use whatever most obviously comes to mind in either language, however, and expect it to be blazing fast.
Scala doesn't have actor-related memory leaks any more except if you use the default actors in a case where either you're CPU-limited so messages get created faster than they're consumed, or you forget to process all your messages. This is a design choice rather than a bug, but can be the wrong design choice for certain types of fault-tolerant applications. Akka overcomes these problems by using a different implementation of actors.
Take a look at the head-to-head comparison. For some problems ghc and java7-server are very close. For equally many, there's a 2x difference, and for only one there's a 5x difference. That problem is k-nucleotide for which the GHC version uses a hand-rolled mutable hashtable since there isn't a good one in the stdlibs. I'd be willing to bet that some of the new datastructures work provides better hashtables than that one now.
In any case, if your problem is more like the first set of problems (pure computation) then there's not a big performance difference and if its more like the second (typically making essential use of mutation) then even with mutation you'll probably notice somewhat of a performance difference.
But again, it really depends on what you're doing. If you're searching over a large data set, you'll tend to be IO bound. If you're optimizing traversal of an immutable structure, haskell will be fine. If you're mutating a complex structure, then you may (depending) pay somewhat more.
Additionally, GHC's lightweight green threads can make certain types of server applications extremely efficient. So if the serving/switching itself would tend to be a bottleneck, then GHC may have the leg up.
Speed is well and good to care about, but the real difference is between using any compiled language and any scripting language. Beyond that, only in certain HPC situations are the sorts of differences we're talking about really going to matter.
The shootout benchmark assumes the same algorithm is used in all implementations. This gives the most advantage to C/C++ (which is the reference implementation in most cases) and languages like it. If you were to use a different approach which suited a different language, this is disqualified.
If you start with a problem which more naturally described in Haskell it will perform best in that language (or one very much like it)
Often when people talk about using concurrency they forget the reason they are doing it is to make the application faster. There are plenty of examples where using multiple threads is not much faster or much much slower. I would start with an efficient single threaded implementation, as profiled/tuned as you can make it and then consider what could be performed concurrently. If its not faster this more than one CPU, don't make it concurrent.
IMHO: Performance is your highest priority (behind correctness), concurrency is only a priority in homework exercise.
Does anyone have any performance benchmarks/experience of using
Haskell vs Scala vs Java for performing highly concurrent tasks?
Your specific solution architecture matters - it matters a lot.
I would say Scala, but then I have been experimenting with Scala so my preference would definitely be Scala. Any how, I have seen quite a few high performance multi-threaded applications written in Java, so I am not sure why this nature of an application would mandate going for FP. I would suggest you write a very small module based on what your application would need in both scala and haskell and measure the performance on your set up. And, may I also add clojure to the mix ? :-) I suspect you may want to stay with java, unless you are looking at benefiting from any other feature of the language you choose.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a history of hating Java, having used it pretty regularly in the late 90's during the 'slow as balls' era. As such, I never really learned it well. From what I understand, Java is actually a pretty good language to use these days. I've been thinking about diving into it because of Jython and Clojure. That is to say, I'd like to program in Java and use inline Jython or Clojure where appropriate. But truthfully, I'll probably just be programming in Jython/jRuby and calling up clojure from there.
Which brings me to my question. I know both of these languages can be called from Java, but is that necessarily good practice? Should I even bother learning java if I just want to use Jython as the primary language? Seeing as how that's a large part of my motivations here, I'd like to know that I'm not terribly misguided before jumping in. I'm aware there is a very high risk for projects to become a kludge if done in multiple languages like this.
I'm still learning about the JVM and the like, so I apologize if this question is painfully obvious.
Jython can be viewed as a cross compiler from Python to the Java Virtual Machine. As such, to get the most out of Jython you'll obviously have to learn Python, and probably will need to learn Java.
You can skip some of the Java learning, but at the end of the day, Java and the JVM grew up together. That means that Java code tends to lend understanding of the JVM. It is possible to gain understanding of the JVM without Java, but that's not a path well travelled. Any Jython code that imports a Java library will immediately have you searching Java documentation, so if you avoid leaning Java you're going to learn it piecemeal anyway.
You will have to decide if a piecemeal approach or a formal approach is more appropriate for you and your situation. A lot of deciding which path to take is knowing how you learn best.
As far as the "slow as balls" period of the 90's, that's when I was learning Java. Personally, I feel it is better to describe it as "slow as balls if you did incredibly stupid things with Java". Now I think people have built up a sufficient skill set to avoid translating C directly into Java. That said, I do occasionally encounter the 2000+ line method, so perhaps I'm being a bit rosy in my projection. The entire JVM is laid out in such a manner that good object oriented code runs faster, and if you're constantly trying to go to "other" objects for all the data you need locally, you'll just stack thrash the JVM.
Regardless of opinions, the JVM is now the hot Java item. There has been "other language" support by one means or the other for over a decade now; however, the excitement around Domain Specific Languages seems to have sparked an interest in compilation technologies and the JVM. The other languages benefit from the JVM being an easy target to hit with built-in cross platform support, excellent performance, huge availability of libraries, and generally good documentation. Learning Java and the JVM will help you with a lot of the JVM supported languages, as many of them don't flesh out their library space in favour of hooking into a pure Java library.
I'd say it's worth knowing Java even if you plan on only using other JVM languages. I use JRuby and Scala, and have played around with Clojure. If you are building things to run on the JVM, knowing Java is a bit like knowing C when working natively–you don't have to know C, but if you do, you can write the bits that need speed in C and wrap them in a Ruby or Python library or whatnot.
It's worth knowing the basic principles of how Java works in terms of things like interfaces and annotations and how the classpath works because otherwise you are working with basically a leaky abstraction. What happens when your interop isn't very good? This is especially true if you are planning to do Clojure and Jython!
The other reason to know Java is simply because if you are using code in the Java ecosystem, you have to be able to read and write Java. You need to write a library? Yes, you can probably write it in Clojure, but if you want other JVM language users to be able to use it, you should probably have written it in good, idiomatic Java. Scala is close enough to Java for this purpose; Clojure or Ruby or Python, not so much. Just being able to read and comprehend Java programs is very important too.
The other great benefit is simply that you get more libraries and they are better tested. You need a double-ended queue? Check the Java Collections Framework. Good random number generation? java.security.SecureRandom. UIs? Well, Swing, AWT and SWT are... okay, bad example. Knowing the benefits and shortcomings of these only comes from doing some Java programming and learning the various ways not to suck at Java.
From a couple of years experience of using Clojure (plus many more years of Java...) here is my perspective:
You don't strictly need any Java experience to write Clojure code - Clojure is a full language in its own right and you can write perfectly capable programs without using any Java.
You will need to set up the JVM environment - the Java environment has some rules about where code gets loaded from (i.e. the "classpath") that need to be followed to get a working environment. Not a big deal, and most IDEs will do it for you, but it can be a hurdle for people completely new to the JVM world. I'd suggest careful following of the setup instructions for whichever IDE/toolset you choose.
There are some Java-related concepts that are helpful to understand - for example, Clojure harnesses Java exception handling features with (try ... (catch ...)) etc. so it's useful to be somewhat familiar with the Java approach to exception handling.
Ultimately you will probably want to use Java APIs - bacause a huge amount of the value of being on the JVM in the first place is in having access to the huge diversity of libraries and tools that are available in the Java ecosystem. You don't need to write any Java code to use Java APIs from Clojure, but you do need to know enough Java (method signatures, data types etc.) to be able to read the JavaDoc documentation of the APIs and convert this into an appropriate Clojure function call. Often, this is as simple as (.someJavaMethod someJavaObject param1 param2) but sometimes it can be more complex (e.g. when you need to instantiate a subclass of some Java class to pass as a parameter)
Java isn't a bad language to learn anyway - while I'll readily admit Java has some weak points (as do all languages!), it's still a great, simple, high performance, cross-platform, object-oriented language that has a lot of value. Even if you only do a few short tutorials and never write anything substantial in Java, I'd still recommend it for the learning experience.
I believe most of the above would also apply to Jython.
I can't speak for Jython, but if you want to really get to grips with clojure, you want to understand its trade-offs compared to Java, especially wrt memory/gc and the basics of Clojure/Java interop. You also need at least an abstract understanding of how the clojure collections are implemented unless you really don't care about performance - that's not to say that clojure is particularly inefficient, but more the opposite: the implementation of its immutable collections is fairly unique and tailored to clojure's stance on persistence and performance and it helps to understand the underlying details when you're trying to improve on performance issues.
For all of that, I don't think you actually need a lot of Java knowledge. Being able to read Java fairly well, a basic understanding of the concepts, and a knowledge of where to find the documentation is probably enough.
I think if you want to do a hybrid Clojure/Jython project the interoperation details are most crucial. That probably means you have to know in some detail how classes, interfaces, some of the standard library and (to a minimal extend) generics work in Java and how to deal with all of those in your chosen languages since the interoperation necessarily reduces to the more basic Java constructs. Some of this is tricky and can be confusing, and in clojure's case at least the documentation often refers back to Java concepts and documentation for obvious reasons, so you have to make sure you read both, closely.
I would definitely learn java and learn it well, not only because Clojure is built on top of the JVM but also to get anything done you will be calling Java libraries all the time, and you may even need to dip into Java occassionally.
On another note it would be expand your mind to understand Java's OO concepts and pain poaints too and this will enhance your undersatnding of Clojure too.
Above all, study the Java libraries. Part of the joy of using the JVM is having access to "it's already been done" libraries, as well as to parts of the core language that accomplish certain tasks with optimum performance on the JVM. In addition, some languages (e.g. Clojure) purposefully dip directly into Java and don't completely discourage it in your own code, so if you want to be able to read others' code Java basics are a must.
As for the rest of "learning Java" (design patterns, concurrency in Java, etc.), I wouldn't waste your time unless/until specific projects requirements demand it.
I have an interesting architectural question regarding an application that I am developing using both Clojure and Java. The application involves a lot of intensive, concurrent data processing tasks that need to be orchestrated.
Here's the rationale for mixing both Clojure and Java:
Java is needed for some pretty CPU-intensive numerical code, where I need to optimise the algorithms to run as fast as possible on the JVM. Clojure can't quite achieve this yet, and such code would not be very idiomatic in Clojure because the algorithms require a lot of mutable data for performance reasons.
Clojure is (IMHO) far better for orchestrating the overall flow of the application, with its excellent support for functional programming, interactive dynamic development at the REPL and concurrency features.
Given that I'm using both languages - what logic or principles should I apply to determine the dividing line between the two? In particular, I'm interested in how to design an API/interface that would be at the right kind of level to take advantage of the relative strengths of both languages.
Without commenting on your perception of the relative advantages of Java and Clojure, and assuming that you did at least some micro-benchmarking to validate that the assumption has some chance of being correct, then the correct approach would seem to be to leave Java only for the parts that require optimization.
The classes responsible for the numeric code and calculation should be written in Java, and everything else in Clojure. I would even take a more aggressive approach and just design the classes to be distinct so that they could be written in Java, but actually write them in Clojure and rewrite them in Java if performance proves to be a problem.
Clojure does a good job of helping developers get most of their part in simple functional style, and isolating mutational work into confined areas.
I would apply the same guidelines here: isolate java code as much as you can, as you would do as much of your clojure code in "pure functional style". So the java island would be as small as possible given your constraints, and access to the java island would go through a small set of clojure functions.
Not sure this helps much, but anyway !
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
I know embedded C is used for micro-controllers along with other languages. but what if the control was from a PC, well I had two possible candidates (java and c++)
Java is simple and easy also Developer friendly when it comes to threading or GUI, but of course C++ is so much better performance (I know computers getting faster, and performance depend on good Algorithms ) but the compilation makefiles, shared-library and cross compiling wastes lots of time caring about technicalities when I should be working on other Important issues.
But still I've faced something like Const references which java doesn't support and force you to use clone() or copying and when that came to arrays it was a giant mess,
NOTE: I'm going to use reverse kinematics and maybe Neural network for pattern recognition. which requires tons of Calculations. but as I said I care also about the whole life cycle of the project (speed of development, performance , user friendliness and quick deployment)
I'm swinging between languages and i'm planning for long term learning process so I don't want to waste that in the wrong language or let's say (without asking) so please help and I hope this question won't be considered subjective but a reference.
cheers
Why you eliminated C?
Why do you think java has worse performances then c++? Some things are as good as c++, and it is easy to use java program on different platforms without much hassle.
Just pick the language you feel comfortable and you have most experience with, and go with it.
Personally I would lean toward C++. Java has a garbage collector, which can put your app to sleep at random. In C++ I have to collect my own garbage, which gives me an incentive to generate less of it. Also C++ allows macros, which I know have been declared a bad thing by Java-nistas, but I use as a way of shortening the code and making it more like a DSL. Making the code more like a DSL is the main way I shorten development effort and minimize introducing bugs.
I wouldn't assume that Java is inherently slower than either C++ or C. IME slowness (and bigness) comes not from how well they spin cycles, but from the design practices that they encourage you to follow. The nice things they give you, like collection classes, are usually well-built, but that doesn't stop you from over-using them because they are so convenient.
IME, the secret of good performance is to have as little data structure as possible (i.e. minimal garbage), and keep it as normalized as possible. That way, you minimize the need to keep it consistent via message-waves. To the extent the data has to be unnormalized, it is better to be able to tolerate temporary inconsistency, that you periodically patch up, than to try to keep it always consistent through notifications (which OO languages encourage you to do). Unless carefully monitored, those make it extremely easy to introduce performance bugs.
Here's an example of some of these points.
I wouldnt worry too much about performance at first - write the code in whatever language you feel comfortable in and then refactor as necessary.
You can always use something like JNI to call out to c/c++ if needed, although the performance gap between Java and c/c++ is nowhere near what it was...
Depending upon your circumstance, Java is no more quick to deploy than is C++. This mainly boils down to: are you guaranteed the same environment in your testbed that you are in production? With all of the modern additions to C++, there is little cause to suggest that Java is easier on the developer unless you are still new to the C++ language.
That aside, you have performance concerns. Unless it is a real-time system, there's no reason to eliminate any language just yet. If you code your Java intelligently (for instance, do your best to avoid copying objects and creating garbage in the most-used sections), the performance differences won't be seriously noticeable for a compute-bound process.
All told, I think you are focusing too much on textbook definitions of these two languages rather than actual use. You haven't really given any overriding reason to choose one over the other.
Java is a bit more portable, but as far as I know the only real factor for something like this is personal preference.
It would really help if You described Your problem in greater detail.
You are willing to use IK, that might suggest some robotic arm manipulation. What it doesn't say are your real time requirements. If it's going on a class-A production line it'll be hard to get away with garbage collected language.
Java is great. There are some very mature NN libraries (Neuroph, Encog) which could save You a lot of coding time. I don't know of any IK library, but I'm sure there also are at least good matrix manipulation libraries to help.
The Garbage Collection in Java is getting better and better. The latest one (G1) is a lot better than anything else, but even with it the best You can get is soft real time. So You can't expect pause-free run.
On the other hand You also might want to look at some dedicated environments - Matlab toolboxes for robotics and artificial intelligence. I think that would yield fastest prototypes.
If it's going on production than You are pretty much stuck with C or C++.