Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Do these features really speed up processing?  RSS feed

 
Tim Bee
Ranch Hand
Posts: 91
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've been reading about the new features of Java 8 and it has occurred to me that many of these additions really don't do much to speed up the overall processing of a company.
One reason is because they are really just new methods that add functionality that we had to develop before by our own programming. They still do the same type of execution of code that we used to write for ourselves so, aside from the presumably better optimization, they are really not speeding things up much.
Secondly, since most servers are running at a high CPU utilization percentage anyway, while one process may run faster, the overall company processing will not improve tenfold.
These new improvements will only really be beneficial in situations where corporations have multi-core servers that are dedicated to a minimum number of processes and have a lot of spare processing power with which to take advantage of these parallel processing improvements.

What are your thoughts? Under what conditions will these changes to Java 8 result in faster overall processing? Are most of the changes just there to make out programming life easier?
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't discount the ability of abstract functions to aid in machine optimization.

A lot of optimization these days, however, is to optimize the programmer, not the program. Hardware is no longer the most expensive part of the system and hasn't been for a long time. So anything that contributes to faster coding is popular. Including, alas, unchecked languages that give the illusion of programmer productivity by pushing fatal errors from the design phase into the production phase.

My experience with production servers has been that they are often spending a lot of time idle. In a way that's good, because this "everybody must give 110%" nonsense doesn't work with hardware. Antything over about 80% risks a train wreck when (not if) an unexpected load comes on the system. But one production machine I used to ride herd on ran most of the day at 3% CPU, only occasionally popping up to 10% CPU. Which is why virtual machines, cloud servers, and containers are so popular these days (gratuitous self-promotion: visit our new cloud/virtualization/container forum, hoest by Your Humble Servant).
 
Tim Bee
Ranch Hand
Posts: 91
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:My experience with production servers has been that they are often spending a lot of time idle. In a way that's good, because this "everybody must give 110%" nonsense doesn't work with hardware. Antything over about 80% risks a train wreck when (not if) an unexpected load comes on the system. But one production machine I used to ride herd on ran most of the day at 3% CPU, only occasionally popping up to 10% CPU. Which is why virtual machines, cloud servers, and containers are so popular these days (gratuitous self-promotion: visit our new cloud/virtualization/container forum, hoest by Your Humble Servant).


Do you think that a bank's servers would be running at 3% or 80%. They are transaction intensive, I would think. And have huge volumes.
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 36406
454
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Bee wrote:Do you think that a bank's servers would be running at 3% or 80%. They are transaction intensive, I would think. And have huge volumes.

Depends what time of day it is and other things. At peak time, maybe 80%. In the middle of the night, maybe 3%. Keep in mind that banks either use very powerful servers and/or have lots of servers running in parallel.

Some of the new features in Java 8 let you write code that parallelizes better if you need to change it later. So there is some element of future proofing going on here. As we get machines with still more cores, this becomes even more important.

I remember when I had to re-write code (and redo design) years ago to adjust for having a large number of less powerful cores as opposed to the dual core (but very powerful core) machine we had been developing for. That was a lot of re-work. Had Java 8 existed at the time, this would have helped greatly.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Bee wrote:
Tim Holloway wrote:My experience with production servers has been that they are often spending a lot of time idle. In a way that's good, because this "everybody must give 110%" nonsense doesn't work with hardware. Antything over about 80% risks a train wreck when (not if) an unexpected load comes on the system. But one production machine I used to ride herd on ran most of the day at 3% CPU, only occasionally popping up to 10% CPU. Which is why virtual machines, cloud servers, and containers are so popular these days (gratuitous self-promotion: visit our new cloud/virtualization/container forum, hoest by Your Humble Servant).


Do you think that a bank's servers would be running at 3% or 80%. They are transaction intensive, I would think. And have huge volumes.


The server I mentioned was in a bank. It was responsible for downloading, transforming, and loading from the outsourced mainframe-based banking systems and mortgage processing systems to the in-house financial systems. The machine also hosted the system responsible for meeting Federal Foreign Asset Control requirements. If you so much as walked your dog outside the building, we were supposed to verify that neither your nor your dog were on the federal list of drug dealers, money launderers and terrorist organizations. The 18 percent peak, in fact, was hit when about once a week, we got a new list and had to recheck all 3.5 million of our known clients, vendors, employees and so forth against the updated list.

A large enterprise has many servers. Some of them carry lots of online traffic. Some of them do lots of batch processing. Some do things that you don't want held hostage to highly-loaded equipment and/or don't want anywhere near places where outsiders could get at them. And some are development servers. We had enough physical boxes that they were blowing breakers for entire equipment racks, but relatively few of them were running high loads. And at the time, it was cheaper to buy more boxes than to train operators on stuff like Solaris Zones.
 
Tim Bee
Ranch Hand
Posts: 91
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do each of these processors have their own JVM? Is one JVM the dominant JVM that controls the others on the other processors?
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 36406
454
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The processors are on the same machine in the case I think we are discussing. Which means that the one JVM can use multiple processors.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For the installation I was referring to, I believe there were 3 JVMs. One ran Tomcat, one ran Apache Avalon (a now defunct framework more or less replaced by Apache ServiceMix), and one ran a dedicated RMI application.

I also was part of an effort that set up a high-use web application host. There were 4 CPUs per box and 4 boxes, so we set up a cluster with an F5 frontend to feed 16 JVM instances in total.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!