|
|
| Line 1: |
Line 1: |
| − | ==1 Title, abstract and keywords<!-- Your document should start with a concise and informative title. Titles are often used in information-retrieval systems. Avoid abbreviations and formulae where possible. Capitalize the first word of the title. | + | == Abstract == |
| | | | |
| − | Provide a maximum of 6 keywords, and avoiding general and plural terms and multiple concepts (avoid, for example, 'and', 'of'). Be sparing with abbreviations: only abbreviations firmly established in the field should be used. These keywords will be used for indexing purposes.
| + | The last improvements in programming languages, programming models, and frameworks have focused on abstracting the users from many programming issues. Among others, recent programming frameworks include simpler syntax, automatic memory management and garbage collection, which simplifies code re-usage through library packages, and easily configurable tools for deployment. For instance, Python has risen to the top of the list of the programming languages due to the simplicity of its syntax, while still achieving a good performance even being an interpreted language. Moreover, the community has helped to develop a large number of libraries and modules, tuning them to obtain great performance. |
| | + | However, there is still room for improvement when preventing users from dealing directly with distributed and parallel computing issues. This paper proposes and evaluates AutoParallel, a Python module to automatically find an appropriate task-based parallelization of affine loop nests to execute them in parallel in a distributed computing infrastructure. This parallelization can also include the building of data blocks to increase task granularity in order to achieve a good execution performance. Moreover, AutoParallel is based on sequential programming and only contains a small annotation in the form of a Python decorator so that anyone with little programming skills can scale up an application to hundreds of cores. |
| | | | |
| − | An abstract is required for every document; it should succinctly summarize the reason for the work, the main findings, and the conclusions of the study. Abstract is often presented separately from the article, so it must be able to stand alone. For this reason, references and hyperlinks should be avoided. If references are essential, then cite the author(s) and year(s). Also, non-standard or uncommon abbreviations should be avoided, but if essential they must be defined at their first mention in the abstract itself. -->==
| + | ==Full Document== |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | ==2 The main text<!-- You can enter and format the text of this document by selecting the ‘Edit’ option in the menu at the top of this frame or next to the title of every section of the document. This will give access to the visual editor. Alternatively, you can edit the source of this document (Wiki markup format) by selecting the ‘Edit source’ option.
| + | |
| − | | + | |
| − | Most of the documents in Scipedia are written in English (write your manuscript in American or British English, but not a mixture of these). Anyhow, specific publications in other languages can be published in Scipedia. In any case, the documents published in other languages must have an abstract written in English.
| + | |
| − | | + | |
| − | | + | |
| − | 2.1 Subsections
| + | |
| − | | + | |
| − | Divide your article into clearly defined and numbered sections. Subsections should be numbered 1.1, 1.2, etc. and then 1.1.1, 1.1.2, ... Use this numbering also for internal cross-referencing: do not just refer to 'the text'. Any subsection may be given a brief heading. Capitalize the first word of the headings.
| + | |
| − | | + | |
| − | | + | |
| − | 2.2 General guidelines
| + | |
| − | | + | |
| − | Some general guidelines that should be followed in your manuscripts are:
| + | |
| − | | + | |
| − | * Avoid hyphenation at the end of a line.
| + | |
| − | | + | |
| − | * Symbols denoting vectors and matrices should be indicated in bold type. Scalar variable names should normally be expressed using italics.
| + | |
| − | | + | |
| − | * Use decimal points (not commas); use a space for thousands (10 000 and above).
| + | |
| − | | + | |
| − | * Follow internationally accepted rules and conventions. In particular use the international system of units (SI). If other quantities are mentioned, give their equivalent in SI.
| + | |
| − | | + | |
| − | | + | |
| − | 2.3 Tables, figures, lists and equations
| + | |
| − | | + | |
| − | Please insert tables as editable text and not as images. Tables should be placed next to the relevant text in the article. Number tables consecutively in accordance with their appearance in the text and place any table notes below the table body. Be sparing in the use of tables and ensure that the data presented in them do not duplicate results described elsewhere in the article.
| + | |
| − | | + | |
| − | Graphics may be inserted directly in the document and positioned as they should appear in the final manuscript.
| + | |
| − | | + | |
| − | Number the figures according to their sequence in the text. Ensure that each illustration has a caption. A caption should comprise a brief title. Keep text in the illustrations themselves to a minimum but explain all symbols and abbreviations used. Try to keep the resolution of the figures to a minimum of 300 dpi. If a finer resolution is required, the figure can be inserted as supplementary material
| + | |
| − | | + | |
| − | For tabular summations that do not deserve to be presented as a table, lists are often used. Lists may be either numbered or bulleted. Below you see examples of both.
| + | |
| − | | + | |
| − | 1. The first entry in this list
| + | |
| − | | + | |
| − | 2. The second entry
| + | |
| − | | + | |
| − | 2.1. A subentry
| + | |
| − | | + | |
| − | 3. The last entry
| + | |
| − | | + | |
| − | * A bulleted list item
| + | |
| − | | + | |
| − | * Another one
| + | |
| − | | + | |
| − | You may choose to number equations for easy referencing. In that case they must be numbered consecutively with Arabic numerals in parentheses on the right hand side of the page. Below is an example of formulae that should be referenced as eq. (1].
| + | |
| − | | + | |
| − | | + | |
| − | 2.4 Supplementary material
| + | |
| − | | + | |
| − | Supplementary material can be inserted to support and enhance your article. This includes video material, animation sequences, background datasets, computational models, sound clips and more. In order to ensure that your material is directly usable, please provide the files with a preferred maximum size of 50 MB. Please supply a concise and descriptive caption for each file. -->==
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | ==3 Bibliography<!--
| + | |
| − | Citations in text will follow a citation-sequence system (i.e. sources are numbered by order of reference so that the first reference cited in the document is [1], the second [2], and so on) with the number of the reference in square brackets. Once a source has been cited, the same number is used in all subsequent references. If the numbers are not in a continuous sequence, use commas (with no spaces) between numbers. If you have more than two numbers in a continuous sequence, use the first and last number of the sequence joined by a hyphen
| + | |
| − | | + | |
| − | You should ensure that all references are cited in the text and that the reference list. References should preferably refer to documents published in Scipedia. Unpublished results should not be included in the reference list, but can be mentioned in the text. The reference data must be updated once publication is ready. Complete bibliographic information for all cited references must be given following the standards in the field (IEEE and ISO 690 standards are recommended). If possible, a hyperlink to the referenced publication should be given. See examples for Scipedia’s articles [1], other publication articles [2], books [3], book chapter [4], conference proceedings [5], and online documents [6], shown in references section below. -->==
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | ==4 Acknowledgments<!-- Acknowledgments should be inserted at the end of the document, before the references section. -->==
| + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | | + | |
| − | ==5 References<!--[1] Author, A. and Author, B. (Year) Title of the article. Title of the Publication. Article code. Available: http://www.scipedia.com/ucode.
| + | |
| − | | + | |
| − | [2] Author, A. and Author, B. (Year) Title of the article. Title of the Publication. Volume number, first page-last page.
| + | |
| − | | + | |
| − | [3] Author, C. (Year). Title of work: Subtitle (edition.). Volume(s). Place of publication: Publisher.
| + | |
| − | | + | |
| − | [4] Author of Part, D. (Year). Title of chapter or part. In A. Editor & B. Editor (Eds.), Title: Subtitle of book (edition, inclusive page numbers). Place of publication: Publisher.
| + | |
| − | | + | |
| − | [5] Author, E. (Year, Month date). Title of the article. In A. Editor, B. Editor, and C. Editor. Title of published proceedings. Paper presented at title of conference, Volume number, first page-last page. Place of publication.
| + | |
| − | | + | |
| − | [6] Institution or author. Title of the document. Year. [Online] (Date consulted: day, month and year). Available: http://www.scipedia.com/document.pdf.
| + | |
| − | -->==
| + | |
The last improvements in programming languages, programming models, and frameworks have focused on abstracting the users from many programming issues. Among others, recent programming frameworks include simpler syntax, automatic memory management and garbage collection, which simplifies code re-usage through library packages, and easily configurable tools for deployment. For instance, Python has risen to the top of the list of the programming languages due to the simplicity of its syntax, while still achieving a good performance even being an interpreted language. Moreover, the community has helped to develop a large number of libraries and modules, tuning them to obtain great performance.
However, there is still room for improvement when preventing users from dealing directly with distributed and parallel computing issues. This paper proposes and evaluates AutoParallel, a Python module to automatically find an appropriate task-based parallelization of affine loop nests to execute them in parallel in a distributed computing infrastructure. This parallelization can also include the building of data blocks to increase task granularity in order to achieve a good execution performance. Moreover, AutoParallel is based on sequential programming and only contains a small annotation in the form of a Python decorator so that anyone with little programming skills can scale up an application to hundreds of cores.
