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 10 years ago.
I've been doing software development (in Java) since 1998 and have worked with many different teams solving various different problems. Never during time period has any team used parallel programming methods. Even though multi-core processors have been around for a while, I find that parallel programming models are still largely ignored in the real world to solve problems. So, why is parallel programming not used more often? It seems like a good way to make things more scalable, efficient and generally improve performance of programs.
Because getting parallel programming right in a multithreaded shared-memory environment like Java is really, really hard. You're practically guaranteed to make mistakes that are very hard to diagnose. And of course it's extra effort.
Furthermore, the kind of programs that most people work on are workflow systems. Desktop versions of those aren't performance-critical, and webapps / server components are trivial to parallelize by having each request be served by its own thread. This has the advantage that developers don't really have to deal with the parallel aspect.
Because parallel programming is not applicable to every possible problem and because writing a correct concurrent program is hard. Especially making sure that threads are synchronized correctly without unnecessary locking is just not easy. Also, bugs that happen depending on the timing of thread scheduling are very hard to reproduce, find and fix. It's very nasty if you have a concurrency bug that happens once every 100,000 transactions and it happens on production and not on your development system (I've been there...).
Read the book Java Concurrency in Practice, the best book about concurrent programming in Java.
parallel programming models are still largely ignored in the real world to solve problems
I think it is being used where it solves problems. But it doesn't come for free, so it's indeed better not to do anything in parallel (asynchronously) when a simpler serial (synchronous) solution works well enough.
Real parallel programming (where you split up a problem over several cores) is mostly interesting for long running algorithms. Most real life applications are more event processors. Often these events will run in parallel (think about a web server having several threads to process requests). when programming is used to solve an arithmetic problem, it is used more often (think optimization, data analysis etc)
I think your opinion is wrong, for sample when you are have a server side application, application server handle any request by a thread(maybe achieve it from thread-pool).
I guess any place that need to parallel(multi-threading) model you have to do programming parallel.
There is usefull information in following link :
http://www.asjava.com/core-java/why-we-need-to-use-multiple-threads/
Related
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 10 years ago.
I need to call a method from another JVM running on the same machine. This methods needs to be called very many time with Java/native-like performance. It is a small-input small-output method. The other JVM runs on the same machine.
What is the fastest way to make this call and retrieve the result from this other JVM running "nearby"?
Some options are probably RMI, pipes, sockets, JMS, an optimized same-machine inter-JVM communication support, some low-level hack in the JVM. Any idea is welcome, regardless of how specialized it is.
The fastest way to communicate between JVMs on the same machine is using shared memory e.g. via memory mapped files. This is as much as 100x faster than using a Socket over loopback. e.g. a 200 ns round trip time vs a 10-20 micro-second round trip time for Sockets.
One implementation is Java Chronicle BTW The 100 ns latency includes persistence of the messages.
Whether you need either of these solutions isn't something you should take for granted. Often when people say they have to have the "fastest" they really mean they don't know how fast it needs to be so if they pick the fastest it should be the right solution. This is usually not correct because taking the fastest solution often means making compromises in the design and implementation which it may turn were never needed if only you knew what the requirements really were.
In short, unless you have specific, measurable latency and/or throughput requirements you should assume that the simplest solution is what you really want. This can be replaced with something faster should it turn out it is not suitable when you have a better understanding of what is required.
Another possibility is 0MQ (ZeroMQ), though it depends what you mean by "fastest" - zeromq is excellent for throughput but if you absolutely must have the lowest possible latency it may not be optimal.
ZeroMQ may be overkill for just two JVMs, but has the advantage that if you later want to move one of the JVMs to another machine, or communicate with non-Java processes, ZeroMQ will still work just fine - and it scales to larger-scale, more complex communications too.
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 10 years ago.
It's not going to be a request for general comparisson:
Play! framework is Java based which means the code is interpreted to bytecode and then compiled by the JVM in runtime. On the other hand, Ruby is a dynamic language which means the code is interpreted with every request. This is certainly obvious for every programmer.
Another aspect is the development process and the ease of the language (strong typing vs weak typing).
Currently I'm developing a new website using Play!
So, for the questions:
Performance for an HTTP server (Play! runs on the JVM, Ruby is dynamic) - does it really matter for a website? would you see a significant differences?
I feel RoR has much larger community, sources, tutorials etc, and it's a little batter me. Or should it?
Well, it depends.
Ruby's not a particularly fast language, but language execution speed is likely not to be your bottleneck—in my experience, ruby's relative slowness is often just a drop in the ocean of external service calls (e.g. databases), algorithmic problems (e.g. synchronous, blocking subroutines), and design choices that are just generally inappropriate for the problem domain. Keep your whole technology stack in perspective.
Community's important, and Ruby/Rails has an extremely active one. AFAIK Play's smaller, but in my own experience Java and Scala (and the myriad other languages that have JVM implementations (including Ruby)) also have good communities.
All of this depends on the specific needs of your app (and you!). If Ruby's too slow, it's too slow. If you absolutely need some library that only exists in Java, use Java. Choose the tool to fit the task. But keep the entire task (and your own needs for completing that task) in perspective.
Many differences between these two models. As for the performance, my opinion about Java based & RoR:
1, Java based website(running on several Java Application Servers), has its unique advantage, such as multi-thread model(highest speed to read local data), global memory, easy to pooling resources, plenty of efficient clients to connect all kinds of 3rd part OSS tools...
2, RoR (and Php) model of HTTPServer connection, need to "proxy" request to App tier. Multi-process model increases inter-process communications. And as a "dynamic language", the performance is lower.
But, nowadays, web programming depends on other tools to boost up. The widespread uses of cache, NoSQL(Memcached, Redis, TT/TC), IPC/RPC framework(netty, akka, )... shift the bottleneck. I knew both above models has been used in large-scale networking social games.
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 10 years ago.
Simple enough really. I have a horrible amount of JSON to process, 100GB in total. This 100GB is split into files which are typically 1mb each.
So this left me wondering, typically speaking would it be quicker to parse a JSON file in Javascript or would I have similar results processing the file using one of Java's JSON jars?
Now obviously I'd have to multi thread all of this and so on.
Use whatever technology you're most adept at, the odds of a massive performance difference are low. V8 (Google's JavaScript engine — best known in the Chrome browser, and in NodeJS in non-browser environments, but which can also be run standalone) is freaky fast, as is Sun/Oracle's JVM with its excellent hotspot optimization technology. You could even use JavaScript on the JVM if you like (Rhino).
Now obviously I'd have to multi thread all of this and so on.
It's not obvious at all. If the process is I/O bound (and if you're reading a thousand 100MB files, it sounds like it probably will be, depending on what you're doing with them), adding multiple threads won't help you.
i think it'd be easier, faster, and more easily scalable (ThreadPoolExecutor) to process in java.
how were you planning to do it with javascript? stand alone v8 ?
If you know it, I'd use Node.js. Better to handle JSON objects in an environment built on Javascript
Both languages are run in a virtual execution environement so the execution speed will the more dependent on the VM you use and recent VMs have become really fast especially on recent hardware.
To my knowledge, javascript doesn't have 'native' support for threading. Multithreading was implemented in a "time shared" execution to prevent lockups. This seems however to no longer be the case with "webworkers" Also you could just split your files across different processes that will independently process the files this will however generate a lot of concurrent disk access which will most probably be your bottleneck when processing your files.
So I'd suggest you go with the language that you are the most comfortable with.
Btw. mind telling us what kind of processing you will be doing on the json files ?
If I were to implement this: to limit concurrent IO, I'd have a 1st thread that will prefetch one file at a time and read it into memory and queue a worker to process that file (if the processing is heavy a threadpool will certainly improve processing speed).
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 12 years ago.
from these links:-
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=python3&lang2=java
http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=python3&lang2=java
http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=python3&lang2=java
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=python3&lang2=java
they appear clearly that the best choice for GAE is java, if scalable feature is what we are looking for.
my question is, What are the implications that will affect on performance if we use one of frameworks?
e.g.
django --> python
spring MVC --> java
slim3 --> java
... etc
Just a quick note - don't take this as a definitive/comprehensive comparison:
Both Django and Spring have a long startup time, which can lead to requests being dropped. I'd go with a framework that was speciffically made for GAE: tipify, slim3, etc..
I'm used both Python and Java on GAE, one project done using Python+Django, and one using Java/Groovy+Spring.
Python+Django is very easy to develop, initially, but not so easy to maintain. It have enough fast startup time, good documentation, atc.
Java+Spring requires more development (some parts takes 2-3 times more than doing same using django), have problems with startup time (even if you are using warmup requests). But it much more stable.
Python project have too much errors, mostly without any visible (to you) reason :( And it's very hard to find cause of this errors, because of dynamic nature of lang. And also, be ready to manually patch some libraries you're using. Don't get me wrong, i have many years of Python experience, but it's really hard to maintain it on such distributed systems like GAE, and it's really have problems with quality of code :(
Java, in other hand, works very well. In case when your code have problems, you'll see all information you need to fix this, and after few iterations you'll fix almost all bugs. Except one: sometimes you'll see startup errors :( Not too often, btw
PS btw, choosing right language for GAE depend on what language you knows betters :) If you don't know Java yet - don't start with it, it requires at least 1-2 years to understand language.
These benchmarks compare Python 3 to Java on a (presumably) standard setup. There's no indication of what sort of workload these benchmarks test, either.
App Engine runs Python 2.5, in a decidedly different configuration to what you'd find on a standard desktop, so the benchmarks really don't apply.
Further, scalability isn't about benchmarks like these - they make, at most, a constant factor difference. If your app is built to scale, it will scale in either language, to the same degree. Scalability depends on how well you architect your app and use the underlying infrastructure.
I would recommend using whatever language and framework you're most comfortable with - don't pick your language based on benchmarks.
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 12 years ago.
Which language is faster for web, Java or PHP?
It is a difficult one to answer as in theory Java should be faster:
it's precompiled, any trivial algorithim will run faster in Java than PHP and there has been a vast amount of work done to optimise Java from improving the code, standard libraries, to JIT compilers, etc.
PHP is loaded and interpreted every time if you're not using the Zend optimiser, objects are intialised on every execution, even the most trivial string varaible is actually a complex object with many methods to support.
The problem is that in practice PHP sites seem to run faster using fewer resources.
I think this is because PHP developers take a more straightforward approach to design and don't get lost trying to implement exotic design patterns and implementing endless pointless abstractions.
Speed doesn't matter
in most cases.
Processing is cheap. Code in what you're comfortable with. Writing proper code goes much further for speed then choosing a language. Solid coding conventions and design plan will also help more.
Best answer I could find
"stuff to consider:
Java web applications are compiled
to bytecode. Even JSPs, which are
compiled at runtime. This is an
advantage over most uses of PHP,
where the Zend Optimizer is not in
use.
Data can be cached in a live servlet
instance - no direct/easy way of
doing this in PHP to my knowledge
(there is only ever a single
instance of a servlet/JSP in memory)
If anybody knows how to cache data in PHP without resorting to ugly
hacks, please enlighten me!
Java applications tend to be
n-tiered, which generally results in
a more maintainable application at a
slight performance penalty. This
probably sounds trollish, but
honestly: even within Java itself
direct use of JDBC will always be
faster than going through three
layers of objects to the database.
But is an n-tiered Java application able to hit the database sooner than an uncompiled, hacked-up monolithic PHP script? I don't think there's an answer to that question.
All that said, I'm working on an n-tiered MVC framework for php 5 (it's called Pure (http://www.sf.net/projects/php-pure)), so my PHP applications are generally n-tiered too. I'll worry about speed when and if it becomes an issue. For now, it's definitely not an issue."
courtesy of krumms
Speed aside, I believe the performance of Java is better than PHP. But developing a project in PHP is faster.
Can't answer this question with one or the other unless you define what you want to measure the speed of.
Some things are much faster in PHP (in a native function for example), other things are much faster in Java.
The intent of each language is substantially different from the other, so if you're debating over which to use for a particular task, you should generally based the decision on that task (and how well suited each language is to it) rather than performance.
For raw performance of code written in the language (as opposed to simply calling code in the standard library), Java will probably run faster than PHP as an extremely general rule. If that matters, chances are that PHP just isn't very well suited to the task at hand.