A comparison of the Cray XMT and XMT‐2
Identifieur interne : 000535 ( Istex/Checkpoint ); précédent : 000534; suivant : 000536A comparison of the Cray XMT and XMT‐2
Auteurs : Shahid H. Bokhari [États-Unis] ; Saniyah S. Bokhari [États-Unis]Source :
- Concurrency and Computation: Practice and Experience [ 1532-0626 ] ; 2013-10.
English descriptors
- Teeft :
- Algorithm, Better performance, Bioinformatics, Biomedical informatics, Bokhari, Clock cycles, Computat, Computational biology, Concurrency, Concurrency computat, Copyright, Cougar, Cray, Dynamic programming, Dynamic programming codes, Egret, Exper, John wiley sons, Large problem sizes, Main loop, Matrix, Matrix multiplication, Matterhorn, Maximum number, Memory access, Memory access times, Memory accesses, Memory cycles, Memory operations, Memory subsystem, Multithreaded supercomputers, Ohio state university, Parallelizing, Pract, Problem size, Problem sizes, Proc, Proc cougar, Proc matterhorn, Processor, Processor cougar, Processor egret, Processors figure, Reassortment, Reassortment networks, Saturation phenomenon, Sequence alignment, Slab size, Small problem sizes, Supercomputing, Supercomputing centre, Target machines, Total number, Traps increase, Virus reassortment algorithm.
Abstract
We explore the comparative performance of the Cray XMT and XMT‐2 massively multithreaded supercomputers. We use benchmarks to evaluate memory accesses for various types of loops. We also compare the performance of these machines on matrix multiply and on three previously implemented dynamic programming algorithms. It is shown that the relative performance of these machines is dependent on the size (number of processors) of the configuration, as well as the size of the problem being evaluated. In particular, small configurations of the original XMT can sometimes show slightly better performance than larger configurations of the XMT‐2, for the same problem size. We note that, under heavy memory load, performance of loops can saturate well before the maximum number of processors available. This suggests that it may not always be useful to use the maximum number of processors for a specific run. We also show that manual restructuring of nested loops, including decreasing the parallelism, can result in major improvements in performance. The results in this paper indicate that careful exploration of the space of problem sizes, number of processors used, and choices of loop parallelization can yield substantial improvements in performance. These improvements can be very significant for production codes that run for extended periods of time. Copyright © 2012 John Wiley & Sons, Ltd.
Url:
DOI: 10.1002/cpe.2909
Affiliations:
Links toward previous steps (curation, corpus...)
Links to Exploration step
ISTEX:047DFC4DBE0E86719879263C10CDBD10A1EF0C9ALe document en format XML
<record><TEI wicri:istexFullTextTei="biblStruct"><teiHeader><fileDesc><titleStmt><title xml:lang="en">A comparison of the Cray XMT and XMT‐2</title>
<author><name sortKey="Bokhari, Shahid H" sort="Bokhari, Shahid H" uniqKey="Bokhari S" first="Shahid H." last="Bokhari">Shahid H. Bokhari</name>
</author>
<author><name sortKey="Bokhari, Saniyah S" sort="Bokhari, Saniyah S" uniqKey="Bokhari S" first="Saniyah S." last="Bokhari">Saniyah S. Bokhari</name>
</author>
</titleStmt>
<publicationStmt><idno type="wicri:source">ISTEX</idno>
<idno type="RBID">ISTEX:047DFC4DBE0E86719879263C10CDBD10A1EF0C9A</idno>
<date when="2013" year="2013">2013</date>
<idno type="doi">10.1002/cpe.2909</idno>
<idno type="url">https://api.istex.fr/ark:/67375/WNG-QQKFKKT7-F/fulltext.pdf</idno>
<idno type="wicri:Area/Istex/Corpus">001D58</idno>
<idno type="wicri:explorRef" wicri:stream="Istex" wicri:step="Corpus" wicri:corpus="ISTEX">001D58</idno>
<idno type="wicri:Area/Istex/Curation">001D58</idno>
<idno type="wicri:Area/Istex/Checkpoint">000535</idno>
<idno type="wicri:explorRef" wicri:stream="Istex" wicri:step="Checkpoint">000535</idno>
</publicationStmt>
<sourceDesc><biblStruct><analytic><title level="a" type="main">A comparison of the Cray XMT and XMT‐2</title>
<author><name sortKey="Bokhari, Shahid H" sort="Bokhari, Shahid H" uniqKey="Bokhari S" first="Shahid H." last="Bokhari">Shahid H. Bokhari</name>
<affiliation wicri:level="1"><country xml:lang="fr">États-Unis</country>
<wicri:regionArea>Department of Biomedical Informatics, The Ohio State University, OH, Columbus</wicri:regionArea>
<wicri:noRegion>Columbus</wicri:noRegion>
</affiliation>
<affiliation></affiliation>
<affiliation wicri:level="1"><country wicri:rule="url">États-Unis</country>
</affiliation>
</author>
<author><name sortKey="Bokhari, Saniyah S" sort="Bokhari, Saniyah S" uniqKey="Bokhari S" first="Saniyah S." last="Bokhari">Saniyah S. Bokhari</name>
<affiliation wicri:level="1"><country xml:lang="fr">États-Unis</country>
<wicri:regionArea>Department of Computer Science and Engineering, The Ohio State University, OH, Columbus</wicri:regionArea>
<wicri:noRegion>Columbus</wicri:noRegion>
</affiliation>
</author>
</analytic>
<monogr></monogr>
<series><title level="j" type="main">Concurrency and Computation: Practice and Experience</title>
<title level="j" type="alt">CONCURRENCY AND COMPUTATION: PRACTICE AND EXPERIENCE</title>
<idno type="ISSN">1532-0626</idno>
<idno type="eISSN">1532-0634</idno>
<imprint><biblScope unit="vol">25</biblScope>
<biblScope unit="issue">15</biblScope>
<biblScope unit="page" from="2123">2123</biblScope>
<biblScope unit="page" to="2139">2139</biblScope>
<biblScope unit="page-count">17</biblScope>
<date type="published" when="2013-10">2013-10</date>
</imprint>
<idno type="ISSN">1532-0626</idno>
</series>
</biblStruct>
</sourceDesc>
<seriesStmt><idno type="ISSN">1532-0626</idno>
</seriesStmt>
</fileDesc>
<profileDesc><textClass><keywords scheme="Teeft" xml:lang="en"><term>Algorithm</term>
<term>Better performance</term>
<term>Bioinformatics</term>
<term>Biomedical informatics</term>
<term>Bokhari</term>
<term>Clock cycles</term>
<term>Computat</term>
<term>Computational biology</term>
<term>Concurrency</term>
<term>Concurrency computat</term>
<term>Copyright</term>
<term>Cougar</term>
<term>Cray</term>
<term>Dynamic programming</term>
<term>Dynamic programming codes</term>
<term>Egret</term>
<term>Exper</term>
<term>John wiley sons</term>
<term>Large problem sizes</term>
<term>Main loop</term>
<term>Matrix</term>
<term>Matrix multiplication</term>
<term>Matterhorn</term>
<term>Maximum number</term>
<term>Memory access</term>
<term>Memory access times</term>
<term>Memory accesses</term>
<term>Memory cycles</term>
<term>Memory operations</term>
<term>Memory subsystem</term>
<term>Multithreaded supercomputers</term>
<term>Ohio state university</term>
<term>Parallelizing</term>
<term>Pract</term>
<term>Problem size</term>
<term>Problem sizes</term>
<term>Proc</term>
<term>Proc cougar</term>
<term>Proc matterhorn</term>
<term>Processor</term>
<term>Processor cougar</term>
<term>Processor egret</term>
<term>Processors figure</term>
<term>Reassortment</term>
<term>Reassortment networks</term>
<term>Saturation phenomenon</term>
<term>Sequence alignment</term>
<term>Slab size</term>
<term>Small problem sizes</term>
<term>Supercomputing</term>
<term>Supercomputing centre</term>
<term>Target machines</term>
<term>Total number</term>
<term>Traps increase</term>
<term>Virus reassortment algorithm</term>
</keywords>
</textClass>
</profileDesc>
</teiHeader>
<front><div type="abstract">We explore the comparative performance of the Cray XMT and XMT‐2 massively multithreaded supercomputers. We use benchmarks to evaluate memory accesses for various types of loops. We also compare the performance of these machines on matrix multiply and on three previously implemented dynamic programming algorithms. It is shown that the relative performance of these machines is dependent on the size (number of processors) of the configuration, as well as the size of the problem being evaluated. In particular, small configurations of the original XMT can sometimes show slightly better performance than larger configurations of the XMT‐2, for the same problem size. We note that, under heavy memory load, performance of loops can saturate well before the maximum number of processors available. This suggests that it may not always be useful to use the maximum number of processors for a specific run. We also show that manual restructuring of nested loops, including decreasing the parallelism, can result in major improvements in performance. The results in this paper indicate that careful exploration of the space of problem sizes, number of processors used, and choices of loop parallelization can yield substantial improvements in performance. These improvements can be very significant for production codes that run for extended periods of time. Copyright © 2012 John Wiley & Sons, Ltd.</div>
</front>
</TEI>
<affiliations><list><country><li>États-Unis</li>
</country>
</list>
<tree><country name="États-Unis"><noRegion><name sortKey="Bokhari, Shahid H" sort="Bokhari, Shahid H" uniqKey="Bokhari S" first="Shahid H." last="Bokhari">Shahid H. Bokhari</name>
</noRegion>
<name sortKey="Bokhari, Saniyah S" sort="Bokhari, Saniyah S" uniqKey="Bokhari S" first="Saniyah S." last="Bokhari">Saniyah S. Bokhari</name>
<name sortKey="Bokhari, Shahid H" sort="Bokhari, Shahid H" uniqKey="Bokhari S" first="Shahid H." last="Bokhari">Shahid H. Bokhari</name>
</country>
</tree>
</affiliations>
</record>
Pour manipuler ce document sous Unix (Dilib)
EXPLOR_STEP=$WICRI_ROOT/Sante/explor/PandemieGrippaleV1/Data/Istex/Checkpoint
HfdSelect -h $EXPLOR_STEP/biblio.hfd -nk 000535 | SxmlIndent | more
Ou
HfdSelect -h $EXPLOR_AREA/Data/Istex/Checkpoint/biblio.hfd -nk 000535 | SxmlIndent | more
Pour mettre un lien sur cette page dans le réseau Wicri
{{Explor lien |wiki= Sante |area= PandemieGrippaleV1 |flux= Istex |étape= Checkpoint |type= RBID |clé= ISTEX:047DFC4DBE0E86719879263C10CDBD10A1EF0C9A |texte= A comparison of the Cray XMT and XMT‐2 }}
![]() | This area was generated with Dilib version V0.6.34. | ![]() |