Beauty Is in the Eye of the Beholder
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
Presentation
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Recorded at:
From Concurrent to Parallel
Presented by
Brian Goetz
on
Jun 19, 2009
Length 01:01:02
- Sections
- Development,
- Architecture & Design
- Topics
- Java ,
- Programming ,
- Design ,
- Language Design ,
- Architecture
- Tags
- QCon ,
- Parallel Programming ,
- QCon San Francisco 2008 ,
- Concurrency
-
- The next QCon is in London March 5-9, Join us!
How would you like to view the presentation?
In case you are having issues watching this video, please follow these simple steps to help us investigate the issue:
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
Summary
Multiprocessor systems have gone from being rare and expensive to being ubiquitous. As the hardware reality changes, so do the programs we want to write and so must the platform and libraries we rely on. In Java SE 7, the java.util.concurent package will grow to address the need to exploit finer-grained concurrency, in the form of the fork-join framework.
Bio
Brian Goetz is the author of over 75 articles on software development, and the book, Java Concurrency In Practice. He serves on the JCP Expert Groups and is a Sr. Staff Engineer at Sun Microsystems.
About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
Multiprocessor systems have gone from being rare and expensive to being ubiquitous. As the hardware reality changes, so do the programs we want to write and so must the platform and libraries we rely on. In Java SE 7, the java.util.concurent package will grow to address the need to exploit finer-grained concurrency, in the form of the fork-join framework.
Bio
Brian Goetz is the author of over 75 articles on software development, and the book, Java Concurrency In Practice. He serves on the JCP Expert Groups and is a Sr. Staff Engineer at Sun Microsystems.
About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
RelatedVendorContent
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
Getting Started with Stratos - an Open Source Cloud Platform
SOA All-In-One Guide: KPIs & Best Practices, ESB Report
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Excellent overview of the forkjoin framework provided by Brian.
by
Jayaram Vundavalli
Posted
Terrible!
by
Daniel Sobral
Posted
Re: Terrible!
by
Aaron Hamid
Posted
-
Yet I'm still confused of how the work stealing would work when multiple workers compele to steal the task from the tail of a single workers dequeue?
-
God, that was awful. I'll paraphrase it here: Java sucks as a language for massive concurrency, but we don't want to face that, so, instead, we'll talk about some ad-hoc approaches to various problems that are already solved and working, and build a library for them as if it were original. Only those problems are not the everyday problems most of us face, and, as said, are solved for those who need them.
I particularly liked when he mentioned that threads are expensive, as if this was basic truth, instead of a consequence of various characteristics of Java.
Now, the library is nice -- actually, very good, and if I hadn't read about it before and the presentation was a bit more honest about the very limited scope of what they were doing, it would be a great presentation.
For those still left looking for effective massive concurrency, it seems Erlang and the like are still it. -
Daniel, while I also have some qualms as to the utility and applicability of this particular library, I have to take issue with your criticism of this presentation.
First, if Java "sucks as a language for massive concurrency", it's because all mainstream languages, which are largely imperative and OO, "suck for massive concurrency".
I'm not sure what you mean when you say the approach described is "ad hoc", or that anybody claimed that it was original. In fact the speaker alluded to previous approaches implemented in other languages at the beginning of the talk. My reservation is that this is not applicable to "everyday problems" but I believe the point the speaker is trying to make is that this WILL be the everyday problem as we face the challenge of massively parallel hardware.
The fact that threads are expensive is a basic truth (they are more expensive than not using threads). This truth stems from operating system implementation, and is possibly worsened by language implementation. If you could say anything about Java, it is not that it does not have a superb VM. Java's VM is best in class, has had massive engineering years poured into it by some really brilliant engineers, and beats the pants of other languages/VMs that could be considered alternatives to Java/JVM: Ruby, Python (both of which have been plagued by infamous "global interpreter locks"), and probably anything else out there.
Perhaps you have some antiquated ideas about Java from 1997? Let's say the Java runtime was perfect, there is still thread overhead at the OS level. This is not specific to Java. All languages that use threads (including natively compiled languages) have to deal with this. There are of course many alternatives available: fibers, events, async IO, etc. But your claim seems to be that threads are expensive specifically due to characteristics of Java, not that other approaches should be used.
Of course if you are looking for "massive concurrency" look at Erlang. Look at a lot of things. Erlang is conspicuously NON-mainstream, so Erlang developers are obviously NOT the target of this talk. If you have been writing massively concurrent Erlang for the last 10 years, well, I guess you get a pat on the back, but you are certainly the exception and I don't get what your beef is with the Java community building new libraries for themselves.
By the way there are languages that suck less for concurrency on the JVM, including Clojure and (gasp) Erjang.
3 comments
Watch Thread Reply