RECORD
Automatic Parallelization: Executing Sequential Programs on a Task-Based Parallel Runtime
Programming Languages · Submitted 11 Apr 2016
abstract compiled · 2026-09-23 · no language-model review
The authors' main claim We have evaluated our approach on 8 benchmark programs against OoOJava, achieving higher speedups.
The compiled record
The paper's own sentences, arranged. Each label is drawn from a closed vocabulary; the number beside it is the probability the classifier gave that label. Numbers in the tables are the authors', checked by code. No sentence in this record was written by a model.
Open the compiled record
The abstract, sentence by sentence
There are billions of lines of sequential code inside nowadays' software which do not benefit from the parallelism available in modern multicore architectures. Automatically parallelizing sequential code, to promote an efficient use of the available parallelism, has been a research goal for some time now. This work proposes a new approach for achieving such goal. We created a new parallelizing compiler that analyses the read and write instructions, and control-flow modifications in programs to identify a set of dependencies between the instructions in the program. Afterwards, the compiler, based on the generated dependencies graph, rewrites and organizes the program in a task-oriented structure. Parallel tasks are composed by instructions that cannot be executed in parallel. A work-stealing-based parallel runtime is responsible for scheduling and managing the granularity of the generated tasks. Furthermore, a compile-time granularity control mechanism also avoids creating unnecessary data-structures. This work focuses on the Java language, but the techniques are general enough to be applied to other programming languages. We have evaluated our approach on 8 benchmark programs against OoOJava, achieving higher speedups. In some cases, values were close to those of a manual parallelization. The resulting parallel code also has the advantage of being readable and easily configured to improve further its performance manually.
background contribution method result interpretation main claim
| # | sentence | role | the authors' own work | states the main conclusion | strength |
|---|---|---|---|---|---|
| s0 | There are billions of lines of sequential code inside nowadays' software which do not benefit from the parallelism available in modern multicore architectures. | background 0.99 | 0.08 | 0.02 | asserted 1.00 |
| s1 | Automatically parallelizing sequential code, to promote an efficient use of the available parallelism, has been a research goal for some time now. | background 1.00 | 0.03 | 0.02 | asserted 1.00 |
| s2 | This work proposes a new approach for achieving such goal. | contribution 1.00 | 0.68 | 0.06 | asserted 0.94 |
| s3 | We created a new parallelizing compiler that analyses the read and write instructions, and control-flow modifications in programs to identify a set of dependencies between the instructions in the program. | method 0.89 | 0.95 | 0.04 | asserted 1.00 |
| s4 | Afterwards, the compiler, based on the generated dependencies graph, rewrites and organizes the program in a task-oriented structure. | method 0.99 | 0.90 | 0.04 | asserted 1.00 |
| s5 | Parallel tasks are composed by instructions that cannot be executed in parallel. | method 0.97 | 0.35 | 0.04 | asserted 0.99 |
| s6 | A work-stealing-based parallel runtime is responsible for scheduling and managing the granularity of the generated tasks. | method 0.98 | 0.50 | 0.04 | asserted 1.00 |
| s7 | Furthermore, a compile-time granularity control mechanism also avoids creating unnecessary data-structures. | method 0.84 | 0.81 | 0.04 | asserted 1.00 |
| s8 | This work focuses on the Java language, but the techniques are general enough to be applied to other programming languages. | limitation 0.83 | 0.34 | 0.04 | asserted 0.79 |
| s9 | We have evaluated our approach on 8 benchmark programs against OoOJava, achieving higher speedups. | result 0.99 | 0.97 | 0.35 | asserted 1.00 |
| s10 | In some cases, values were close to those of a manual parallelization. | result 0.97 | 0.91 | 0.10 | asserted 0.85 |
| s11 | The resulting parallel code also has the advantage of being readable and easily configured to improve further its performance manually. | result 0.50 | 0.72 | 0.19 | asserted 0.99 |
What was examined, and what was not
- arXiv listing abstract v1
- full text
- figures and tables
- references and citing sentences
- relations to other papers
- P abstract
- S sections
- T body sentences
- C citations
- R cross-paper relations
The paper
Original abstract
There are billions of lines of sequential code inside nowadays' software which do not benefit from the parallelism available in modern multicore architectures. Automatically parallelizing sequential code, to promote an efficient use of the available parallelism, has been a research goal for some time now. This work proposes a new approach for achieving such goal. We created a new parallelizing compiler that analyses the read and write instructions, and control-flow modifications in programs to identify a set of dependencies between the instructions in the program. Afterwards, the compiler, based on the generated dependencies graph, rewrites and organizes the program in a task-oriented structure. Parallel tasks are composed by instructions that cannot be executed in parallel. A work-stealing-based parallel runtime is responsible for scheduling and managing the granularity of the generated tasks. Furthermore, a compile-time granularity control mechanism also avoids creating unnecessary data-structures. This work focuses on the Java language, but the techniques are general enough to be applied to other programming languages. We have evaluated our approach on 8 benchmark programs against OoOJava, achieving higher speedups. In some cases, values were close to those of a manual parallelization. The resulting parallel code also has the advantage of being readable and easily configured to improve further its performance manually.
Human review
Discussion
Know something about this paper? Leave a comment, or highlight any passage above to comment on it.