科 学 技 術 計 算 分 科 会

選 出

SS 研 HPC フォーラム 2010 より海外招待講演

Extreme Computing: Challenges,
Constraints and Opportunities

Anne Trefethen
Oxford University

26th August, 2010

Fujitsu's HPC Users Group Meeting

Extreme Computing: Challenges,
Constraints and Opportunities
Anne E Trefethen
PreambleThis paper is a handout to support the presentation at the Fujitsu HPC Users Group Meeting on 26th
August, 2010.

Abstract
Scientific applications require an ecosystem of computational infrastructure that can allow
distributed collaboration and computation, large‐scale simulation and analysis and appropriate
consideration of data driven science. The ecosystem requires the integration of high‐performancecomputing, in some cases to the exascale, cloud computing, databases, high bandwidth networks
and the software and people infrastructure that enables the effective use of the components.
In this presentation we will consider some of the challenges and constraints that drive thedevelopment of the computational infrastructure and its components – including computationalmodels, energy and knowhow; and the opportunities that are presented, in terms of new science
applications and new algorithmic approaches. There is a particular focus on energy.

Key words
Exascale, extreme computing, energy efficiency, cloud computing

Introduction
Advanced computing is an essential tool in addressing scientific problems of national and scientificinterest, including climate change, the virtual human, new materials, next‐generation power sources
and astrophysics, but as importantly it is equally essential to solve commercial and industrial
problems in financial modelling, engineering, and real‐time decision systems.
Extreme computing has moved from being a somewhat esoteric interest of a few scientists to anecessity for any computational scientist or developer who uses simulation as a tool. A shift has
occurred in recent years as the processor chip designs mimic the architecture of high‐performancecomputers, with multiple processing cores on a single chip, making efficient programming of a single
processor computer as complex as it once was to develop software for a high‐performancecomputer.

1

26th August, 2010

Fujitsu's HPC Users Group Meeting

The interface to extreme computing is also changing with increasing availability of infrastructure andservices through Cloud Computing enabling access to both high‐performance and high‐throughput
computing.
The computers and computer systems, however, are still largely designed with little thought to theapplications that might use them and often arrive to the users with little software infrastructure inplace. The development of the required software infrastructure is becoming increasingly complex
and if we are to be effective in the use of these systems there is a need to address this throughappropriate abstractions, programming languages and tools to support application developers andusers.
A further pressure point for extreme computing is the constraint that energy requirements arehaving, and will continue to have, on the developments of computer architectures and their use.
This becomes increasingly important both in terms of the general computing infrastructure which is
becoming a significant component of national use of electricity [1] and for the high‐end computer
systems, with the predictions of the exascale energy requirements up to 100MW [2] – more thanwould be required by a small town. Given that a standard dual‐core laptop is equivalent to one of
the Top500 machines of only 12 years ago we can expect these issues to be pervasive as we go
forward.
This presentation provides an overview of the challenges that are faced in extreme computing,
together with some of the ongoing activities to provide a roadmap for future developments.
Focussing on energy as a driver there is a consideration of some of the research and activities acrossthe ecosystem of computing and in particular we consider that required for the Square Kilometre
Array [3] which provides an excellent co‐design vehicle1.
Ultimately our interest is in providing a framework to allow the development of applications andalgorithms that are energy‐aware and will allow the user to make choices regarding the objective
optimized in the software – be it energy performance, price performance or indeed computational
performance.

1

A co‐design vehicle is a concept described in [ref] and is essentially an application that is developed inconjunction with the design of the software and hardware infrastructure together.

2

26th August, 2010

Fujitsu's HPC Users Group Meeting

Extreme Computing Challenges and Constraints
There have been many studies during the last several years that have addressed the requirements ofextreme (or exascale) computing [4, 5]. Here we will provide a general overview with some specifics
from a recent study in the UK focussed on the development of a roadmap for high‐performancecomputing [6] and the roadmap of the International Exascale Software Program [7] but the reader isreferred to the original texts for the full discussion and details.
The HPC/NA roadmap activity in the UK brought together computational scientists, mathematicians
and computer scientists to understand what might be the key issues for the future of extreme
computing both in the UK and within an international context. The activity held a number ofworkshops and had individual communications with scientists and groups in the UK and a review ofthe literature from other national activities was included to provide the international perspective. It
did not address hardware challenges directly, but the whole discussion was of course motivated by
the changing face of computing hardware. The IESP roadmap provides a good overview of the
hardware expectations [8]. As we go forward, we can expect that power and cooling limits willcontinue to constrain clock speeds; we will see a shift to multi/many core with attendanthierarchical parallelism an often with the additional complexity of hardware accelerators. This canbe seen by the evidence of the Top 500 machines where multi‐core machines and those with GPUs
and the like are an increasing proportion [9]. Memory bandwidth will continue to be a bottleneck
and this is likely to get worse. Chip design and chip to chip communication capabilities are likely tochange however with 3D stacking and integration designs, for example [10] and the introduction ofhigh‐speed optical communications [11].
The HPC/NA roadmap activity found there were five major themes that dominated the discussions.

Theme 1: Cultural Issues
There are gaps between disciplines that meant that often the team effort that might be required tobring a large‐scale application together was not optimal and that appropriate knowledge andexpertise might not be captured within such an effort. This is a common issue and many national
activities are investing to ensure that community actions are supported and interdisciplinary teams
created.
Differences in discipline communities were also identified in that some application domain scientists
are used to sharing models and codes, and reusing other software developed by other groups; while
for other domains this approach is almost completely alien with codes being entirely developed
within a particular group and little use being made of libraries or other third‐party software.
Similarly there is a need to ensure that the software activities are not only focussed at a national
level but are within an international context. It is the case that several application codes in the UK
are dependent up on software that has been developed in programmes in other countries and viceversa. These dependencies are a risk to the sustainability of the software and that risk can only be
mitigated by international collaboration.

3

26th August, 2010

Fujitsu's HPC Users Group Meeting

Theme 2: Applications and Algorithm development
There are many issues that need to be addressed in the area of application and algorithm
development. These include ensuring that a component approach to development is taken whereappropriate such that algorithms that might underpin multiple application areas are developed assuch. Having noted that, many applications involve multiple models at different scales or fordifferent elements of the application and integration of components is not possible without
appropriate standards for data models and formats, interoperability of programming models, andlack of knowledge of error propagation through the integrated system. Clearly this is not a problem
unique to extreme computing, but is one that as a community we have yet to address fully.
The memory hierarchy of high‐performance computers is on course to get even more complex which
will drive the needs for hierarchical algorithms to deal with bandwidth across the memory hierarchy
together with software strategies to mitigate high memory latencies. This will in turn drive the needfor algorithms to be dynamically adaptive, perhaps as components of an active library, and of course
scalable much beyond the present status quo. There are few applications that can scale to petaflops
levels let alone toward exascale. Such scaling can only be achieved with appropriate portioning andload balancing and effective data management. Data‐intensive science [12] is increasingly importantand the ability to manage large amounts of data effectively and efficiently is crucial [13]. Moving
data takes energy, at every level of the system – this is a point we will return to later.

Theme 3: Software Challenges
Development of software is becoming increasingly complex and without appropriate software
engineering, in the context of an exascale system, will be un‐maintainable. Application scientists are
not usually software engineers but there is a need to ensure that by some means appropriate
practice is adopted. Frameworks and tools to support software development will be needed
together with compilers and code generation tools that can provide a layer of abstraction for
application scientists.

Theme 4: Sustainability
The HPC/NA Roadmapping activity identified a general concern regarding the sustainability of
application codes, software libraries and skills (we consider skills in the next section). This issue is
integral to that of programming models, interoperability and also the cultural issues above.
Scientists are naturally loathed to invest a great deal of effort in the development of software thatwill last only the lifetime of a particular computer architecture, compiler or other dependent
component of the environment. We can only address this issue as a community as we agree in the
adoption of standards and open source mechanisms.

Theme 5: Knowledge Base
It is important to ensure that computational scientists have the right set of skills, and this set of skills
needs constantly updating. Within the UK activity it was also discovered that there was a lack ofawareness by some members of the community of existing libraries/packages. Maintaining a strong
knowledge base will require education for graduate students as well as the opportunity for life‐longlearning. The report on exascale computing for energy and environment [14] notes “The current
belief is that the broad market is not likely to be able to adopt multi‐core systems at the 1000‐
processor level without a substantial revolution in software and programming techniques for the4

26th August, 2010

Fujitsu's HPC Users Group Meeting

hundreds of thousands of programmers who work in industry and do not yet have adequate parallel
programming skills.”

Other issues:
Since the last of the roadmapping workshops Cloud Computing [15] has matured and is now verymuch part of the computational environment. It offers a different interface to distributed, and insome cases, high‐performance computing and as such is part of the evolving ecosystem forapplication development. As data‐intensive applications dominate it is possible that the businessmodels underpinning Cloud computing might offer benefits to scientists. These issues will likely beresolved as computational scientists become engaged with the various vendors but there is noquestion that the scale of Cloud computing infrastructure may offer benefits in terms of energy
efficiency and from that point of view we will return to them as part of the ecosystem later.

Co­Design Vehicles and the Square Kilometre Array
During the workshops and activities of the Department of Energy in the USA addressing therequirements for exascale computing, the notion of a co‐design vehicle has been adopted. At
present, other than in a few specific cases [15, 16, 17], a computer system is designed with little
thought for the applications that will use it, and the software is generally designed to try to fit the
hardware. In the co‐design model the two are seen as part of the same system and the design ofeach is done through collaboration. In the extreme this might result in computer systems that are
only useful for a given application such as [15, 16, 17] but the model can be adopted to enable moregeneric progression with the evolution of the computer architect and algorithms being betteraligned and providing better capability and specifically energy performance.
We are interested in the computing challenge provided by the development of the Square Kilometre
Array [?], the next generation radio telescope. The telescope is in the design phase with theanticipation that construction of the first phase will begin in 2016 with the full telescope completed
and in operation by 2022. The SKA will likely be located in either Australia or South Africa, in adesert so as to have little or no interference, but is a collaborative effort of over 50 groups in 19
countries.
The present design [18,19,20] has a combination of aperture arrays in the core and up to 3000
phased array feeds on dishes and a collecting area of approximately one square kilometre withreceptors extending out to a distance of 3000km from the centre of the telescope (figure 1). It willallow a sensitivity of more than 50 times that of existing telescopes, and 10,000 times the survey
speed and will provide data to answer fundamental science questions on gravitation and magnetism,galaxy formation and even the question of life on other planets. The design of the SKA is developing
through design studies based on the science requirements, Pathfinder telescopes that provide
experience of design options, and technology capability considerations.

526th August, 2010

Fujitsu's HPC Users Group Meeting

Figure 1 Possible configuration of SKA receptors and artist’s impression of SKA core(from [21])The SKA provides a fabulous information technology challenge with a typical data rate from eachdish antenna on the order of 100Gbs‐1 aggregating to over 100Tbs‐1 [21] and need for Exaflop
computation [23] for post‐processing. The infrastructure required to support the various sciencecases will need to range from real‐time capability to transport and analyse the data at these high‐data rates and the capacity to store and “publish” the data for later analysis and interpretation by
the global astrophysics community. The computational systems will likely range from specificallydesigned FPGA‐like units to exascale computing and Cloud‐like data centres. The communications
infrastructure will range from intra‐chip and inter‐chip with optical fibre to the correlator and on to ahigh‐performance computer, to trans‐oceanographic with the latter having data rates of at least
100Gbs‐1 over the general network providers. The SKA will succeed or not depending on both thephysical implementation of the telescope design and the software infrastructure that will enable it.
The software infrastructure required to realise this information technology challenge is itself has
been identified as > 2000 person year task [22] but even this may not take full account of thecomplexity of the task.
Figure 2: SKA computational requirements in context of Top500 [23]The fundamental algorithms in
the SKA data pipeline include
beamforming,
gridding,
convolution
andfilteringalgorithms. Cornwell et al [23]estimate the computational
requirements in the context of
the Top500 and show them tobe beyond the scale ofprojected performance in thetimescale required (figure 2).
Alongside the challenges of thecomputational
infrastructure
are the related challenges ofpowering the infrastructure.
This includes the power6

26th August, 2010

Fujitsu's HPC Users Group Meeting

required for the core antennas (~30MW) and the remote stations ~0.5MW) and the various
computational components including high‐performance computing (~40MW) data transmission(~?MW) and Cloud (or equivalent) provision (~?MW). Energy provision is a major design factor in
the delivery of the telescope – plans to mitigate the energy constraints include renewable energy
sources (sun) providing the station power and it is easy to see that the SKA could possibly be thelargest Green IT project ever to be considered.

Counting Joules
As indicated above the ecosystem of computational resources required to enable the SKA provides aplethora of challenges and opportunities where energy efficiency is concerned.
Moving data takes energy whether the data is moving from L2 cache on chip or within a transatlantic
Data Cloud. Effective management of that data communication is a major component of any
optimal energy model.
There has been a great deal of research on wireless network
communications and sensor networks, where devices are most often low‐energy devices withbattery constraints. Indeed a lot of research has been done in general on low‐energy devices
including computational algorithms from which we might learn. The existing communications
network across the globe relies on hundreds of thousands of switches and routers and these, unlike
wireless or mobile infrastructure, do not power down when idle. The network is a complex systemof different technologies and it is difficult to predict the energy consumption under different
circumstances so sending data 10 times as fast might use interfaces that use 100 times the amountenergy or in some cases (e.g. newer optical ones) 1000 times less [24]. A good overview of network
energy costs for realistic configurations can be found in [25]. There are a number of research efforts
considering the issues around Green network communications including INTERNET [26] and others
can be seen at recent conferences [27,28]. Of course as energy‐aware systems are developed there
are still issues of what they optimise – usage or cost? Qureshi et al [29] illustrate effective ways inwhich energy‐aware data centres can optimise cost by moving computation to nearby states where
electricity costs are less.
Optimizing energy usage in large‐scale data centres and Clouds is almost a science in itself.
McKinsey and the UpTime Insitute [1] indicate that the energy used by data centres in the US is
becoming a significant percentage and is likely to overtake airlines in terms of carbon emissions. The
report states that the average data centre uses as much power as 25,000 households, but that
estimate is probably somewhat out of date as in the last few years Cloud provisioners have built very–large scale data centres across the US [30].
On a somewhat smaller scale at the Oxford
Supercomputing Centre (OSC) we have developed software that intelligently powers down
components of the systems at times of under utilisation. The indications are that this will provide
significant savings.
The McKinsey report identifies a number of issues around the effectiveness of data centres including
siloed organisations and limited transparency that match very well with the findings of the HPC/NA
for that community. McKinsey make the recommendation that metrics be defined that are not only
measuring the facility but are linked to the applications using it and the processes integral to it. A
consortium called the Green Grid is now in place with the aim to develop standards and best7

26th August, 2010

Fujitsu's HPC Users Group Meeting

practice for data centres. The recommendation regarding metrics is one that we, as a community,
should also take on board as we develop exascale technology.
At the computing system level there are many approaches to energy efficiency. Again there is alarge knowledge base in the low‐energy systems community that we should consult. Indeed an
approach that might be considered for some application areas builds directly on the low‐energy
embedded microprocessor technology to build petascale systems. This approach is underdevelopment for the Green Flash system [31, 32] at Berkeley National Laboratory where researchers
are collaborating directly with Tensilica, Inc. to explore the use of Tensilica's Xtensa processor coresin building a computer to model clouds (that is clouds in the weather system not as a computer
system!). They believe that a specially designed core could get 10–100 times better performance
per watt. The Green Flash design will have on the order of 20 million processors consuming lessthan 4 MW whereas the equivalent in conventional microprocessors would require around 200MW.
With appropriate systems support it is possible to provide hooks into the operating system to allow
spindown policies to be enacted, adaptive placement of memory blocks, agile use of component
devices and of course energy‐aware routing [33].To make use of this level of support it would be
helpful to have tools that can provide a mapping from the higher‐level action to the underlying
activity.
The power cost for a device is proportional to the frequency cubed. This means that a multi‐core
device that is running at a lower clock rate is bound to provide the potential for higher performanceat a lower energy cost. Interesting issues arise when there are multiple such devices to hand andthe algorithm designer can chose to optimise the energy usage for a given computational
performance. At this point in time the SKA community are considering the use of GPUs, FPGAs andmulti‐core chips [34, 35]. Nieuwpoort et al [34] show some interesting results in this area where
they have used a variety of chipsets to underpin the computation to correlate signals. The results
are particularly interesting in respect to the achieved efficiency vs Gflops/Watt where although agiven device might underperform in terms of percentage efficiency it may still perform better in
Gflops/Watt. The Green500 provide good reference indicators for feasible platforms at this time
[36].
Within the Oskar project [37] we tackled the Digital beamforming for the aperture array componentsof the SKA that pose considerable computational challenges [38]. The proposed algorithm provides
a hierarchical algorithm for beamforming using a simplified and flexible computational approach of
direct matrix‐vector multiplies rather than FFTs that provides a reduced data rate and acomputational cost of forming beams of 1TFlop as opposed to 20TFlops for the FFT approach.
Within PrepSKA [39] Savlini et al [40] have developed a Pipeline for Extensible Lightweight Imaging
and Calibration (PELICAN). This framework for parallel quasi‐real time data processing offers two
deployment options either with the server supplying multiple pipelines or the pipeline connecting to
the data stream directly. PELICAN allows reuse of modular components and will be deployed on
LOFAR [41] interferometer stations to allow all sky calibration and imaging, and pre‐processing forpulsar searching. The modular framework allows appropriate computational components to be
implemented on appropriate devices, in this case GPGPUs.

8

26th August, 2010

Fujitsu's HPC Users Group Meeting

Tools, Benchmarks, metrics
While benchmarks for datacentres and systems are now relatively mature [42, 43] there is still work
to be done at the numerical algorithms level. On the exascale roadmap [8] it is suggested thatstandards to support energy‐aware algorithms should be agreed in 2014/2015 with energy‐aware
libraries available in 2016. We have our work cut out!
Although for the SKA specific algorithms of interest we can model and implement across different
platforms there is a lack of agreed metrics, tools and benchmarks to provide the community withclear evidence to support design features.
This is true across the board for computationalalgorithms although there are some efforts in this direction.
There are a number of tools for a variety of platforms that will allow measurements of device andsub‐device power usage. Kirk Cameron and his group have created a profiling tool that is an open
source software system together with hardware power measurement devices, PowerPack [44].
Using the profiler they have analysed the HPC Challenge Benchmarks [45] and been able to provide
very clear analysis of the behaviour of the algorithms in terms of energy used.
It may be time to consider again what benchmarks should stress. As we consider adaptive algorithms
that are able to autotune to heterogeneous sets of processors we may need to consider a different
set of characteristics and metrics that are captured by existing suites. There may be instances where
replacing data movement by computation provides a saving in energy while maintaining
computational speed.

Conclusions
Energy constraints provide one of the major challenges for extreme computing in the future. There
are opportunities at every level of the computational infrastructure to address the challenges
through both efficient physical hardware but also through more sophisticated use of the physicalinfrastructure. An intelligent software infrastructure could reduce the energy use on chip, within aprocessor, between processors, between computers, across Cloud platforms and indeed overinternational boundaries.
Ultimately our own interest lies in the development of energy‐aware algorithms for extreme
computing. We believe that to achieve such algorithms and to see the benefits there will need to besignificant investment in the support of tools and low‐level mechanism to allow the profiling ofenergy use across platforms. Equally important are standard metrics and computational
benchmarks that will allow agreement on measures of “success”. Just as the linpack benchmark hascome to be seen as the measure of the performance of a computer system we need the equivalentapplication/algorithm benchmarks that capture the energy characteristics of any given system.
The future holds continuing complexity in computing systems from the combinations of computing
within the whole ecosystem to the heterogeneity of chips on our laptops. The most effective
algorithms at any given point in time for any specific application are going to depend upon the
choices that can be made given the hardware configurations. In general, at present we cannot evenarticulate those choices let alone provision the most appropriate algorithm. This challenge of9

26th August, 2010

Fujitsu's HPC Users Group Meeting

articulation and optimal algorithm design can only be addressed through a co‐design approach withhardware, software and application scientists working together.
While we have focussed here on the energy aspects of the problem, and specifically as driven by
SKA, there are any one of several other key issues that could and should be addressed including thecomplexity of the software development for such an infrastructure, the usability of the softwaresystems, the data management and related semantic issues for such colossal data systems or theprovision of imaging and data analysis in the Cloud. Each of these is a talk of its own – for next time.

Acknowledgements
My thanks to colleagues on the prepSKA project Steve Rawlings, Aris Karastergiou, Stef Salvini, Ben
Mort, Chris Williams, Fred Dulwich and Andy Faulkner. The HPC/NA project was in collaboration
with Nick Higham, Iain Duff, Peter Coveney, Mark Hylton and Stef Salvini. I am grateful to Jeyan
Thiyagalingam, Simon McIntosh‐Smith, Jon Crowcroft and Jaafar Elmirghani for their input andsuggestions.

References
1. Revolutionizing Data Center Efficiency, McKinsey Company and the Uptime Institute,www.mckinsey.com/.../Revolutionizing_Data_Center_Efficiency.pdf
2. www.exascale.org
3. The SKA project: www.skatelescope.org/
4. The DARPA Exascale Study Report:
http://users.ece.gatech.edu/mrichard/ExascaleComputingStudyReports/exascale_final_repo
rt_100208.pdf
5. The Department of Energy workshop on extreme computing:
http://extremecomputing.labworks.org/index.stm
6. The HPC/NA Roadmap: www.oerc.ox.ac.uk/research/hpc‐na/roadmap
7. The International Exascale Software Project: www.exascale.org
8. The IESP roadmap: http://www.exascale.org/mediawiki/images/4/42/IESP‐roadmap‐1.0.pdf
9. The Top500 machines: www.top500.org
10. Intel http://www.eetimes.com/electronics‐news/4204959/Intel‐Silicon‐Optics
11. 3D DRAM Design and Application to 3D Multicore Systems, Hongbin Sun, Jibang Liu, Rakesh
S. Anigundi, Nanning Zheng, Jian‐Qiang Lu, Kenneth Rose, Tong Zhang, IEEE Design and Testof Computers, vol. 26, no. 5, pp. 36‐47, September/October, 2009.
12. The Fourth Paradigm: Data Intensive Research,http://research.microsoft.com/en‐
us/collaboration/fourthparadigm/
13. The Data Deluge: An e‐Science Perspective, A.J.G. Hey and A.E. Trefethen, in Grid Computing‐ Making the Global Infrastructure a Reality, Berman, Fox, Hey, eds., pp 809‐824, Wiley andSons, 2003.
14. DOE Report on Modeling and Simulation at the Exascale for Energy and the Environment,
June 2007
15. Above the Clouds: A Berkeley View of Cloud Computing, Michael Armbrust, Armando Fox,
Rean Griffith, Anthony D. Joseph, Randy Katz, Andy Konwinski, Gunho Lee, David Patterson,10

26th August, 2010

Fujitsu's HPC Users Group Meeting

Ariel Rabkin, Ion Stoica, and Matei Zaharia, UC Berkeley Reliable Adaptive Distributed
Systems Laboratory . http://radlab.cs.berkeley.edu/ February 10, 2009
16. The QCDOC project: ukqcd.epcc.ed.ac.uk/community/qcdoc/
17. The MD‐Grape3 machine: http://www.peta.co.jp/index‐en.html
18. The D.E.Shaw Machine: www.deshawresearch.com/
19. The Square Kilometre Array, http://www.skatelescope.org/
20. The Square Kilometre Array, Peter E. Dewdney, Peter J. Hall, Richard T. Schilizzi, and T.
Joseph L. W. Lazio, Proceedings of the IEEE | Vol. 97,No. 8, August 2009
21. The Square Kilometer Array (SKA) Radio Telescope: Progress and Technical Directions, P.J.
Hall, Richard T. Schilizzi, and T. Joseph L. W. Lazio, U.R.S.I, The Radio Telescope Bulletin, No
326, September 2008
22. SKA Memo 100: Preliminary Specifications for the Square Kilometre Array, R. T. Schilizzi, P.
Alexander, J. M. Cordes, P. E.Dewdney, R. D. Ekers, A. J. Faulkner, B. M. Gaensler, P. J. Hall, J.
L. Jonas, K. I. Kellermann,
http://www.skatelescope.org/PDF/memos/100_Memo_Schilizzi.pdf
23. Scaling Mount Exaflop: from the pathfinders to the Square Kilometre Array, T.J. Cornwell,
Ger van Diepen, www.atnf.csiro.au/people/tim.cornwell/publications/MountExaflop.pdf
24. Green Optical Communications—Part II: Energy Limitations in Networks, Rodney S. Tucker,
IEEE JOURNAL OF SELECTED TOPICS IN QUANTUM ELECTRONICS
25. Private communication with Jon Crowcroft
26. First ACM SIGCOMM Workshop on Green Networking, August 2010,
http://conferences.sigcomm.org/sigcomm/2010/gncfp.php
27. INTERNET: Intelligent Energy Aware Networks, http://www.internet‐project.org.uk/
28. E‐energy: First international conference on energy‐efficient computing and networking, April
2010, http://www.e‐energy.uni‐passau.de/
29. Cutting the Electric Bill for Internet‐Scale Systems, A. Qureshi, R. Weber, H. Balakrishnan, J.
Guttag and B. Maggs. SIGCOMM 2009.
30. Data Centres in the News:
http://www.datacenterknowledge.com/archives/2010/02/05/virginia‐nc‐battling‐for‐microsoft‐data‐center/
31. The Green Flash computer project, http://www.lbl.gov/cs/html/greenflash.html
32. Towards Ultra‐High Resolution Models of Climate and Weather , Michael Wehner, Leonid
Oliker, and John Shalf, International Journal of High Performance Computing Applications
May 2008 22: 149‐165, doi:10.1177/1094342007085023
33. Every Joule is Precious: The Case for Revisiting Operating System Design for Energy
Efficiency, Amin Vahdat, Alvin Lebeck, and Carla Schlatter Ellis, Proceedings of the 9thworkshop on ACM SIGOPS European workshop: beyond the PC: new challenges for theoperating system Pages: 31 – 36, 2000 ISBN:1‐23456‐789‐0
34. Using many‐core hardware to correlate radio astronomy signals, Rob V. van Nieuwpoort,
John W. Romein, Proceedings of the 23rd international conference on Supercomputing,pages: 440‐449, 2009, ISBN:978‐1‐60558‐498‐01
35. Evaluating Multi‐Core Platforms for HPC Data‐Intensive Kernels, Alexander S. van Amesfoort,
Ana L. Varbanescu, Henk J. Sips, Delft University of Technology, The Netherlands
36. The Top Green 500 Computers, www.green500.org
37. The OSKAR project: http://www.oerc.ox.ac.uk/research/oskar
1126th August, 2010

Fujitsu's HPC Users Group Meeting

38. OSKAR: Simulating Digital Beamforming for the SKA Aperture Array, Fred Dulwich, Benjamin
J. Mort, Stefano Salvini, Kristian Zarb Adami, and Mike E. Jones, Widefield Science andTechnology for the SKA, SKADS Conference 2009

39. Preparation for SKA: www‐astro.physics.ox.ac.uk/~sr/prepska.html
40. The Pelican framework: https://wiki.oerc.ox.ac.uk/svn/pelican/slides/pelican‐slides2.ppt
41. The Lofar Pathfinder: www.lofar.org/
42. The SPEC power benchmark, http://www.spec.org/benchmarks.html#power
43. JouleSort: A Balanced Energy‐Efficiency Benchmark, Suzanne Rivoire, Mehul A. Shah,
Parthasarathy, Ranganathan, Christos Kozyrakis, SIGMOD’07, June 11–14, 2007, Beijing,
China
44. PowerPack: Energy Profiling and Analysis of High‐Performance Systems and Applications ,Rong Ge, Xizhou Feng, Shuaiwen Song, Hung‐Ching Chang, Dong Li, Kirk W. Cameron, IEEE
Transactions on Parallel and Distributed Systems, 23 Apr. 2009. IEEE computer Society
Digital Library. IEEE Computer Society,<http://doi.ieeecomputersociety.org/10.1109/TPDS.2009.76>
45. Energy Profiling and Analysis of the HPC Challenge Benchmarks Source, Shuaiwen Song,Rong Ge, Xizhou Feng, Kirk W. Cameron International Journal of High Performance
Computing Applications Volume 23 , Issue 3 (August 2009), Pages: 265‐276, 200912

科 学 技 術 計 算 分 科 会

選 出

SS 研 HPC フォーラム 2010 より

10PetaFLOPS は生命科学で何を実現できるか

理化学研究所姫野 龍太郎SS研HPCフォーラム2010

2010年8月26日

10PetaFLOPSは生命科学で何を実現できるか
理化学研究所

次世代生命体統合シミュレーション研究グループ
グループディレクタ 姫野龍太郎

Keywords
スーパーコンピュータ、生命科学、シミュレーション、分子、細胞、臓器、全身、脳神経系、マルチ
スケール

1. はじめに
次世代スーパーコンピュータは来年度から部分的に稼働が始まり、再来年度には全システムの稼働が予定されている。この稼働に合わせて、生命科学分野でのグランドチャレンジとも呼ばれる次世代生命体統合シミュレーション研究開発プロジェクト（ISLiM）が、2006 年秋から理研を中核拠点として行われている。このプロジェクトはペタスケールのシミュレーション技術によって、ライフサイエンスに仮説-検証型の新たな研究手段を提供し、生命現象を定量的かつ統合的に理解・予測・解明することを目指すと共に、創薬・ヘルスサイエンスサイエンスへの貢献、新規医療技術の実用化を図るものである。

2. 推進体制とソフトウェア開発の状況
このような目的の実現のため、分子・細胞・臓器全身という３つの階層に分かれた研究チームと、大量の実験データから法則に迫るデータ解析融合チーム、更に脳神経系チーム、全てのチームを支える HPC チームの６チームを設置して取り組んでいる。
これらのチームで現在開発中のソフトウェアは量子化学や分子動力学から構造流体連成計算、脳の局所回路モデル、可視化ソフトウェア、並列化のためのミドルウェアなど、合計３４本にのぼる。
これまでの開発で、並列化に関して 1,024 を超えるところまでテストが終わったものが 18 本、8,000
並列までのテストが終わったものは９本という状況である。今後は次世代スーパーコンピュータでの実効性能と実行時間の予測を行い、どの程度のモデルでどのくらいの計算をするかを検討してゆく予定である。

3. 現在の見通し
昨年から開発中のソフトウェアの並列性能などの開発状況を睨みながら、10PetaFLOPS の次世
代スーパーコンピュータを使ってどんな問題を解くかを検討してきた。また、どの問題をどの時期に解いてゆくか、問題間の優先順位をどのようにつけるかを検討した。その結果、それぞれのソフ
トウェアを３つに分類、計算を行う時期に合わせて、第一走者、第二走者、第三走者として、波状的に成果を出してゆくこととした。開発中のソフトウェアの数が多いので、第一走者と第二走者の一部について、そのソフトウェアの概要と解こうとしている問題を紹介する。

䈖䈱⎇ⓥ㐿⊒䈱૏⟎䈨䈔ᰴ਎ઍ䉴䊌䉮䊮㐿⊒䊒䊨䉳䉢䉪䊃䈱৻ㇱ⃻࿷

10PetaFLOPS䈲↢๮⑼ቇ䈪૗䉕ታ⃻䈪䈐䉎䈎ᰴ਎ઍ↢๮૕⛔ว䉲䊚䊠䊧䊷䉲䊢䊮⎇ⓥ㐿⊒䉫䊦䊷䊒䉫䊦䊷䊒䊂䉞䊧䉪䉺ᆢ㊁㦖ᄥ㇢ᐔᚑ㪈㪏ᐕᐲ
䋨㪉㪇㪇㪍䋩

䉲䉴䊁䊛

䷼义
且䷯
万丨
䷡
䷥丱
丈世
䷦ 一丩
䷰
䷡丢
丫
丶
丱䷶
䷷並
丱
乊

ᐔᚑ㪈㪐ᐕᐲ
䋨㪉㪇㪇㪎䋩

᭎ᔨ⸳⸘ᰴ਎ઍ䊅䊉⛔ว䉲䊚䊠䊧䊷䉲䊢䊮

ᐔᚑ㪉㪇ᐕᐲ
䋨㪉㪇㪇㪏䋩

ᐔᚑ㪉㪈ᐕᐲ
䋨㪉㪇㪇㪐䋩

⹦⚦⸳⸘ᐔᚑ㪉㪉ᐕᐲ
䋨㪉㪇㪈㪇䋩

ᕈ⢻

䉼䊠䊷䊆
䊮䉫

⸳⸘

ଏ↪㐿ᆎ

ታ⸽

㐿⊒䊶⵾૞䊶⹏ଔ⸘▚ᯏ᫟ᐔᚑ㪉㪋ᐕᐲ
䋨㪉㪇㪈㪉䋩

⹜૞䊶⹏ଔ䊶⵾ㅧ㐿⊒䊶⵾૞䊶⹏ଔᰴ਎ઍ↢๮૕⛔ว䉲䊚䊠䊧䊷䉲䊢䊮

ᐔᚑ㪉㪊ᐕᐲ
䋨㪉㪇㪈㪈䋩

ታ⸽

ᑪ⸳

ᣉ
⸳
⸳⸘

⎇ⓥ᫟

ಽሶ䉴䉬䊷䊦⎇ⓥ㐿⊒⎇ⓥ㐿⊒䈱᭎ⷐ䈫㆐ᚑ⋡ᮡ䋨䋲䋰䋰䋸ᐕ䋱䋰᦬એ㒠䋩
ၮ␆ᣇ⒟ᑼ䈮ၮ䈨䈒⸃ᨆ⊛䉝䊒䊨䊷䉼䈫䇮ᄢ㊂䈱ታ㛎䊂䊷䉺䈎䉌ᧂ⍮䈱ᴺೣ䈮ㄼ䉎ታ㛎䊂䊷䉺䈎䉌⸃ᨆ䈻䈱䉝䊒䊨䊷䉼䇮䈘䉌䈮䈲ᄙ㓏ጀ䉕ㅪ⚿䈜䉎䉝䊒䊨䊷䉼䈮䉋䉍䇮⇣䈭䉎䉴䉬䊷䊦䈱⎇ⓥ䈫ታ㛎䊂䊷䉺䉕⛔ว⊛䈎䈧᦭ᯏ⊛䈮⚿䈶䈧䈔䇮䊕䉺䉴䉬䊷䊦䈫䈇䈉ᩴ㆑䈇䈱ᕈ⢻䉕ᜬ䈧䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺䈱ᕈ⢻䉕䊐䊦䈮⊒ើ䈚䇮↢૕䈪⿠䈖䉎⒳䇱䈱⃻⽎䉕ℂ⸃䈚ක≮䈮⽸₂䈜䉎䈢䉄䈱䉸䊐䊃䉡䉢䉝䉕㐿⊒䈜䉎䇯䉴䉬䊷䊦㑆ㅪ⚿䉝䊒䊨䊷䉼ታ㛎䊂䊷䉺䈎䉌⸃ᨆ⸃ᨆ⊛䉝䊒䊨䊷䉼
䈻䈱䉝䊒䊨䊷䉼䉟䉥䊮䉼䊞䂾↢๮⃻⽎䈱TGCTCTTATCTTCCTCCCACAGCTC䊈䊦
CTGGCCCATCATGGCTGGTGTGGC⛔ว⊛䈭ℂ⸃
ಽሶ䉴䉬䊷䊦TAATGCCCGCTATTAAACTTAATAAAAAACATTTATTTTCATTGCAATATT䋨䋽↢๮䊒䊨 䉫
TTACTGATATTATACAGGGGGCATG
GTTTGACT……
䊤䊛䈱ℂ⸃䊶ౣ
⃻䊶੍᷹䋩
␹⚻⚦⢩
ዪᚲ࿁〝

⚦⢩䉴䉬䊷䊦

䊂䊷䉺⸃ᨆⲢว⤳ེోり䉴䉬䊷䊦

㐿⊒⋡ᮡ䋺㊂ሶൻቇ⸘▚䋨䌑䌍䋩䊶ಽሶേജቇ⸘▚䋨䌍䌍䋩䊶☻ⷞൻ䊝䊂䊦⸘▚䋨䌃䌇䋩䉕✚วൻ䈜䉎ᛛⴚ䉕㐿⊒䇮䉺䊮䊌䉪⾰䉇⚦⢩䈱ᯏ⢻⊒⃻ㆊ⒟䈱䉲䊚䊠䊧䊷䉲䊢䊮䈮䈧䈭䈕䇮⚦⢩䉴䉬䊷䊦䈫䈱᦭ᯏ⊛䈭ㅪ៤䉕࿑䉎䇯䉺䊷䉭䉾䊃䋺ᄙ೷ឃ಴䊃䊤䊮䉴䊘䊷䉺䇮⢽⢌㉄ઍ⻢㉂⚛෻ᔕ㐿⊒⸘↹䋺䌑䌍䇮䌍䌍䇮䌃䌇䈱ฦ䉴䉬䊷䊦䈪䊒䊨䉫䊤䊛䈱㐿⊒䉕ㅴ䉄䉎䈫䈫䉅䈮䇮䈠䉏䉌䈱ᚻᴺ䉕⚿ว䈚䈢QM/MM䇮MM/CGᴺ䈮䉋䈦䈩䊙䊦䉼䉴䉬䊷䊦䉲䊚䊠䊧䊷䉲䊢䊮䉕ታ⃻䈜䉎䈢䉄䈱䊒䊨䉫䊤䊛䉕㐿⊒䈜䉎䇯䊕䉺䉴䉬䊷䊦䊶䉲䊚䊠䊧䊷䉲䊢䊮

䉲䉴䊁䊛
ో⣖

䊤䉟䊐䉰䉟䉣䊮
䉴䈱ᣂ䈢䈭ᚻ
Ბ䈱ឭଏ

㊂ሶൻቇ⸘▚

ಽሶേജቇ⸘▚䂾䊓䊦䉴䉰䉟䉣
䊮䉴䈻䈱⽸₂䇮వ┵ක≮╬䈱
ᛛⴚၮ⋚䈱᭴
▽

ࠃࠅዊߐߊ
ࠃࠅ⍴ᤨ㑆
ࠃࠅ෩ኒ

⣖䊶␹⚻♽
ၮ␆ේℂ䋨ᣇ⒟ᑼ䋩wv
 ^( v  v 0 ) ` v
wt

  p 

1'v
Re䊝䊂䊦䈮䉋䉎᛽⽎ൻᄢⷙᮨ䊂䊷䉺

y=f(x)+g(x)exp(az)㨯㨯㨯

in

out

ᑪ⸳

3

☻ⷞൻࡕ࠺࡞⸘▚

ࠃࠅᄢ߈ߊ
ࠃࠅ㐳ᤨ㑆
ࠃࠅㄭૃ⊛

ㅴ᝞⁁ᴫ䋺QM/MM/CG䈱䋳㓏ጀ䈠䉏䈡䉏䈪⸘▚ᣇᴺ䉕䊒䊨䉫䊤䊛ൻ䈚䇮䊁䉴䊃䉕⛯䈔䈭䈏䉌㐿⊒䇮ၮᧄ⊛ᚻᴺ䈱䊒䊨䉫䊤䊛ൻ䈏⚳䉒䉍䇮128-512ਗ೉⒟ᐲ䉁䈪ᕈ
4⢻䈏಴䉎䉁䈪䈮䈭䈦䈩䈇䉎䇯⚦⢩䉴䉬䊷䊦⎇ⓥ㐿⊒ಽሶ䉲䊚䊠䊧䊷䉲䊢䊮䈱นⷞൻ䊛䊷䊎䊷㐿⊒⋡ᮡ䋺䊕䉺䊐䊨䉾䊒䉴⚖䈱⸘▚ജ䉕ᵴ䈎䈚䈩⚦⢩䉕䋱䋰䋰ਁ䈱䊗䉪䉶䊦䈮඙↹䇮䈠䈖䈮൮᜝⊛䈭ታ⸽䊂䊷䉺䉕⚵䉂ㄟ䉖䈣⢄⚦⢩䊶⢄ዊ⪲䈱䉲䊚䊠䊧䊷䉲䊢䊮䈱ታ⃻䉕⋡ᜰ䈜䇯⮎೷╬䈱૞↪䉇೽૞↪䈱੍᷹䉕ⴕ䈉䉲䊚䊠䊧䊷䉲䊢䊮䈱㐿⊒䈮䈧䈭䈕䉎䇯㐿⊒⸘↹䋺↢‛䈱ⓨ㑆⊛ᖱႎ䉕౉䉏ㄟ䉃䈖䈫䈏಴᧪䉎䊒䊤䉾䊃䊐䉤䊷䊛䈱㐿⊒䈫ᐔⴕ䈚䈩䇮䊒䊤䉾䊃䊐䉤䊷䊛䈮ታⵝ䈜䉎䈢䉄䈱䊂䊷䉺෼㓸䈫䊝䊂䊦䈱᭴▽䉕ㅴ䉄䉎䇯䉁䈢䇮䊒䊤䉾䊃䊐䉤䊷䊛䈫ฦ⒳䊂䊷䉺䊶䊝䊂䊦䈫䈱᦭ᯏ⊛ㅪ៤䉕࿑䉎䇯⚦⢩䉲䊚䊠䊧䊷䉲䊢䊮䊒䊤䉾䊃䊐䉤䊷䊛

䉯䊦䉳૕ ታ᷹䊂䊷䉺䊶ᒻᘒ䊝䊂䊦⚦⢩ᖱႎ䈱෼㓸⚦⢩䈮㑐䈜䉎ᖱႎ䈱ᢙ୯ൻ䊶䊂䊷䉺෼㓸䊶⛔৻ᒻᑼ䈮䉋䉎⸥ㅀ↢‛ቇ⊛ᖱႎ

⚦⢩ౝ䈱෻ᔕᖱႎ
ઍ⻢⚻〝⚦⢩䈱ᒻ⁁ᄌൻ

⚦
⢩
䷶
丞
两
丫
丶
䷶
並
丱

⚦⢩䉕䊗䉪䉶䊦䋨ⓨ㑆䉕ᩰሶ⁁䈮඙ಾ䈦䈢䋱䈧䈱඙↹䋩䈮ಽഀ䈚䇮↢‛ቇ⊛ᖱႎ䉕♽⛔⊛䈮⚵䉂ㄟ䉃䇯ㅴ᝞⁁ᴫ䋺⚦⢩䉕⚂3ਁ୘䈱䊗䉪䉶䊦䈮ಽഀ䇮ⶄᢙ䈱䉥䊦䉧䊈䊤䉕⴫⃻䈚䇮⒖ᵹ
᜛ᢔᣇ⒟ᑼ䈮䉋䉎‛⾰⒖േ䉕䉲䊚䊠䊧䊷䉲䊢䊮䈪䈐䉎⚦⢩䉲䊚䊠䊧䊷䉲䊢䊮䊒䊤䉾䊃䊐䉤䊷䊛䉕㐿⊒䇮E-CELL䋳䉕䊔䊷䉴䈮䈚䈢ઍ⻢෻ᔕ䈏䉥䊦䉧䊈䊤㑆䉅฽䉄䈩䉲
6䊚䊠䊧䊷䉲䊢䊮䈪䈐䉎䉋䈉䈮䈭䈦䈢⤳ེోり䉴䉬䊷䊦⎇ⓥ㐿⊒ⴊᩖᒻᚑ䈫ャㅍ䈱䉲䊚䊠䊧䊷䉲䊢䊮㐿⊒⋡ᮡ䋺䊕䉺䊐䊨䉾䊒䉴⚖䈱⸘▚㊂䉕↪䈇䈩䇮ᢙᤨ㑆䈪ታⴕน⢻䈭⤳ེోり䉲䊚䊠䊧䊷䉲䊢䊮䈱᭴▽䉕⋡ᜰ䈜䇯䈖䉏䈮䉋䉍䇮∛ᘒ੍᷹䉇ᴦ≮੍᷹╬䈱ක≮ᡰេ䉿䊷䊦䈱㐿⊒䈮䈧䈭䈕䉎䇯㐿⊒⸘↹䋺ⴊ▤✂䇮ฦ⒳⤳ེ䇮ోり䉕䋳ᰴర⊛䈮ౣ⃻䈚䈢⤳ེోり䊝䊂䊦䉕᭴▽䈚䇮∛ᘒ੍᷹䉇ᴦ≮੍᷹䉕ⴕ䈉⤳ེోり䊝䊂䊦䉕ᰴ਎ઍ䉴䊌䉮䊮䈮ታⵝ䇮ᓴ
Ⅳེ♽∔ᖚ䉕ᆎ䉄䈫䈜䉎⒳䇱䈱∛ᘒ䈱䉲䊚䊠䊧䊷䉲䊢䊮䈫䇮䉧䊮䈭䈬䈱ᴦ≮ᡰេ䉲䊚䊠䊧䊷䉲䊢䊮䋨᡼኿✢䊶㓸᧤⿥㖸ᵄ䈭䈬䋩䈮䈧䈭䈕䉎䇯ᴦ≮䊶⸻ᢿ䈱଀䋨⿥㖸ᵄ䉕↪䈇䈢ᖡᕈ⣲≌䈱ᴦ≮੍᷹䋩∔ᖚㇱ૏⤳ེోり䊝䊂䊦䈱᭴▽୘೎ᖚ⠪䈱䊝䊂䊦䉕૞ᚑ⿥㖸ᵄવ៝䉲䊚䊠䊧䊷䉲䊢䊮ㅴ᝞⁁ᴫ䋺1mmಽ⸃⢻䈱ోり䊗䉪䉶䊦䊝䊂䊦䉕㐿⊒䈜䉎䈫หᤨ䈮ᣂ䈚䈇᭴ㅧᵹ
૕ㅪᚑᚻᴺ䈫ᄙᇦ⾰ౝ䈱⿥㖸ᵄવ៝⸃ᨆᚻᴺ䉕㐿⊒䈚䈢䇯䈖䉏䉌䈮䉋䉍䇮ᄖ⑼ᚻ
7
ⴚ䉲䊚䊠䊧䊷䉲䊢䊮䉇෼᧤⿥㖸ᵄ䈮䉋䉎䉧䊮䈱ᴦ≮╬䈻䈧䈭䈕䉎ၮ⋚䉕᭴▽䈚䈢䇯䊂䊷䉺⸃ᨆⲢว⎇ⓥ㐿⊒෼᧤⿥㖸ᵄ䈮䉋䉎ᴦ≮䈱䉲䊚䊠䊧䊷䉲䊢䊮㆐ᚑ⋡ᮡ䋺䊕䉺䊐䊨䉾䊒䉴⚖䈱⸘▚䈮䉋䈦䈩䇮ഃ⮎䉺䊷䉭䉾䊃ត⚝䉇୘ੱᏅ䉕⠨ᘦ䈚䈢ක≮䈱䈢䉄䈱ၮ⋚ᖱႎᛛⴚ䈱᭴▽䉕⋡ᜰ䈜䇯䈖䉏䈮䉋䉍䇮䊍䊃ోㆮવሶ䉕ኻ⽎䈫䈚䈢ഃ⮎䉺䊷䉭䉾䊃ㆮવሶត⚝䈱ታ⃻䈮䈧䈭䈕䉎䇯㐿⊒⸘↹䋺ㆮવሶ䊈䉾䊃䊪䊷䉪ផቯ䊶䉺䊮䊌䉪⾰䊈䉾䊃䊪䊷䉪ផቯ䊶䉭䊉䊛ᄙဳ⸃ᨆᛛⴚ╬䈱⎇ⓥ䇮䈭䉌䈶䈮䊂䊷䉺หൻᛛⴚ䈱㐿⊒䉕ㅴ䉄䇮㐿⊒䈚䈢⸃ᨆᴺ䉇䊂䊷䉺หൻᛛⴚ䉕ᰴ਎ઍ䉴䊌䉮䊮䈮ታⵝ䈚䇮䊂䊷䉺⸃ᨆ䈫䉲䊚䊠䊧䊷䉲䊢䊮䉕Ⲣว䈚䈢ᛛⴚ䉕㐿⊒䈜䉎䇯
䉲䊚䊠䊧䊷䉲䊢䊮䊝䊂䊦䈱᭴▽㑐ㅪ䈜䉎䊂䊷䉺䉕䊝䊂䊦䈮หൻ䊝䊂䊦䊂䊷䉺หൻᛛⴚ

∛᳇䈱䉲䉴䊁䊛⊛ℂ⸃䈮䉋䉎ක≮㐿⊒䉟䊉䊔䊷䉲䊢䊮઒⺑䈱⥄േ↢ᚑ䊂䊷䉺䋨≸䈭䈬䈱∛᳇䈮㑐䉒䈦䈩䈇䉎䊝䊂䊦䋩੍᷹䈫䉣䊤䊷䈱⊒⷗ᣂ઒⺑䊂䊷䉺䉣䊤䊷䈱⊒⷗䋨㑐ㅪ䈢䉖䈴䈒⾰䈱ᤨ♽೉䊂䊷䉺䋩ㅴ᝞⁁ᴫ䋺ಽሶ䈱䊈䉾䊃䊪䊷䉪䉕࿾࿑䈫䈚䈩᛽಴䈜䉎䈢䉄䈱ᣇᑼ䈫䈚䈩䇮ᄢⷙᮨㆮવሶ䊈䉾䊃䊪䊷䉪ត⚝෸䈶䉺䊮䊌䉪⾰᭴ㅧ䈮ၮ䈨䈒⋧੕૞↪੍᷹䈱⎇ⓥ䉕ⴕ䈇䇮ᣂ䈢䈭ᛛⴚ㐿⊒䈱ᚑഞ䈫ᣂ䈢䈭ਗ೉䊒䊨䉫䊤䊛䈱㐿⊒䈮䉋䉍䇮䈖䉏䉌䈱䊒䊨䉫䊤䊛
10䈏䋱䋰䋲䋴䉕⿥䈋䉎core䈪Ⓙേ䈜䉎䉋䈉䈮䈭䈦䈢䇯⣖␹⚻♽⎇ⓥ㐿⊒↢๮૕ၮ⋚䉸䊐䊃䉡䉢䉝㐿⊒䊶㜞ᐲൻ㐿⊒⋡ᮡ䋺⣖ో૕䊧䊔䊦䈪䈱౉಴ജ㑐ଥ䉕ౣ⃻䈪䈐䉎䊝䊂䊦䈫䉲䊚䊠䊧䊷䉲䊢䊮䉸䊐䊃䉡䉢䉝䉕㐿⊒䇮ᰴ਎ઍ䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺䈱ᕈ⢻䉕ᒁ䈐಴䈚䈩䇮⣖䈱ᨵエ䈭
ⅣႺㆡᔕ⢻ജ䈪䈅䉎⣖䈱⊒㆐䈫ቇ⠌䈱ౣ⃻䉕⋡ᜰ䈜䇯㐿⊒⸘↹䋺␹⚻⚦⢩䈫ዪᚲ࿁〝䈱䉲䊚䊠䊧䊷䉺䇮䈍䉋䈶䇮⣖䈱䉲䊚䊠䊧䊷䉺䈫䈚䈩᣸⯻䈱൬䈇ᖱႎಣℂ࿁〝䊝䊂䊦䇮䈾੃㘃䈱✂⤑䊝䊂䊦䈫䉕㐿⊒䇮ᰴ਎ઍ䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺䈮ㆡ䈚䈢䊒䊨䉫䊤䊛䈫䈜䉎䈖䈫䈪䇮᣸⯻䈱༦ⷡ♽ᖱႎಣℂ䈪䈲ታᤨ㑆䈪䇮䈾੃㘃䈱ⷞⷡ♽ᖱႎಣℂ䈲䋶䋰୚䈱ᤨ㑆䈪⸘▚น⢻䈫䈜䉎䇯␹⚻䊙䊦䉼䊐䉞䉳䉪䉴䉲䊚䊠䊧䊷䉺ዪᚲ࿁〝䉲䊚䊠䊧䊷䉺㪥㪜㪪㪫㐿⊒⋡ᮡ䋺䊒䊨䉳䉢䉪䊃䈪㐿⊒䈘䉏䉎ฦ⒳䉸䊐䊃䉡䉢䉝䈱㜞ᕈ⢻ൻ䇮․䈮ᰴ਎ઍ䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺ะ䈔䈱ᦨㆡൻ䉕ⴕ䈇䇮ᰴ਎ઍ䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺䈱↢๮⑼ቇ
䈻䈱ᔕ↪䉕ଦㅴ䈜䉎䈫หᤨ䈮䉫䊤䊮䊄䉼䊞䊧䊮䉳䉕ታ⃻䈜䉎䇯㐿⊒⸘↹䋺䉮䉝䉸䊐䊃䉡䉢䉝䊶ၮ⋚䊤䉟䊑䊤䊥䈱㐿⊒䈫ઁ䉼䊷䊛䉝䊒䊥䉬䊷䉲䊢䊮䈱⺞ᩏ䊶㜞ㅦൻ䈮ะ䈔䈢ᬌ⸛䉕ㅴ䉄䇮ᰴ਎ઍ䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺ታᯏ䈪䈱䉝䊒䊥䉬䊷䉲䊢䊮䈱㜞ㅦൻ䇮䉼䊠䊷䊆䊮䉫䉕ⴕ䈉䇯ᕈ⢻ዪᚲ࿁〝䉲䊚䊠䊧䊷䉲䊢䊮䋨⚦⢩ᢙ 105, 䉲䊅䊒䉴ᢙ 109䋩⚦⢩ᭂᕈᒻᚑ䉲䊚䊠䊧䊷䉲䊢䊮ㅴ᝞⁁ᴫ䋺ᧄ䉼䊷䊛䈲2008ᐕ10᦬䈮⊒⿷䇮ᤓᐕᐲ䈲␹⚻䊙䊦䉼䊐䉞䉳䉾䉪䉴䉲䊚䊠䊧䊷䉺䈪䈲␹⚻⚦⢩䈱ᭂᕈᒻᚑ䈮䈧䈇䈩䇮ಽሶ䊧䊔䊦䈎䉌䈱䉲䊚䊠䊧䊷䉲䊢䊮䈏䈪䈐䈢䇯䉁䈢䇮ዪᚲ11࿁〝䉲䊚䊠䊧䊷䉺NEST䈪䈲10^5୘䈱␹⚻⚦⢩䇮10^9୘䈱䉲䊅䊒䉴䈎䉌䈭䉎ᄢⷙᮨዪᚲ࿁
〝䈱䉲䊚䊠䊧䊷䉲䊢䊮䈏䈪䈐䈢䇯ᧂਗ೉ൻ₸䉝䊛䉻䊷䊦䈱ᴺೣਗ೉ൻᐲ䈏਄䈏䉎䈮䈧䉏䇮䉒䈝䈎䈭ᧂਗ೉ൻ䈪䉅ᕈ⢻䈮ᄢ䈐䈭ᓇ㗀䉕෸䈿䈜ਗ೉ൻᐲㅴ᝞⁁ᴫ䋺ᧄ䉼䊷䊛䈲2007ᐕ11᦬䈮⊒⿷䇮䈖䉏䉁䈪䈮ಽሶേജቇ⸘▚䉸䊐䊃䉡䉢䉝䈱⸃ᨆ䊶㐿⊒䇮㊂ሶൻቇ⸘▚䉸䊐䊃䉡䉢䉝䈱㜞ᕈ⢻ൻ䈮䈧䈇䈩䈱⺞ᩏ䇮ၮ⋚䊤䉟12䊑䊤䊥䊶นⷞൻ䉸䊐䊃䉡䉢䉝䈱⺞ᩏ䊶㐿⊒䉕ㅴ䉄䈢䇯↢๮૕ၮ⋚䉸䊐䊃䉡䉢䉝㐿⊒䊶㜞ᐲൻ䉼䊷䊛䋨HPC䉼䊷䊛䋩䈱⹦⚦䇸↢๮૕ၮ⋚䉸䊐䊃䉡䉢䉝㐿⊒䊶㜞ᐲൻ䉼䊷䊛䇹ᓎഀ•ಽሶേജቇ䉇㊂ሶജቇ↪䉸䊐䊃䈱㜞ㅦ䉮䉝䊤䉟䊑䊤䊥䊷䈱㐿⊒•ਗ೉䊚䊄䊦䉡䉢䉝䊶⿥ᄢⷙᮨ䊂䊷䉺ಣℂนⷞൻ䉲䉴䊁䊛㐿⊒䋨㗔ၞဳ⸃ᴺ䇮☸ሶ䊔䊷䉴䈱⸃ᴺ↪䇯䊤䉟䊐䉰䉟䉣䊮䉴ಽ㊁䉕ਥ䈭ኻ⽎䈫䈚䈩䈇䉎䈏䇮᳢↪⊛䈮૶䈋䉎⸳⸘䋩•㜞ਗ೉ൻ䊶㜞ㅦൻኻᔕ䋨ฦ䉼䊷䊛䈲1,000ਗ೉䉁䈪⥄ഥദജ䋩

ಽ ሶ

䊂䊷䉺
⤳ེోり ⸃ᨆⲢว

⚦ ⢩

䈠䈱ઁ

㜞ᕈ⢻ൻᡰេ

ၮ⋚䉸䊐䊃㐿
⊒䊶㜞ᐲൻᡰ
េ౒ㅢၮ⋚䊤䉟䊑䊤䊥䊷䋫䉮䉝䉸䊐䊃䉡䉢䉝䊊䊷䊄䉡䉢䉝䈮ነ䉍ᷝ䈦䈢ᦨㆡൻ•SIMDᯏ᭴䈱ᦨᄢ೑↪䋺䉝䉶䊮䊑䊤䊶䉮䊷䊂䉞䊮䉫•䊙䊦䉼䉴䊧䉾䊄ਗ೉䈫MPIਗ೉䈱ਔᣇ䈱ᵴ↪
•MPI䉋䉍䉅ૐ䊧䊔䊦䈱ㅢା䊤䉟䊑䊤䊥䈱ᵴ↪
•䉥䊮䉨䊞䉾䉲䊠⸘▚䋨䉨䊞䉾䉲䊠䊑䊨䉾䉨䊮䉫䇮䊒䊥䊐䉢䉾䉼䋩•⸘▚䈫ㅢା䈱䉥䊷䊋䊷䊤䉾䊏䊮䉫•䊨䊷䊄䊋䊤䊮䉲䊮䉫䌇䌕䌉䋯䊪䊷䉪䊐䊨䊷╬⋥ᗵ⊛䈭ᠲ૞╬䉕ታ⃻䈚᏷ᐢ䈇䊡䊷䉱䊷䈱೑↪䉕น⢻䈮ታ⃻⽎ ᰴ਎ઍ䉴䊌䉮䊮↪䉲䊚䊠䊧䊷䉲䊢䊮䉸䊐䊃䉡䉢䉝⟲䈮ᔕ↪
䈚䈩䊐䉞䊷䊄 ⥄䉌ᡷ⦟໡↪䉸䊐䊃䉡䉢䉝䈻䈱ᡷ⦟䊋䉾䉪䊊䊷䊄䉡䉢䉝䈮ะ䈇䈢⸘▚䉝䊦䉯䊥䉵䊛•↢૕㜞ಽሶ䈱ේሶ㑆䈱㐳〒㔌ജ䉕᳞䉄䉎䊘䉝䉸䊮ᣇ⒟ᑼ
Æ FFT䈎䉌ታⓨ㑆䊙䊦䉼䉫䊥䉾䊄⸘▚•㉂⚛෻ᔕ䈱ᯏ⢻⸃ᨆ䊶⮎೷䈱ᱜ⏕䈭⚿ว⥄↱䉣䊈䊦䉩䊷੍᷹䋺㊂ሶൻቇ⸘▚䈪䈱
䉥䊷䉻䊷Nᚻᴺ

ฦᯏ㑐䋨ฦ
䉼䊷䊛䋩䈱
䉸䊐䊃㐿⊒

ታ⸽೑↪
ᡰេ
䉫䊤䊮䊄䉼䊞䊧
䊮䉳㆐ᚑ⋡ᮡ

䉸䊐䊃䉡䉢䉝
䊊䉡䉴

14ቇⴚ೑↪䊶↥ᬺ೑↪

13
13䈖䉏䉁䈪䈱⚻✲䈫੹ᓟ䈱੍ቯ䉼䊷䊛⋡ᮡ䈫౒ㅢ⋡ᮡ䋨䊝䊂䊦ൻ䉕⋡ᜰ䈜⃻⽎䋩䇸↢๮⃻⽎䈱⛔ว⊛⸃᣿䇹䈮ะ䈔䇮䉴䉬䊷䊦䉕⿥䈋䈢ㅪ៤䉕ⷞ㊁䈮౉䉏䈧䈧䉰䉟䉣䊮䉴䈫䈚䈩䉟䊮䊌䉪䊃䈱䈅䉎⎇ⓥ㐿⊒⺖㗴䉕ᬌ⸛
10䌾20ᐕᓟ
䋳ᐕᓟ⛔ว⊛⸃ᨆ䈮䉋䉎
ᖱႎಣℂ୘䇱䈱䉴䉬䊷䊦
↢๮⃻⽎䈱ℂ⸃䈱䈱ⷐ⚛ㆶర⊛䈭น႟ᕈ䊶ᒻᘒᄌൻ
ᷓൻ䊶䊓䊦䉴䉰䉟䉣⃻⽎⸃᣿䊮䉴䈻䈱⽸₂⚦⢩⚵❱䈱 ↢๮䉲䉴䊁䊛↢ൻቇⷐ⚛䉕ข䉍౉䉏䈢ⴊⴕേᘒ

⣖␹⚻♽
⤳ེోり
䉴䉬䊷䊦

ⶄᢙ⚦⢩
⚦⢩ౝ‛⾰
ャㅍ䊶ઍ⻢
ⴊᩖᒻᚑ

⚦⢩䉴䉬䊷䊦
⃻⁁

㓸ว૕䈫䈚
䈩䈱⤳ེ

ฦ⒳䊌䊤
䊜䊷䉺ផቯ

ಽሶ䉴䉬䊷䊦
䊂䊷䉺⸃ᨆⲢว

䈱ቯ㊂⊛⸘᷹
䊂䊷䉺䈱⫾Ⓧ

⺖㗴䈱᣿
⏕ൻ䈫ᢛ
ℂ

⛔ว䉲䊚䊠䊧䊷䉲䊢䊮䈱଀䃂ಽሶ䊧䊔䊦䈎䉌୘૕䊧䊔䊦䉁䈪䈱ઍ⻢෻ᔕ䈱੍᷹䃂ㆮવሶᄌ⇣䊶⚦⢩䈱䈏䉖ൻ䊶ォ⒖䉁䈪䉕฽䉃䈏䉖䈱⊒↢๮⃻⽎䉕⸥ ∝ᯏᐨ䈱⸃᣿ㅀ䈜䉎ᢙℂ䊝 䃂ฦ୘ੱ䈱䊂䊷䉺䈮ၮ䈨䈒୘ੱᏅ䉕⠨ᘦ䈚䈢ක≮ၮ⋚䈱䊂䊦䈱⊒ዷ᭴▽䃂⊒↢䊶Ⴧᱺ䈫䈇䈦䈢↢๮⃻⽎䈱ᩮᧄේℂ䈱⸃᣿䃂␹⚻ᄌᕈ∔ᖚ䈱⊒↢ᯏᐨ䈱⸃᣿ઍ⻢෻ᔕ䊶⤑Ⱞ
⊕⾰䈱േᘒ

䉝䊒䊥㐿
⊒ᡰេ䊶
㜞ᐲൻ
䉼䊷䊛ᣂ
⸳
㐿ᆎ

ᄖㇱክᩏ
ᣂⷙ⎇ⓥ
⺖㗴⺞ᩏ

䊈䉾䊃䊪䊷䉪ផቯ዁᧪䈱⛔ว䉕⷗ᝪ䈋䈢᜸ᚢ15⊛䈭㐿⊒⺖㗴

2006ᐕ

2007ᐕ

૕೙ᒝൻ
MEXT
⹏ଔ

ਗ೉ᕈ
⢻ᒝൻ

⣖␹⚻
♽䉼䊷
䊛⸳⟎

㐿⊒⁁
ᴫ䈱น
ⷞൻ䊶▤
ℂᒝൻ

2008ᐕ

2009ᐕ

㐿⊒䈚䈢䉲
䈠䉏䈡䉏 䊚䊠䊧䊷䉲䊢䈱ᕈ⢻⋡ 䊮䉕ᰴ਎ઍᮡ䉕᣿⏕ 䉴䊌䉮䊮䈪ൻ䇮㆐ᚑ䉕 䉼䊠䊷䊆䊮
࿑䉎
䉫
2010ᐕ

2011ᐕ

䉼䊠䊷䊆
䊮䉫ቢ
ੌ䇮ᧄᩰ
ᵴ↪

2012ᐕ

⎇ⓥ㐿⊒䈪䈱ੑ㕙ᕈ• ᰴ਎ઍ䉴䊌䉮䊮㐿⊒䈫䈚䈩䈱஥㕙– ᰴ਎ઍ䉴䊌䉮䊮䈪ೋ䉄䈩น⢻䈮䈭䉎㕟ᣂ⊛⸘▚– ᰴ਎ઍ䉴䊌䉮䊮䈱ᕈ⢻䉕䊐䊦䈮ᒁ䈐಴䈜䉸䊐䊃䉕೑↪⠪䈮ᐢ䈒ឭଏ• ↢๮⑼ቇ䈫䈚䈩䈱஥㕙– ↢๮⃻⽎䈱ℂ⸃䈻䈱⽸₂– ක≮䊶ක⮎䊶䊤䉟䊐䉬䉝䈻䈱⽸₂17䋲䋮䊤䉟䊐䉰䉟䉣䊮䉴ಽ㊁䈮䈍䈔䉎⸘▚⑼ቇ⎇ⓥ㐿⊒䈱਎⇇䈱⃻⁁18
18䋲䋩ᶏᄖ䈪䈱⎇ⓥ㐿⊒䈱੹ᓟ䈱ᣇะ䋱䋩਎⇇⊛䈭⎇ⓥ䈱ਛᔃ䈲•zਃᭂ䋺䉝䊜䊥䉦䈫᰷Ꮊ䋨䋫⽕Ꮊ䇮䊆䊠䊷䉳䊷䊤䊮䊄䋩䇮ᣣᧄ䉝䊜䊥䉦䋺DoE䇮NIH䇮DoD䇮᳃㑆ડᬺ䋨䊔䊮䉼䊞䊷䇮⵾⮎ડᬺ䋩䈏ਥ䇮
DoE䈏ၮ␆⑼ቇ䋨↢‛ቇ䋫⸘▚⑼ቇ䋩䇮NIH䈏ක≮䉕ᜂᒰ䈜䉎䈢䉄䇮੕䈇䈱දജ䈲Ꮧ⭯䇯⸘▚⑼ቇ䈫ක≮䉕䈧䈭䈓േ䈐䈏䈭䈇䇯਎⇇⊛䈮ข䉍⚵䉁䉏䈩䈇䉎䈱䈲– 䉺䊮䊌䉪䈱᭴ㅧ䉇ᄌൻ䈭䈬䈱⸃ᨆ– ᄢ㊂䈱ታ㛎䊂䊷䉺䈮ၮ䈨䈒ᄙᰴర࿃ሶ⸃ᨆ䈭䈬䊶 ⃻࿷䈱⎇ⓥ㐿⊒䈪䊖䉾䊃䈭⹤㗴䈲䊙䊦䉼䉴䉬䊷䊦
NIH䉅EU䈪䉅ੑ䈧એ਄䈱䉴䉬䊷䊦䉕䈧䈭䈓⎇ⓥ㐿⊒䈮䊐䉜䊮䊂䉞䊮䉫ᣣᧄ䈲䉫䊤䊮䊄䉼䊞䊧䊮䉳䈫䈚䈩ᣢ䈮䊙䊦䉼䉴䉬䊷䊦䈮᜸ᚢ䊶ᣇ⒟ᑼ䈮ᔘታ䈮䊝䊂䊦ൻ䈚䇮䉴䉬䊷䊦䉕⿥䈋䉎䊶⤘ᄢ䈭⸘▚㊂䈲ᰴ਎ઍ䉴䊌䉮䊮䈪⸃ᶖ᰷Ꮊ䋺EU䈏䉴䊘䊮䉰䊷䈫䈭䉍䇮ITᛛⴚ䉕ක≮䈮↢䈎䈜ข䉍⚵䉂䉕ផㅴ䇯
৻଀䋺VPH(Virtual Physiological Human)䇮୘೎ᖚ⠪䈱ᴦ≮䈏⋡ᮡ䇯ᄢቇ䊶ක≮ᯏ㑐䊶⵾⮎ડᬺ䊶ක≮ᯏེ䊜䊷䉦䊷䈏ෳട䇮䊙䉾䉼䊮䉫䊐䉜䊮䊄䇮5ᐕ䈪ᢙ⊖ం౞ⷙᮨ䇯⣖⑼ቇ䈪䈲䉴䉟䉴䈏BlueBrain䊒䊨䉳䉢䉪䊃䉕ផㅴ䇯਎⇇䉕䊥䊷䊄䇯

http://simbios.stanford.edu/᰷☨䈪䈲ක≮ᯏ㑐䈪૶䈉䈖䈫䉕೨ឭ䈮◲⇛ൻ䈚䈢䊝䊂䊦ൻ䇯䋨⣖⑼ቇ䈪䈲଀ᄖ⊛䈮䉴䊌䉮䊮䉕ᜰะ䋩ᚢ⇛ಽ㊁ൻ䈪䇮ᣣᧄ䈏਎⇇䈮⽸₂

19

20
http://ec.europa.eu/information_society/newsroom/cf/itemdetail.cfm?item_id=3956

19•ಽሶ䉴䉬䊷䊦
– 䉝䊜䊥䉦䈲⿥ਗ೉⸘▚䈪వⴕ– ☻ⷞൻ䊝䊂䊦䈮䉋䉎⸘▚䇮ో㔚ሶ䉕౉䉏䈢䉺䊮䊌䉪⾰䈱㊂ሶൻቇ⸘▚䈪䈲ᣣᧄ䈏䊥䊷䊄•⚦⢩䉴䉬䊷䊦
– 䉲䉴䊁䊛䊋䉟䉥䊨䉳䊷䋨E-cell╬䋩䈲ᣣᧄ⊒ᢙਁਗ೉ⷙᮨ䈱⸘▚⢻ജ䉕䉅䈦䈢䉸䊐䊃䉡䉢䉝㐿⊒䉕ផㅴ੹ᓟ䇮ᰴ਎ઍ䉴䊌䉮䊮䈮ะ䈔䈢ਗ೉ᕈ⢻ะ਄䉕ടㅦో㔚ሶ⸘▚䈪䈲਎⇇䉕
䊥䊷䊄䋨ProteinDF)– ⚦⢩⟲䈎䉌⤳ེ䈻䇮ಽሶ䈎䉌⚦⢩䈻䈱䉝䊒䊨䊷䉼䈲䈬䈖䉅䈖䉏䈎䉌•20䋳䋩࿖㓙Ყセ䋨⛯䈐䋩䋳䋩࿖㓙Ყセ•http://www.nibib.nih.gov/Research/ProgramAreas/MathModeling⤳ེ䊶ోり䉴䉬䊷䊦– ࿖㓙⊛䈭⎇ⓥ㐿⊒૕೙䈏᭴▽䈘䉏䈧䈧䈅䉎Јಽሶ䊶⚦⢩䊶⤳ེోり䈱ฦ䉴䉬䊷䊦䈫ታ㛎䊂䊷䉺⸃ᨆ䇮⣖␹⚻♽䉕⛔
ว䈚䈩⎇ⓥ㐿⊒䃨਎⇇⊛䈮䉅ో䈒䈭䈇⹜䉂หᤨ䈮ⴕ䈉䈖䈫䈮䉋䉍䇮ᚻᴺ䉇䉸䊐䊃䉕੕䈇䈮೑↪䈚䇮㐿⊒䉕ടㅦЈᰴ਎ઍ䉴䊌䉮䊮䈪਎⇇䉕䊥䊷䊄䈜䉎䉼䊷䊛㑆䈱ㅪ៤– ᣣᧄ䈲ᔃ⤳䊝䊂䊦䇮ஜᏱ⠪䈎䉌䈱⹦⚦ੱ૕䊝䊂䊦䈪䊥䊷䊄•䊋䉟䉥䉟䊮䊐䉤䊙䊁䉞䉪䉴– ୘ੱ䈱ᄙ᭽ᕈ䈫ක≮䉕䈧䈭䈇䈪䉉䈒䈫䈖䉐䈪䈲ᣣᧄ䈲ఝ૏– ᰴ਎ઍ⿥㜞ㅦ䉲䊷䉬䊮䉰䊷╬䈮䉋䉎Ꮒᄢ䊂䊷䉺䈮⋥㕙䇮਎⇇⊛䈭⺖㗴•☻ⷞൻ䊝䊂䊦䈮
䉋䉎ಽሶ䊝䊷䉺

⣖⑼ቇ
– 䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺䈮䉋䉎䉲䊚䊠䊧䊷䉲䊢䊮䈪䈲BlueBrain䈭䈬䈏వⴕ– 䈚䈎䈚䇮⸘▚⺰⊛␹⚻⑼ቇ䈪䈲ᣣᧄ䈏਎⇇䉕䊥䊷䊄䇮BlueBrain䈪䈲䈖䈱ⷰὐ䈏੹䈲ᛮ䈔䈩䈇䉎

21

ᔃ⤳

21

ో㔚ሶ⸘▚䈪
䈱ਗ೉ᕈ⢻䋨ProteinDF䋩
2500䉮䉝䉁䈪䈱ਗ೉䉕⏕⹺⣖䈱ዪᚲ࿁〝䉲䊚䊠䊧䊷䉲䊢䊮䈪
䈱ਗ೉ᕈ⢻
䋨BlueGeneL䈪1000ਗ೉䉁䈪䈱ㅦᐲะ਄䉕⏕⹺䋩2222⃻࿷䈱㐿⊒⁁ᴫ▤ℂ䋺㐿⊒䊐䉢䊷䉵䉕䋴䈧䈮ಽ㘃
Phase I䋺䊒䊨䊃䉺䉟䊒㐿⊒䈫ਗ೉ൻ䈱䊁䉴䊃䋨ᗐቯ2006ᐕ䌾2008ᐕ)Phase II䋺ᄢⷙᮨਗ೉ൻ(ᗐቯ2009ᐕ䌾2010ᐕ)
Phase III䋺⿥ᄢⷙᮨਗ೉䋫ታᯏ䉼䊠䊷䊆䊮䉫(ᗐቯ2011ᐕ)Phase IV䋺ᰴ਎ઍ䉴䊌䉮䊮਄䈪䈱ᧄᩰ⊛䈭ታⴕ䈫PR᥉෸(ᗐቯ2012ᐕ)ฦI-III䈱䊐䉢䊷䉵䈱ਛ䈮䇮䈘䉌䈮䋳䈧䈱䊙䉟䊦䉴䊃䊷䊮䉕⸳ቯ䇮䋱䋰Ბ㓏䈮䋳䋮䉸䊐䊃䉡䉢䉝㐿⊒⁁ᴫ㐿⊒䉸䊐䊃䉡䉢䉝䋺ో䋳䋴ᧄ23
233䊱᦬Ფ䈮䉝䉾䊒䊂䊷䊃䇮໧㗴䈏䈅䉏䈳ᯏേ⊛䈮ኻಣ

18ᧄ䋺䋱䋰䋲䋴ਗ೉એ਄䇮10ᧄ䋺䋸䋰䋰䋰ਗ೉એ਄นⷞൻ䉸䊐䊃䉅䋱䋰䋰GPGPUਗ೉

24

䈠䉏䈡䉏䈱ᚑᨐ䉝䊏䊷䊦ᤨᦼ㐿⊒䉸䊐䊃䈱ఝవ㗅૏䈫䊥䉸䊷䉴䈱᦭ലᵴ↪
⢛᥊䊶 Ⓙ௛ೋᦼ䋨ㇱಽⒿേ䌾ᧄᩰⒿേ䈱㑆䋩䈮䈲䊡䊷䉱䊷䈏૶䈋䉎䊙䉲䊮ᤨ㑆䈲ዋ䈭䈇䊶 㜞ᐲൻ䉼䊷䊛䈏หᤨ䈮ข䉍⚵䉄䉎䉸䊐䊃䉅㒢䉌䉏䉎

╙৻⿛⠪

╙ਃ⿛⠪

╙ੑ⿛⠪

␹⚻♽⛔ว䉲䊚䊠䊧䊷䉺ᄙ೷ឃ಴䊃䊤䊮䉴䊘䊷䉺MARBLE⚦⢩䈎䉌⤳ེ䈻
Platypus
ProteinDFಽሶ䈎䉌⚦⢩䈻
CafeMol
CafeMol(䊍䉴䊃䊮DNA䋩 RICS:⢄⚦⢩HIFU ZZ-DOSE㊀䉟䉥䊮☸ሶ
UTHeartSiGN SSM L1GNE
SPH3D
LiSDAS
ParaHaplo
MEGADOCKਛ㐳ᦼ⋡ᮡ
CMDN:ᄢ⣖⊹⾰ዪᚲ࿁〝䊝䊂䊦
NEST(␹⚻࿁〝✂䋩䉴䉬䊷䊦䉕⿧䈋䈢ቢᚑᓟ䇮1ᐕએౝ
ቢᚑᓟ䈜䈓䈮ᚑ⛔ว⊛ℂ⸃䈮ะ䈮ᚑᨐ䉕䉝䊏䊷䊦
ᨐ䉕䉝䊏䊷䊦
26䈔䈢ข䉍⚵䉂
cppmd䋨ಽሶേജቇ䋩䊶ో䉸䊐䊃䈱㐿⊒ㅴ᝞䉕䈉䉁䈒䉮䊮䊃䊨䊷䊦䇮䊐䉢䊷䉵䉕䈝䉌䈚䈩䇮䊥䉸䊷䉴䉕᦭ല೑↪䈪䈐䉎䉋䈉䈮࿑䉎䇯䊶㐿⊒ਛ䈱䉝䊒䊥䈮ఝవ㗅૏䉕䈧䈔䉎䇯
䊶Ⓙ௛ᓟ⍴ᦼ㑆䈮ᚑᨐ䉕⸘↹⊛䈎䈧ᵄ⁁⊛䈮಴䈚䈩䉉䈒
25ᄢⷙᮨਗ೉↪MD䉮䉝䊒䊨䉫䊤䊛:cppmd╙৻⿛⠪䈱ಽ㘃⸘▚ᯏ⑼ቇ⊛䉟䊮䊌䉪䊃䋨䉯䊷䊄䊮䊔䊦⾨⁓䈇䋩㐿⊒⽿છ⠪䋺ᵏ࿾ ⌀ᒄੱ䋨ℂൻቇ⎇ⓥᚲ䋩਎⇇ᦨㅦ䈱ಽሶേജቇ⸘▚䈪GordonBell⾨䉕⋡ᜰ䈜⸘▚⑼ቇ⊛䉟䊮䊌䉪䊃䋨䊤䉟䊐ಽ㊁ะ䈔䈱䉝䊏䊷䊦䋩ProteinDF
UTHeartcppmd䂾ಽሶേജቇ⸘▚䉸䊐䊃䉡䉢䉝䋺10ਁ䉮䉝એ਄䈱⿥ਗ೉ൻ䋨100ਁ-1000ਁේሶ♽䈪䋩
10Petaflops䈪䋱ంේሶ⚖䈱䉲䊚䊠䊧䊷䉲䊢䊮䉕ታ⃻䈚䇮ታലᕈ⢻䈪ᦨㅦ䉕⋡ᜰ䈜

CafeMol(䊍䉴䊃䊮DNA䋩

SPH3D

䂾↢૕ಽሶ䈱ㆇേ䈱㐳ᤨ㑆䉲䊚䊠䊧䊷䉲䊢䊮100ਁේሶ♽䈱䉰䊑䊚䊥⑽䉲䊚䊠䊧䊷䉲䊢䊮䉕⋡ᜰ䈜䋨ኻ⽎଀䋩 ⚦⢩⤑᭴ㅧ䇮ᩭ⤑ャㅍ䇮䉡䉞䊦䉴䈭䈬䇼ᓥ᧪䈱䋱䋰䋰୚એ਄䈱ᤨ㑆䉴䉬䊷䊦䇽

ParaHaplo

NEST䂾䈖䉏䉁䈪ਇน⢻䈣䈦䈢ᤨ㑆䉴䉬䊷䊦䈪䇮↢ℂ⊛䈮ᗧ๧䈱䈅䉎䉺䊮䊌䉪⾰䈱ᄢ䈐䈭᭴ㅧᄌൻ䉕ᝒ䈋䉎䈖䈫䈮䉋䉍↢๮䉲䉴䊁䊛䈱ේሶ䊧䊔䊦䈪䈱᭴ᚑේℂ䉕ℂ⸃䈜䉎䈫౒䈮ഃ⮎䈮ᔅⷐ䈭䊧䊔䊦䈱⸘▚♖ᐲ䉕ታ⃻䈜䉎

ਔಽ㊁䈪䈱ᚑ
ᨐ䉕䉝䊏䊷䊦
27

ኒᐲ᳢㑐ᢙᴺ䈮ၮ䈨䈒䉺䊮䊌䉪⾰ో㔚ሶᵄേ㑐ᢙ⸘▚䋨ProteinDF䋩㐿⊒⽿છ⠪䋺૒⮮ ᢥବ 䋨᧲੩ᄢቇ䋩਎⇇ᦨᄢ䈱䉺䊮䊌䉪⾰ో㔚ሶ⸘▚䉕⋡ᜰ䈜 䉺䊮䊌䉪⾰䈱㔚ሶ䊧䊔䊦䈪䈱෻ᔕ䉕ᱜ⏕䈮⸃᣿䈜䉎䈢䉄䈱⸘▚⑼ቇᛛⴚ 28ᄢⷙᮨಽሶേജቇ䉲䊚䊠䊧䊷䉲䊢䊮䊙䊦䉼䉴䉬䊷䊦䊶䊙䊦䉼䊐䉞䉳䉾䉪䉴ᔃ⤳䉲䊚䊠䊧䊷䉲䊢䊮:UTHeart㐿⊒⽿છ⠪䋺ਭ↰ ବ᣿ 䋨᧲੩ᄢቇ䋩਎⇇ᦨᄢⷙᮨ䈱ᔃ╭⚦⢩䊧䊔䊦䈎䉌䈱ᔃ⤳ో૕䉲䊚䊠䊧䊷䉲䊢䊮䉕⋡ᜰ䈜 ਎⇇䈪䉅೨଀䈱䈭䈇䊋䊷䉼䊞䊦ᔃ⤳䉕਎⇇ᦨᄢⷙᮨ䈪䉮䊮䊏䊠䊷䉺਄䈮ౣ⃻ 䉸䊐䊃䉡䉢䉝䈱․ᓽ
䂾ಽሶ䊧䊔䊦䈱㔚᳇ൻቇ䇮ജቇ⃻⽎䉕ౣ⃻䈚䈢䇮ᔃ╭⚦⢩䈱䊝䊂䊦䉕૶䈦䈩ᔃ⤳䉕⚵䉂਄䈕䇮ᔃ⤳䈱േ䈐䈫ⴊᶧ䈱ᜉേ䉕ౣ⃻䈜䉎䉲䊚䊠䊧䊷䉲䊢䊮䊶䉸䊐䊃䉸䊐䊃䉡䉢䉝䈱․ᓽ
䂾ኒᐲ᳢㑐ᢙᴺ䈮䉋䉎ో㔚ሶᵄേ㑐ᢙ⸘▚䉸䊐䊃䉺䊮䊌䉪⾰䈱ബ⿠⁁ᘒ䉕䋱ਁਗ೉⿥䈪⸘▚䂾Ꮒᄢ䈭䉺䊮䊌䉪⾰䈱ബ⿠⁁ᘒ䉇㔚ሶ⒖േ䈱⸘▚䈏น⢻䋨䋱ජᱷၮ䇮䋱䋰ਁ゠㆏䇮ബ⿠⁁ᘒ⸘▚䋩 Protein Data Bank䈱99䋦એ਄䈏⸘▚น⢻䈮䂾䊚䊈䊤䊦䉕฽䉃䉺䊮䊌䉪⾰䋨㉂⚛䉇䊓䊛䉺䊮䊌䉪⾰䋩䈱௛䈐䉕⸃᣿䈜䉎䈱䈮᦭ല 䉺䊮䊌䉪⾰䈱ᯏ⢻䉕㜞ㅦ䈪㐳ᤨ㑆䉲䊚䊠䊧䊷䉲䊢䊮䈜䉎䈢䉄䈱⸘▚ᛛⴚ 䉸䊐䊃䉡䉢䉝䈱․ᓽ

䂾ฦ⒳ᔃ⤳∛(ਇᢛ⣂䉇᜛ᒛဳᔃ╭∝䈭䈬䋩䈱ၮ䈮䈭䈦䈩䈇䉎࿃ሶ䉕⚦⢩ౝ䈪⿠䈐䉎ಽሶ䊧䊔䊦䈱᜼േ䈎䉌ᬌ⸛䈜䉎䈖䈫䈏น⢻䇯ක≮䊶ഃ⮎䈻䈱ᔕ↪䉕ᬌ⸛䇯䋨ᚑᨐ䈱଀䋩
䉟䊮䉴䊥䊮䈱ಝ㓸䈮઻䈉㔚ሶ䈱ౣಽᏓ
6㊂૕䈫න㊂૕䈱ో㔚ሶಽᏓ䈱Ꮕ䉕ឬ䈇䈢䉅䈱䂾㔚ሶ䈏ਥᓎ䈱㜞ㅦ෻ᔕ䈏⹦⚦䈮⸃᣿น⢻䈮䈭䉍䇮 10Peta䈪䈲Cytochrome P450䈭䈬↢૕ᮨ୮శ㔚ሶ⚛ሶ䇮ੱᎿశวᚑ䈭䈬䈻䈱ᔕ↪䈏ᦼᓙ䈏䉺䊷䉭䉾䊃
29䈘䉏䉎

30

ోり䊗䉪䉶䊦䉲䊚䊠䊧䊷䉲䊢䊮䋨䍬䍼䍖䍜䍷᭴ㅧᵹ૕ㅪᚑ⸃ᨆ䍪䍽䍹䍖䍼䍵䍯䋺SPH3D)

ᄢ⣖⊹⾰ዪᚲ␹⚻࿁〝䉲䊚䊠䊧䊷䉺䊷:NEST㐿⊒⽿છ⠪䋺Marcus Diesmann 䋨ℂൻቇ⎇ⓥᚲ䋩㐿⊒⽿છ⠪䋺㜞ᧁ ๟ 䋨ℂൻቇ⎇ⓥᚲ䋩਎⇇ᦨᄢⷙᮨ䈱ᄢ⣖⊹⾰␹⚻࿁〝䈱ᵴേ䉲䊚䊠䊧䊷䉲䊢䊮䉕⋡ᜰ䈜਎⇇ᦨᄢⷙᮨ䈱ⴊᩖ䈱ᒻᚑ䇮ャㅍ䇮᪪Ⴇ䈱หᤨ䉲䊚䊠䊧䊷䉲䊢䊮䉕⋡ᜰ䈜 ක≮ᔕ↪䈮ะ䈔䇮䉇䉒䉌䈎䈭ੱ૕䈱⸃ᨆ䊶੍᷹䈮ㆡ䈚䈢⸘▚⑼ቇᛛⴚ 䉸䊐䊃䉡䉢䉝䈱․ᓽ
䂾ᄢ䈐䈭ⴊ▤䈎䉌Ძ⚦ⴊ▤䉁䈪䈱⿒ⴊ⃿䇮ⴊዊ᧼䉕౉䉏䈢⸘▚䈏䈪䈐䉎᭴ㅧᵹ૕ㅪᚑ䉸䊐䊃䉡䉢䉝䂾ᄢ⣖⊹⾰䈱䋱䋰䋰䉮䊤䊛䈮⋧ᒰ䈜䉎䋱ජਁ␹⚻⚦⢩䇮␹⚻⚦⢩㑆䉕ធ⛯䈜䉎䉲䊅䊒䉴1ජం䈱ାภಣℂ䉕ౣ⃻䊶੍᷹䋨ᓥ᧪䈱਎⇇䊃䉾䊒䈱䋱䋰䋰୚䈱ⷙᮨ䋩

Whole body䂾ක≮䊂䊷䉺䋨䌃䌔䉴䉨䊞䊮,䌍䌒䌉╬䋩䈎䉌⋥ធ䉲䊚䊠䊧䊷䉲䊢䊮䉕ⴕ䈉䈖䈫䈏䈪䈐䇮୘ੱᲤ䈱⸻ᢿ䈮හᔕ䈚䈩䉲䊚䊠䊧䊷䉲䊢䊮䈏೑↪น⢻䈮

vesselblood
muscle䂾⿥㜞ਗ೉䊒䊨䉫䊤䊛䋨⃻ᤨὐ䈪32,000ਗ೉䋩ᰴ਎ઍ䉴䊌䉮䊮਄䈪䈲ᢙචਁਗ೉䉕㆐ᚑ䇮਎⇇ᦨㅦ䉕⋡ᜰ䈜䂾ⴊᩖᒻᚑ䊶㐽Ⴇ䈮䉋䉎ᔃ╭᪪Ⴇ䋬⣖᪪Ⴇ䈱੍᷹䈫⮎ല⹏ଔ

Stress-strain䂾േ⣂≜䊶േ⣂⎬ൻ∝╬䈱ᓴⅣེ♽∔ᖚ䈱੍᷹䈫ᴦ≮ᴺ䈱ᬌ⸛

Muscle force‫ٻ‬ᏯႝឋƷऴ‫إ‬ϼྸҥˮᲫǳȩȠᲢOOᲣƴᲫᲪɢ̾ƷᅕኺኬᏘ
32

velocity

Whole body voxel Multi physics
model
model

31

䍨䍪䍽䍹䍞䍐䍪䍽㑐ㅪ⸃ᨆ䈮ᣈ䈔䉎⛔⸘ᬌቯ䉸䊐䊃䉡䉢䉝
䋨ParaHaplo)☻ⷞൻ䊝䊂䊦⸘▚䋨CafeMol)㐿⊒⽿છ⠪䋺㜞↰ ᓆੑ 䋨੩ㇺᄢቇ䋩㐿⊒⽿છ⠪䋺㎨⼱ ⋥ਯ䋨ℂൻቇ⎇ⓥᚲ䋩⤘ᄢ䈭㐳䈘䈱DNA䈏ᩭ䈱ਛ䈮෼⚊䈘䉏䇮ᔅⷐ䈭䈫䈐䈮⺒䉂಴䈞䉎⻘䈮᜸䉃

47∔ᖚ䈱ේ࿃ㆮવሶ䉕৻᜼䈮⊒⷗䈜䉎䈖䈫䉕⋡ᜰ䈜 ⚦⢩ᩭౝ䈪䈱DNA䈱䊍䉴䊃䊮䈻䈱Ꮞ䈐ઃ䈐䈫䇮䈾䈬䈒䊜䉦䊆䉵䊛䈱⸃᣿ 䉸䊐䊃䉡䉢䉝䈱․ᓽ
䂾ⷙᮨ䊶ᤨ㑆⊛䈮Ꮒᄢ䈭↢૕ಽሶ䈱⃻⽎䉕䉲䊚䊠䊧䊷䉲䊢䊮䈜䉎䈢䉄䈱☻ⷞൻ䊝䊂䊦⸘▚⚦⢩ ୘ੱ䈱ㆮવᖱႎ䈫∔∛䇮⮎‛෻ᔕᕈ䈱㑐ㅪ䉕᣿䉌䈎䈮 䉸䊐䊃䉡䉢䉝䈱․ᓽ
䂾ⶄᢙ䈱ㆮવሶ䉇ⅣႺⷐ࿃䋨り㐳䇮૕㊀䇮༛ᾍ䇮㘶㈬䈭䈬䋩䈱⚵䉂ว䉒䈞䈮䉋䈦䈩᳿䉁䉎∔∛䉇⮎‛䈱ല䈐ᣇ䇮೽૞↪䈭䈬䈱㑐ㅪ䉕✂⟜⊛䈮⸃ᨆᨴ⦡૕䂾਎⇇ᦨᄢ䋱ජਁේሶⷙᮨ䊶਎⇇ᦨ㐳䈱䊚䊥⑽䈱⃻⽎䉕ౣ⃻䊶੍᷹䉕⋡ᜰ䈜

䂾ో䉭䊉䊛䋨䋳䋰ంႮၮ䋩䈱୘ੱ䈗䈫䈱ㆮવᖱႎ䈱㆑䈇䈱ਛ䈎䉌䇮∔∛䈮㑐ㅪ䈜䉎ㆮવᖱႎ䉕䇮✂⟜⊛䈮♖ᐲ䉋䈒ត䈚಴䈜䈖䈫䈏น⢻䈮䂾ቇⴚ⊛䈭䉟䊮䊌䉪䊃䉕ਈ䈋䉎䇮ㆮવᖱႎ䈏ォ౮䈘䉏䉎㓙䈱DNA䈫
䊍䉴䊃䊮䈱䉻䉟䊅䊚䉾䉪䉴䉕ౣ⃻⚦⢩ਛ䈪⤘ᄢ䈭㐳䈘䈱DNA䈲䊍䉴䊃䊮䈮Ꮞ䈐ઃ䈐䇮䉮䊮䊌䉪䊃䈮ᩭ䈮෼⚊䈘䉏䈩䈇䉎䋨䉪䊨䊙䉼䊮᭴ㅧ䋩䂾䊋䉟䉥䊋䊮䉪䉳䊞䊌䊮䈮⊓㍳䈘䉏䈩䈇䉎⚂20ਁੱ䇮47∔ᖚ䉕ኻ⽎䈮⸃ᨆ

䉪䊨䊙䉼䊮
47∔ᖚ

䊍䉴䊃䊮
ㆮવሶ䈏⊒⃻䈜䉎㓙䈮䈲䇮ㆡಾ䈭႐ᚲ䈱DNA䉕䊍䉴䊃䊮䈎䉌䈾䈬䈐䇮ㆮવᖱႎ䉕ォ౮䈚䈩䈇䉎䇯
iPS⚦⢩䈱ᯏ⢻䈲䇮䉪䊨䊙䉼䊮᭴ㅧ䈮䉋䉎ォ౮೙ᓮᯏ᭴䉕ೋᦼൻ䈜䉎䈖䈫䈮䉋䈦䈩㆐ᚑ䈘䉏䉎䈫䈇䉒䉏䈩䈇䉎䇯䈠䈱䈭䈡䈮䉅᜸ᚢ䈪䈐䉎

DNA

33

SNPㆮવሶဳ䈫∔ᖚ䈫䈱㑐ㅪ䉕␜䈜䉝䊷䊚䊁䊷䉳ᬌቯ䈱P୯
䈱-log P୯䂾ోりⴊ▤✂䉲䊚䊠䊧䊷䉺䈫䈱ㅪᚑ䈮䉋䉎ⴊ࿶ᵄᒻ䋨ⴊ࿶᷹ቯ䋩䈎䉌䈱ᓴⅣེ♽∔ᖚ䈱੍᷹ න⚐䈭␹⚻⚦⢩䊝䊂䊦䈎䉌ታ㓙䈱⣖䈱ᵴേ䈏⺑᣿䈪䈐䉎䈎䉕⸃᣿ 䉸䊐䊃䉡䉢䉝䈱․ᓽ

ో䉭䊉䊛㑐ㅪ⸃ᨆ䈮䉋䉎∔ᖚ㑐ㅪSNP䈱ᬌ⚝34
ᨴ⦡૕1⇟䈎䉌22⇟䉁䈪䈮ਗ䈼䈢䇮⚂30ਁ୘䈱SNP

䉝䊒䊥䈱䊥䉴䊃䋨䋱䋩

4䋮ฦ䉸䊐䊃䉡䉢䉝䈱᭎ⷐ

35
35

ᄙ೷ឃ಴䍢䍵䍻䍛䍬䍽䍎䍞䍎䈮䈍䈔䉎⮎೷ឃ಴䉲䊚䊠䊧䊷䉲䊢䊮䋨MARBLE䋯Platypus䋯CafeMol 䋩䉝䊒䊥䈱䊥䉴䊃䋨䋲䋩⎇ⓥઍ⴫⠪䋺ᧁኹ ⹎♿䋨ℂൻቇ⎇ⓥᚲ䋩᛫↢‛⾰䈏ല䈎䈭䈒䈭䉎䊜䉦䊆䉵䊛䈱ℂ⺰⊛⸃᣿䉕⋡ᜰ䈜䉸䊐䊃䉡䉢䉝䈱․ᓽ
䂾㔚ሶ䉴䉬䊷䊦䌾ේሶ䊶ಽሶ䉴䉬䊷䊦䌾䉺䊮䊌䉪⾰ో૕䉴䉬䊷䊦䈱ᄙ㓏ጀ䋨㊂ሶൻቇ䊶ಽሶേജቇ䊶☻ⷞൻ䊝䊂䊦䋩䈱ㅪᚑ⸘▚䈮䉋䈦䈩Ꮒᄢ䉺䊮䊌䉪⾰䈱േ૞ᯏᐨ䉕᣿䉌䈎䈮䈜䉎䇯䂾⸘▚ኻ⽎䋺⚦⢩⤑䈮䈅䉎ᄙ೷ឃ಴䊃䊤䊮䉴䊘䊷䉺䊷䋳䈧䈱䉺䊮䊌䉪⾰䈏⚿ว䈚䈢Ꮒᄢ䉺䊮䊌䉪⾰䇯ฦ䇱䇮ข䉍ㄟ䉂ဳ  ⚿วဳ  ឃ಴ဳ䈫㗅➅䉍䈮᭴ㅧ䉕ᄌ䈋䈭䈏䉌䇮⮎೷ൻว‛䉕ឃ಴䈜䉎䈫⠨䈋䉌䉏䈩䈇䉎䇯䈠䈱䊜䉦䊆䉵䊛䉕ត䉎䂾⚦⩶䉇䈏䉖⚦⢩䈱⮎೷⠴ᕈൻ䈱ਥⷐ䈭ේ࿃䈱䋱䈧䈪䈅䉎䊜䉦䊆䉵䊛䈱⸃᣿䈮䈧䈭䈏䉍䇮⮎೷⠴ᕈൻ䈚䈮䈒䈇᛫↢‛⾰䉇䇮ឃ಴䉕ᅹ䈕䉎ᣂ⮎䈱⸳⸘╬䈻䈱ᵄ෸䈏ᦼᓙ䈪䈐䉎䇯ૐଚⷅᴦ≮䉲䊚䊠䊧䊷䉲䊢䊮:HIFU䋨䊗䉪䉶䊦⿥㖸ᵄવ᠞䊒䊨䉫䊤䊛䋩38⚦⢩䉲䊚䊠䊧䊷䉺䋺RICS

㐿⊒⽿છ⠪䋺᧻ᧄ ᵗ৻㇢ 䋨᧲੩ᄢቇ䋩෻ᔕ䊷᜛ᢔ䊷⤑ㅘㆊ䈱ㅪᚑ⸘▚䉕䋱䋰䋰ਁ㪭㫆㫏㪺㪼㫃ⓨ㑆䈪ታ⃻䋣
(100䋳)

ዊⷙᮨ䊝䊂䊦䈱⸘▚ᤨ㑆䋨⿒ⴊ⃿䋩⿥㖸ᵄᴦ≮ᯏེ䈱⸳⸘㐿⊒䊶቟ోᕈ䈱⏕⹺䈮⽸₂

䋲㬍 䋲㬍䋲䋨䋽䋸䋩䊗䉪䉶䊦䉕ㅙᰴ䋨䋱CPU䋩䈪⸘▚
1000step䌳/197⑽ 䌴=1ms 䋨ታᤨ㑆1⑽䋩

 ᖚㇱ䈣䈔䉕὾䈒㓸᧤⿥㖸ᵄᴦ≮䈱቟ో䈭ㆡ↪䈮ะ䈔䈢⸘▚⑼ቇᛛⴚ ⿒ⴊ⃿ᒻ⁁䊝䊂䊦䋲㬍 䋲㬍䋲䊗䉪䉶䊦䌯䌸䌹䌈䌢䉕⴫␜䋶䋴㬍 䋶䋴㬍䋲䋵䋨䋽102400䋩䊗䉪䉶䊦䉕ㅙᰴ䋨䋱CPU䋩䈪⸘▚
512ਗ೉䋺1.36h 䌴= 0.05ms
ታᤨ㑆1ಽ䋺600h 䋱䋰ਁਗ೉䋺䋳hr䉸䊐䊃䉡䉢䉝䈱․ᓽ
䂾ੱ૕ౝ䋨㛽䉇⤳ེ䈭䈬㖸㗀․ᕈ䈱⇣䈭䉎ᄙᇦ⾰૕ౝ䋩䈱⿥㖸ᵄવ៝䉕䉲䊚䊠䊧䊷䉲䊢䊮䈜䉎䉸䊐䊃䉡䉢䉝⢄⚦⢩⹦⚦䊝䊂䊦

䂾ක≮↹௝䊂䊷䉺䈎䉌㐿⊒䈘䉏䈢䊗䉪䉶䊦ੱ૕䊝䊂䊦䉕૶䈦䈩䉲䊚䊠䊧䊷䉲䊢䊮䇯HIFU䋨ᒝജ㓸᧤⿥㖸ᵄ䋩䉕૶䈦䈢ᴦ≮ᯏེ䈱⿥㖸ᵄ䈱㓸᧤⁁ᴫ䈱㜞♖ᐲ䈭೙ᓮ䉕䉲䊚䊠䊧䊷䉲䊢䊮น⢻䂾⃻࿷䈱⿥㖸ᵄᴦ≮䈪䈲ኻᔕ࿎㔍䈭⢄⤳䈭䈬䈱૕ౝᷓㇱ䈮䈅䉎⤳ེ䉇⣖䈭䈬㛽䈪࿐䉁䉏䈢ㇱ૏䈮ኻ䈚䈩䋬㓸᧤⿥㖸ᵄ䈪⣲≌䉕὾ἳ䈜䉎ක≮ᯏེ䈱㐿⊒䈮೑↪䇯䉲䊚䊠䊧䊷䉲䊢䊮⚿ᨐ䉕䉅䈫䈮⿥㖸ᵄ䈱ᾖ኿ᣇᴺ䉕ᬌ⸛䈚䋬ᚻⴚ⸘↹䉕┙᩺น⢻ᄙ೷ឃ಴䍢䍵䍻䍛䍬䍽䍎䍞䍎㪘㪺㫉㪙䋱䋰䋰㬍䋱䋰䋰㬍䋱䋰䋰䋨⊖ਁ䋩䊗䉪䉶䊦䉕䋱䋰ਁਗ೉䋩䈪⸘▚䋶䋴㬍 䋶䋴㬍䋲䋵䊗䉪䉶䊦䊐䊦ઍ⻢䊝䊂䊦䉕ᗐቯ 䌴= 0.05ms
ታᤨ㑆1ಽ 䋺䋱䋰ਁਗ೉䋺䋳䋰h䌲⢄ዊ⪲䊝䊂䊦䋨ઍ⻢㛽ᩰ䊝䊂䊦䋩䋵䋰㬍䋵䋰㬍䋵䋰䋰䋨⊖ਁ䋩䊗䉪䉶䊦䉕䋱䋰ਁਗ೉䋩䈪⸘▚䊐䊦ઍ⻢䊝䊂䊦䉕ᗐቯ 䌴= 0.䋵msታᤨ㑆1䋰ಽ 䋺䋱䋰ਁਗ೉䋺䋴䋰h䌲㗡⬄㛽⿧䈚䈱HIFUᾖ኿
39
䉲䊚䊠䊧䊷䉲䊢䊮

40䉸䊐䊃䉡䉢䉝䈱㜞ᕈ⢻ൻ• MD䉮䉝
ᄢⷙᮨਗ೉ൻ䈘䉏䈢ಽሶേജቇ⸘▚䉮䉝• MO䉮䉝
Platypus QM/MM䈱䈢䉄䈱MO䈱ਗ೉ൻ• ╙৻⿛⠪䉝䊒䊥䉬䊷䉲䊢䊮䈱㜞ᕈ⢻ൻ

5䋮䉸䊐䊃䉡䉢䉝䈱㜞ᕈ⢻ൻ– ઁ䉼䊷䊛䈱䉝䊒䊥䉬䊷䉲䊢䊮䉕฽䉄䈢䉼䊠䊷䊆䊮䉫– ᕈ⢻⹏ଔ䉕ቢੌ䇮⚿ᨐ䉕䊐䉞䊷䊄䊋䉾䉪– ੹ᓟ౒ห䈪㜞ᕈ⢻ൻ䉕ㅴ䉄䉎• 㜞ᐲൻ䉼䊷䊛䈫䈚䈩䈱ᧄ⇟䈱ᵴേ䈲ᰴ਎ઍ䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺䈏Ⓙ௛䉕ᆎ䉄䉎੹ᐕᐲએ㒠– ૐ䊧䊔䊦ㅢାAPI– SIMD๮઎䈱⋥ធ⊛೑↪

• Ḱ஻⁁ᴫ䈫䈚䈩䈲䇮䈾䈿੍ቯㅢ䉍
41

42
41

z

ᄢⷙᮨਗ೉䈮ะ䈔䈩䇮᭽䇱䈭ਗ೉ൻ
ᚻᴺ䉕⋓䉍ㄟ䉖䈣ၮ⋚䉸䊐䊃䉡䉢䉝ᄢⷙᮨਗ೉ൻ䈱䇸䊃䊧䊷䊆䊮䉫䇹㐿⊒ᤨὐ䈎䉌ᰴ਎ઍ䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺䉕ᒝ䈒ᗧ⼂
ᄙᯏ⢻

z

㜞ㅦ

z

z

• MD䈱႐ว䋺z

Desmond (D. E. Shaw Research), NAMD(UIUC),
Blue Matter (IBM) 䈭䈬䈏ᢙජਗ೉એ਄䈱ਗ೉䉕ታ⃻䇯z૗䉏䈱䉮䊷䊄䉅䇮㜞ᕈ⢻⸘▚䈱ኾ㐷ኅ䈏ਛᔃ䈮ෳട䈚䈩㐿⊒䉕ㅴ䉄䈩䈇䉎䇯• 䊤䉟䊐䉝䊒䊥䉬䊷䉲䊢䊮䈪䈱104એ਄䈱ਗ೉ᐲ䈮䈧䈇䈩䈲䇮਎⇇⊛䈮⷗䈩䉅䈖䉏䉁䈪䈱⫾Ⓧ䈲㕖Ᏹ䈮ዋ䈭䈇䇯

z

z
z

43
z

㪤㪛䉮䉝䋨㪉䋩ᰴ਎ઍ䉴㺍䊌䊷䉮䊮䊏䊠䊷䉺䈱䊈䉾䊃䊪䊷䉪䊃䊘䊨䉳䉕⠨ᘦ䈚䈢ㅢା䊌䉺䊷䊮䈱ᡷ⦟㫏㪃㫐㪃㫑ゲ䈮ㅙᰴㅢାㅢା⋧ᚻ䈏ዋ䈭䈇z ᰴ਎ઍ䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺䈱䊈䉾䊃䊪䊷䉪䊃䊘䊨䉳䋨䊃䊷䊤䉴᭴ㅧ䋩䈮৻⥌45
䋸䋰䋰䋰䉮䉝䈪䈱ᕈ⢻ะ਄䉕ታ⃻

z

z

z

z

ౣ೑↪ᕈ䊶ᚻᴺᲧセੑ૕⋧੕૞↪䉦䉾䊃䉥䊐⸘▚䈱㜞ㅦൻ䉕ఝవ
㜞ਗ೉ᤨ䈱ㅢା䉕⠨ᘦ᳓ 㪐㪎㪍㪊㪎㪈ේሶ 䋨㪈㪈㪇ේሶ㪆䉮䉝䋩㪩㪠㪚㪚㩷㪏㪇㪇㪇ਗ೉䈪䈱ਗ೉ൻ⏕⹺䈠䈱ઁ䈱ᯏ⢻䈲ᄙᯏ⢻ 䈎䉌⒖ᬀਛ㪧㫃㪸㫋㫐㫇㫌㫊㩷㪨㪤㪆㪤㪤䈱䈢䉄䈱ਗ೉ಽሶ゠㆏ᴺ䉮䉝䉸䊐䊃䉡䉢䉝z㪟㪝㪆㪩㪟㪝㪆㪚㪘㪪㪪㪚㪝㪆㪚㪘㪪㪚㪠z䊔䉪䊃䊦ൻ䋨ᒰೋ䋩䇮㪪㪠㪤㪛ൻ䈮䈧䈇䈩䉅⺞ᩏzzੑ૕⋧੕૞↪䈱䉦䉾䊃䉥䊐⸘▚㪙㪆㪝䈱㆑䈇䉅⠨ᘦ䈜䉎䈫㪐㪇ේሶ㪆䊉䊷䊄⒟ᐲ䉁䈪䉴䉬䊷䊦䋨㪈㪈ේሶ㪆䉮䉝䋩z ᰴ਎ઍ䉴䊌䉮䊮ో૕䋨㪏㪇㪃㪇㪇㪇䊉䊷䊄䋩䈪㪎㪃㪉㪇㪇㪃㪇㪇㪇ේሶ㪐㩷z 㪉㫏㪈㪇 㫊㫋㪼㫇㩷㪆㩷㪻㪸㫐㩷䋨ല₸㪈㪇㩼㪔㩷㪈㪧㪽㫃㫆㫇㫊䋩z 㪉㪽㫊㪆㫊㫋㪼㫇䈪㪋㱘㫊㪼㪺㪆㪻㪸㫐z ੹ᓟ䈱⺖㗴
ઁ䈱⸘▚䈱⽶⩄䈱⷗䈧䉅䉍න૕ᕈ⢻䉼䊠䊷䊆䊮䉫z㪠㫅㫋㪼㪾㪼㫉㩷㪺㪸㪺㪿㪼㩷㫄㫀㫊㫊䈱ᡷༀ䋨㪝㪯㪈䈪䈱ታⴕ⚿ᨐ䈎䉌䋩㪦㫇㪼㫅㪤㪧䊶㪪㪠㪤㪛䈱ᵴ↪
9 ๮઎ታⴕኒᐲ㩿㪚㪧㪠㪀䈱ะ਄
99

RDFT Strong scaling
SP+HIS, 6-31G,
AOᢙ䋺2488, 䉲䉢䊦ᢙ:1188
䋨㒋ᄢਛ᧛⎇䈮䉋䉎⸘᷹䋩㪚㪘㪪㪪㪚㪝䈱㪤㪦ᄌ឵䈱ᕈ⢻ะ਄䈭䈬䈮․ᓽ
੹ᓟ䇮䈘䉌䈮ਗ೉ൻ₸䈱ะ਄䈮දജ䇯• Weak/Strong scaling౒䈮⦟ᅢ
CASSCF Strong scaling
DNA, STO-3G, AOᢙ䋺798,
MOᢙ:798, 䉲䉢䊦ᢙ:508

ౖဳ⊛䈭໧㗴䈮ኻ䈚䇮㪉㪇㪃㪇㪇㪇䉮䉝એ਄䉁䈪䈱䉴䉬䊷䊥䊮䉫ታ⃻䈏⋡ᮡz䈠䈱ઁ䇮㪦㩿㪥㪀ಽሶ゠㆏ᴺ㩿㪥㪫㪚㪿㪼㫄㪃㩷᦭㒢ⷐ⚛
ၮᐩ㪀䈱㜞ㅦൻ䈮䈧䈇䈩䉅৻ㇱᡰេ⤳ེోり䉴䉬䊷䊦䉼䊷䊛䈪㐿⊒ਛ䈱䉮䊷䊄• 䋱䊜䉾䉲䊠ᒰ䉍䈱Ṷ▚ᢙ– A=7144+827+18Ni– Ni䈲SOR䈱iteration࿁ᢙ㪛㪝㪫㪆㪚㪘㪪㪛㪝㪫䈮䈧䈇䈩䈲㒋ᄢਛ᧛⎇䈪㐿⊒z46᭴ㅧᵹ૕ㅪᚑ䊒䊨䉫䊤䊛SPH3D䋨䋱䋩
ᕈ⢻⹏ଔၮᧄㇱಽ䈱㐿⊒䉕ቢੌ䈚䇮㒋ᄢਛ᧛⎇䈮ᒁ䈐
ᷰ䈚

z

44䉮䉝ᢙ

Weak scaling 110atoms/core㪤㪛䉮䉝䋨㪊䋩ᰴ਎ઍ䉴䊌䉮䊮䈪䈱ዷᦸ㪤㪦䉮䉝㐿⊒䈱䈰䉌䈇䈫⁁ᴫz䉮䉝ᢙStrong scaling
976,371 atoms, smallball, XYZㅢା

47
໧㗴ⷙᮨ䉕ᄢ䈐䈒䈜䉏䈳䈘䉌䈮ᡷༀ䈜䉎⷗ㄟ䉂solphi827flopsolu

7144flop 1.5GFLOPS@RICC(
13% of peak)

Solp_
sor4

18flop/it
erationWeak Scaling (1003 grids/core)䉮䉝ᢙStrong Scaling (9603 grids/core)

2.8GFLOPS@RICC(
24% of peak)ᤨ㑆䋨sec䋩ోᣇะ⋥ធㅢା⋧ᚻ䈏ᄙ䈇z ┹ว䈏ỗ䈚䈒䈭䉎z ᰴ਎ઍ䉴䊷䊌䊷䉮䊮䊏䊠䊷
䉺䈱․ᓽ䉕↢䈎䈞䈭䈇

੹࿁䈱ታⵝ

⸘▚

ᤨ㑆䋨sec䋩

ㅢᏱ䈱ታⵝ

ว⸘
ㅢା

ᕈ⢻䋨Atom/s䋩• ਗ೉ൻ䈱⁁ᴫ䈮㑐䈚䈩䈲䇮䉝䊒䊥䉬䊷䉲䊢䊮䈮䉋䈦䈩䉁䈤䉁䈤䇯ᤨ㑆䋨s/step䋩㪤㪛䉮䉝㪑㪺㫇㫇㫄㪻䋨䋱䋩㐿⊒䈱䈰䉌䈇䈫⁁ᴫ਎⇇䈱⁁ᴫ

0.71GFLOPS@RICC(6% of peak)48
䉮䉝ᢙ᭴ㅧᵹ૕ㅪᚑ䊒䊨䉫䊤䊛SPH3D䋨䋲䋩
ᰴ਎ઍ䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺䈮ะ䈔䈢ዷᦸᰴ਎ઍ䉴䊌䉮䊮(10Pflops䊙䉲䊮)਄䈪䈱䊕䉺䉴䉬䊷䊦Ṷ▚䊝䊂䊦䃂䃂– ⃻⁁䉮䊷䊄䈪䈲15003䊗䉪䉶䊦䈏㒢⇇䃂– 䈖䈱䈫䈐SOR䈱෻ᓳᢙ䈲48000࿁

– 1Coreᒰ䉍䈱䊗䉪䉶䊦ᢙ䈏173䋺ㅢା䊗䊃䊦䊈䉾䉪
– Poisson solver䈱ᡷ⦟䈏ᔅ㗇•䃂Ṷ▚ᢙ䋨PFLOP䋩• ਗ೉FFT䊔䊷䉴䉸䊦䊋䈱1000୚
ㆃ䈇

оNx5.2

оNx4

䃂⺖㗴– Multigrid Poisson Solver䈱ዉ౉䋨MD䉮䉝╬䈪㐿⊒䋩– Hybrid ਗ೉ൻ䉫䊥䉾䊄ᢙ䋨1ᰴరᣇะ䋩ၮᧄ⊛䈮䈲䇮㪜㫄㪹㪸㫉㫉㪸㫊㫊㫀㫅㪾㫃㫐㩷㪧㪸㫉㪸㫃㫃㪼㫃㪩㪠㪚㪚㩷㪏㪇㪇㪇䉮䉝䈪䉴䉬䊷䊥䊮䉫䉕⏕⹺䉺䊷䉭䉾䊃ⷙᮨ䋺㪈ਁੱ㓸࿅㬍㪈㪇㪇ਁ㪪㪥㪧ᰴ਎ઍ䉴䊌䉮䊮䈪㪈㪌ᤨ㑆䊊䊷䊄䉡䉢䉝䉦䉡䊮䉺䈪䈲㪊㪏㪊㪞㪝㪣㪦㪧㪪䉮䉝ᒰ䈢䉍㪇㪅㪇㪌㪞㪝㪣㪦㪧㪪䋺ᢛᢙṶ▚ਛᔃ㸢 ᢛᢙṶ▚䈱ᶋേዊᢙὐṶ▚䈻䈱⟎䈐឵䈋䉕ᬌ⸛
ㅪ㎮ਇᐔⴧ䊑䊨䉾䉪䈅䈢䉍䈱䊊䊒䊨䉺䉟䊒䊂䊷䉺ᢙ䈱䉝䊮䊋䊤䊮䉴䈏䇮䊨䊷䊄䊋䊤䊮䉴䈮⋥⚿
㸢 ㈩ಽ䈱⷗⋥䈚䈮䉋䉎䊨䊷䊄䊋䊤䊮䉴䈱ᡷༀ䉕ᬌ⸛

ᕈ⢻䋨GFLOPS䋩•ో䉭䊉䊛㑐ㅪ⸃ᨆ㪧㪸㫉㪸㪟㪸㫇㫃㫆ᕈ⢻⹏ଔ䈫ዷᦸ

䉮䉝ᢙ

49

50

ᄢⷙᮨ䉲䊚䊠䊧䊷䉲䊢䊮䈱䊁䉴䊃

NEST䉲䊚䊠䊧䊷䉺Strong scaling

http://www.nest-initiative.org

Weak scaling• ᄢⷙᮨ␹⚻࿁〝䊝䊂䊦䈱ಽᢔ䉲䊚䊠䊧䊷䉲䊢䊮– ⃻ᤨὐ䈪਎⇇ᦨ㜞᳓Ḱ䈱㓸Ⓧᐲ䉕น⢻䈫䈚䈩䈇䉎

Reduced full cortex
Reduced visual cortex• O(100) 䊒䊨䉶䉾䉰䉁䈪⿥✢ᒻ䇮 O(1000) 䊒䊨䉶䉾䉰䉁䈪✢ᒻ䈱ᕈ⢻ะ਄
• CPU㑆䈱䊜䉾䉶䊷䉳䊌䉾䉲䊮䉫䈫䊙䊦䉼䉮䉝CPUౝ䈱䊙䊦䉼䉴䊧䉾䊂䉞䊮䉫䈱䊊䉟䊑䊥䉾䊄䉝䊷䉨䊁䉪䉼䊞• ㅪ⛯୯䈪䈱䉴䊌䉟䉪䉺䉟䊚䊮䉫䉕↪䈇䈢♖ᐲ⦟䈇Ⓧಽ• 䊡䊷䉱䊐䊧䊮䊄䊥䊷䈭Python䉟䊮䉺䊷䊐䉢䉴PyNEST• ᄙ⒳䈱䊆䊠䊷䊨䊮䊝䊂䊦䈫䉴䊌䉟䉪䉺䉟䊚䊮䉫ଐሽน႟ᕈ
(STDP) 䉕฽䉃ᄙ⒳䈱䉲䊅䊒䉴䊝䊂䊦䉕ታⵝน⢻• ⍴ᦼน႟ᕈ (STP)䉅ᛒ䈉䈖䈫䈏䈪䈐䉎
Eppler, Helias, Muller, Diesmann, and Gewaltig (2008)
51
Frontiers in Neuroinformatics 2:12. doi:10.3389/neuro.11.012.2008⃻࿷䈱䉲䊚䊠䊧䊷䉲䊢䊮䈲106 - 107 䊆䊠䊷䊨䊮䈎䉌䈭䉎䊝䊂䊦䈪ታᣉਛ
Kunkel S, Potjans T, Morrison A, Plesser HE, Diesmann M5252ᄢⷙᮨนⷞൻ䉸䊐䊃䉡䉢䉝䋨2䋩ᕈ⢻᷹ቯ䋨ੱ૕䊗䉪䉶䊦䋩ᄢⷙᮨนⷞൻ䉸䊐䊃䉡䉢䉝䋨䋱䋩㵶㵶㵶㩿ᦨ㜞⸃௝ᐲ䋺㪇㪅㪉㫄㫄㩷㫇㫀㫋㪺㪿㪃㩷㪉㪎㪅㪌㩷㪞㪭㫆㫏㪼㫃㪃㩷㪈㪇㪎㪞㪙㪀㩷㵶 㪩㪠㪚㪚㩷㪞㪧㪞㪧㪬䉪䊤䉴䉺㩿㫌㫇㪺㪀䉕૶↪

䊂䊷䉺䊨䊷䊄

䊂䊷䉺ಽഀ䈮䉋䉍䊂䊷䉺䊨䊷䊄䈲㪈ޯ㪊⑽⒟ᐲ䉁䈪㜞ㅦൻ䉕ታ⃻䊧䊮䉻䊥䊮䉫䈲㪇㪅㪋⑽⒟ᐲ
䉟䊜䊷䉳㊀⇥䈲৻ᩴ⒟⍴䈇ᤨ㑆㪌㪝㪧㪪㩿㪇㪅㪉㪲㫊㪼㪺㪆㪽㫉㪸㫄㪼㪴㪀䈱ታ⃻䈮䈲䊂䊷䉺䊨䊷䊄䈫䊧䊮䉻䊥䊮䉫䈱䉼䊠䊷䊆
䊮䉫䈏ᔅⷐ

㪈㪍㪇
㪈㪋㪇

ᤨ㑆㪲㫊㪴

㪇㪅㪇㪊
㪇㪅㪇㪉
㪇㪅㪇㪈

53

㪇

㪉㪇
㪇

㪈㪅㪉

㪇㪅㪇㪋
㪇㪅㪇㪋㪊
㪇㪅㪇㪋㪉

㪈

㪈㪇㪇㪞㪙

㪇㪅㪏

㪈㪅㪊㪏㪌

㪉㪌

㪈㪅㪊㪎㪏

㪋㪍

㪉㪅㪐㪐

㪉㪅㪐㪊

㪌㪇

㪎㪌

㪏㪞㪙

㪎㪌

㪈㪅㪊

㪉㪅㪐㪉
㪈㪅㪇㪐
㪈㪇㪇

㪈㪇㪇㪞㪙
㪏㪞㪙
㪈㪞㪙

㪇㪅㪍

㪇㪅㪍

㪇㪅㪏
㪇㪅㪌㪊
㪇㪅㪋

㪇㪅㪋
㪇㪅㪉
㪇

㪌㪇
ਗ೉ᢙ

㪈㪇

㪋㪅㪍㪊㪏

㪈㪅㪋

㪇㪅㪇㪋㪋

㪈㪞㪙

㪉㪌

㪌㪎㪅㪍
㪈㪊㪅㪐㪍

ਗ೉ᢙ

㪇㪅㪇㪋㪊

㪈㪇

㪎㪋㪅㪐

㪍㪇
㪋㪇

䉟䊜䊷䉳䉮䊮䊘䉳䉲䊢䊮

㪇㪅㪇㪊㪊
㪇㪅㪇㪉㪌
㪇㪅㪇㪊㪊
㪇㪅㪇㪉㪇㪅㪇㪉㪌
㪇㪅㪇㪉㪌
㪇㪅㪇㪉

㪈㪞㪙

㪏㪇

䊧䊮䉻䊥䊮䉫

㪇㪅㪇㪌
㪇㪅㪇㪋

㪏㪞㪙

㪈㪇㪇

㵨 䊂䊷䉺䊨䊷䊄䋺䉴䊁䊷䉳䊮䉫䋫㜞ㅦൻ㵨 䊧䊮䉻䊥䊮䉫䋺䊉䊷䊄ౝਗ೉ൻ㵨 㪥㪼㪿㪸㫃㪼㫄㪂㪫㪜㪪㪣㪘㩷㪚㪈㪇㪍㪇
㪈㪇㪇บ

㪈㪇㪇㪞㪙

㪈㪊㪎㪅㪍

㪈㪉㪇
ᤨ㑆㪲㫊㪴

㵶

㵶 ᄢⷙᮨਗ೉ൻ䈘䉏䇮ᄢⷙᮨ䊂䊷䉺䈮ኻᔕ䈚䈢นⷞൻ䉸䊐䊃䉡䉢䉝㵶 䊥䊝䊷䊃นⷞൻ䈮䉅ኻᔕ㵶 ੱ૕䊗䉪䉶䊦䊂䊷䉺䈪䈱䊁䉴䊃

ᤨ㑆㪲㫊㪴

51

•

㪈㪇㪇

㪇㪅㪋

㪈㪇

㪇㪅㪍㪌
㪇㪅㪊㪌

㪇㪅㪍

㪇㪅㪊㪍

㪇㪅㪊㪋
㪉㪌

㪇㪅㪋

㪌㪇
ਗ೉ᢙ

㪎㪌

㪈㪇㪇 54䉝䊒䊥䉬䊷䉲䊢䊮䊚䊄䊦䉡䉢䉝Sphere↥ᬺᔕ↪䈮ะ䈔䈢ᢛ஻ਗ೉䉸䊐䊃䉡䉢䉝㐿⊒ടㅦ䈱䈢䉄䈱䊒䊤䉾䊃䊐䉤䊷䊛•• ᄢⷙᮨ䈭ಽሶ䉲䊚䊠䊧䊷䉲䊢䊮䉕↪䈇䈢⮎೷䉴䉪䊥䊷䊆䊮䉫ะ䈔䊌䉟䊒䊤䉟䊮㐿⊒⠪ะ䈔ᯏ⢻– 䊤䊏䉾䊄䊒䊨䊃䉺䉟䊏䊮䉫
•
•
•

–
–
–
–

䊤䉟䊑䊤䊥⟲䈱೑↪
䈵䈭ᒻ೙ᓮ᭴ㅧ䈱೑↪
䉮䊷䊄ㇱຠ䈱ౣ೑↪

ᄢⷙᮨ઒ᗐൻว‛䊤䉟䊑䊤䊥䋨᧲ᄢ䋩

ਗ೉ಣℂᯏ⢻䈱೑↪
䉸䊷䉴䊘䊷䉺䊎䊥䊁䉞ᷙว⸒⺆ C++/F90, GPGPUㅪᚑ໧㗴䈱䉴䉪䊥䊒䊃⸥ㅀ䉺䊷䉭䉾䊃䉺䊮䊌䉪⾰᭴ㅧ

ൻว‛䊤䉟䊑䊤䊥Chemoinformatics•

䉣䊮䊄䊡䊷䉱ะ䈔ᯏ⢻– ⛔৻䈘䉏䈢UI䈫ታⴕⅣႺ
– XML䈮䉋䉎೙ᓮ– 䊙䊦䉼䊒䊤䉾䊃䊖䊷䊛
•

•

Ớ❗
䊤䉟䊑䊤䊥
┙૕᭴ㅧ
↢ᚑ

XML file :<SphereConfig SolverType="Incompressible_flow_solver" >

䊄䉾䉨䊮䉫

ᰴ਎ઍ
䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺ᰴ਎ઍ䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺,Linux cluster, Windows cluster,
BG, SX, Mac, Altix, T2K…

MM-PB/SA ಽሶേജቇ

⃻࿷䇮⤳ེోり䉴䉬䊷䊦䋨SPH3D,
HIFU䋩䊶⚦⢩䉴䉬䊷䊦䉼䊷䊛(RICS)
䈪೑↪

ಽሶേജቇ
⚿ᨐ⸃ᨆ

55

䊄䉾䉨䊮䉫
⚿ᨐ⸃ᨆ
ಽሶേജቇ
౉ജ䊐䉜䉟䊦
↢ᚑ

㔚⩄⸘▚
ಽሶ゠㆏ᴺ

䉲䊚䊠䊧䊷䉲䊢䊮

Accelrys Pipeline Pilot਄䈮᭴▽䊥䊷䊄ᦨㆡൻ䈻56䉁䈫䉄• 㐿⊒䉸䊐䊃䉡䉢䉝䋺ో䋳䋴ᧄ– 䈠䈱䈉䈤18ᧄ䋺䋱䋰䋲䋴ਗ೉એ਄– 10ᧄ䋺䋸䋰䋰䋰ਗ೉એ਄– นⷞൻ䉸䊐䊃䉅䋱䋰䋰GPGPUਗ೉• ੹ᓟ䇮ਗ೉ᕈ⢻䈱ᡷༀ• ᰴ਎ઍ䉴䊌䉮䊮䈮䊐䉞䉾䊃䈚䈢ᦨㆡൻ• ⸘▚ᤨ㑆䈮ว䉒䈞䈢ㆡᱜ䈭⸘▚ⷙᮨ䉕⸳ቯ䈚䇮೑↪⸘↹䉕┙᩺䇮䊐䊦Ⓙ௛䈮஻䈋䉎

13ᯏ㑐䋺᧲੩ᄢቇ䇮ᄢ㒋ᄢቇ䇮੩ㇺᄢቇ䇮᧲ർᄢቇ䇮ർ㒽వ┵ᄢቇ䇮᧲ᶏᄢቇ䇮ජ⪲ᄢቇ䇮ᘮᔕᄢቇ䇮ᮮᵿᏒᄢ䇮᧲Ꮏᄢ䇮ᐢፉᄢቇ䇮⛔⸘ᢙℂ⎇ⓥ
ᚲ䇮ℂൻቇ⎇ⓥᚲ
⚂200ฬ䈱⎇ⓥ⠪䋨䊘䉴䊄䉪⚂80ฬ䋩
57

Contributers

Workshop in 2009

Workshop in 2008

59

58

科 学 技 術 計 算 分 科 会

選 出2010 年度 科学技術計算分科会 会合 より

原子力研究開発を推進する
スーパーコンピュータシステムと原子力アプリケーション

日本原子力研究開発機構
平山 俊雄

2010 年 10 月 20 日

サイエンティフィック・システム研究会
2010 年度科学技術計算分科会会合資料

原子力研究開発を推進するスーパーコンピュータシステムと原子力アプリケーション
平山 俊雄 ・ 清水 大志 ・ 久米 悦雄
日本原子力研究開発機構・システム計算科学センター[アブストラクト]
原子力機構では、計算科学を活用した原子力の研究開発を加速するために、本年、３月には、Altix3700 Bx2（13TFlops）に替えて、国内最高性能となるピーク性能 200 TFlops の Linux クラスターシステム（BX900）とピーク性能 12 TFlopsの次世代計算機プロトタイプ機（FX1）からなる２種類のスーパーコンピュータを導入し、それらの運用を開始した。
BX900 は、旺盛な計算需要に応えるために、また FX1 は次世代計算機（京コンピュータ）の利用に向けた原子力アプリ
ケーションのチューニングを目的としている。
BX900 については、その利用開始後 3 日目で 90％を超える利用率を達成し、その後も高い利用状況が続いている。これは、原子力計算科学研究者が数千コアを用いた大規模並列計算コードの開発能力と利用技術力を既に兼ね備えていることを表している。次世代計算機向け原子力コードのチューニングについては、FX1 を用いたプロファイリングデータに基づく性能予測を行い、1PFlops までの良好な並列性能を推定した。また、新旧３機種のスーパーコンピュータの基本性能を比較した結果についても言及する。

[キーワード]
原子力計算科学、次世代計算機、ペタフロップス計算、BX900、FX1、ハイブリッド並列

1.

はじめに
計算科学技術は「理論」及び「実験」と並ぶ第 3 の研究手法として、21 世紀の先端的研究のフロン

ティアを切り開くための重要な基盤技術となっている。特に、原子力のような巨大技術においては、安全面や時間・空間の制約により実験が困難な場合が多く、計算科学技術は従来から重要な研究手段となっている。すなわち、計算科学技術は、原子力研究開発の効率化、原子力施設の安全評価、国際競争力強化のカギを握る技術となっている。原子力委員会においても、その原子力政策大綱の中で「シミュレーション技術の高度化による大規模な技術システム開発の効率化」を求めている。
原子力関連二法人の統合と独立行政法人化を経て、旧二法人が所有していたスーパーコンピュータの資源について、整理統合と合理化を果たし、膨大な計算需要に応えるための新たな設備を導入すると共に、京コンピュータの利用に向けた準備を整えた。
2.

新スーパーコンピュータの性能比較
BX900 の Linpack 性能は 191.40 TFlops、実行効率 95.66 ％であり、2010 年 6 月時点の TOP500によれば世界 22 位、実行効率世界 2 位であった。FX1 については、11.66 TFlops、実行効率 90.37 %である。
第 1 図に、新旧 3 機種の HPC Challenge
Benchmark の 性 能 を 示 す 。 こ こ で 、Altix3700Bx2(Itanium2)は更新前の機種で、ピーク性能 13 TFlops である。Altix3700Bx2 に比較して、BX900 は演算性能、通信性能ともにコアあたりのピーク性能差（～2 倍）だけの改善がみられる。ただし、プロセス間通信のバンド幅および遅延については、ソケットあたりのコア数の増加やインターコネクトの構造の違いのため、単純に比較することができない。
FX1 については、実効メモリバンド幅及びプ1

ロセス間通信性能が BX900 と比較して低位にある。特に、実効メモリバンド幅については、BX900 が
カタログ性能の 70％程度出ているのに対し、FX1 では 30％以下となっている。この問題は、メモリコ
ントローラチップが CPU の外にあることに起因しているようだが、京コンピュータでは CPU 内蔵
内臓となっており、本問題は解決しているとのことである。
3.

京コンピュータの利用に向けたチューニングと性能予測
将来において膨大な計算需要を擁している核融合コードについて、
将来おいて膨大な計算需要を擁している核融合コードについて、PFlops
級の計算を想定した並列性

能および実行性能を BX900 および FX1 を用いて評価した。
BX900 の 16,384 コアを用いて並列性能を評価した結果、全てのコアに対して MPI プロセスを割り当てる FlatMPI では MPI プロセス間通信量の増大により、全体処理性能は大幅に低下する。したがって、大規模並列計算ではスレッド並列を併用する Hybrid 並列化を用いることで、MPI プロセス数を削減することが必須となる。なお、富士通 Fortran の自動並列化は核融合コードについてはかなりの部分で有効であった。また、メモリ使用量を軽減する上でも、Hybrid 並列化は有効である。
第 2 図は、京コンピュータ 4096 並列（～500TFlops）
上での性能予測結果である。FX1 の 256CPU（1024コア）を用いて性能予測をするため、4096 並列の 1 プ
ロセスあたりの問題規模を保ったまま、weak scalingを仮定して 4096 プロセス並列から 256 プロセスにス
ケールダウンをする。次に、FX1 の 256CPU を用いて取得したプロファイリング情報に対して、FX1 から京コンピュータへの性能変換表を用いて演算時間を推定した。通信時間については、当該コードの通信の種類、
データ長、通信回数を調査し、インターコネクトのト
ポロジー（仮定）をもとに机上計算により推定している。
演算性能については、京コンピュータにおいてプロセスあたり 2.4 倍程度の高速化が期待できる。京コンピュータのコア数が、4 コア（FX1）から 8 コア（京）と 2 倍になっていることから、演算性能は十分にスケールしているといえる。しかし、1 コアあたりの性能はすでに飽和しつつあることに留意する必要がある。したがって、京コンピュータの利用にあたっては、コア数が増えた時のコードの並列化性能が特に重要になる。
第 3 図は、京コンピュータの 1PFlops について、
上記推定手法に基づいた 2 段階の Strong Scaling である。1PFlops においても良好な並列化性能が期待できることがわかる。
4.

まとめ
日本原子力研究開発機構では、「シミュレーション

技術の高度化による大規模な技術システム開発の効率化」を求めた原子力政策大綱に基づき、計算科学的手法を用いた原子力研究開発を推進してきた。その結果、年間の論文数の 20％以上が計算科学的手法を用いた研究に移行している。しかし、数 PFlops に達する膨大な潜在需要に応えるためには、計算機資源の不足は深刻な状況であり、京コンピュータの積極的利用が不可欠となっている。
京コンピュータのプロトタイプ・アーキテクチャの FX1 を用いたコード分析とチューニングは、京コンピュータの利用に向けた準備作業として極めて有効であることを確認した。また、原子力コードについて FX1 を用いたチューニングを行い、1PFlops までの良好な並列性能を確認した。

2ḩώҾ‫܇‬щᄂᆮểᚘምᅹ‫ܖ‬ḪώἋὊἣὊἅὅἦἷὊἑૢͳᚘဒ

ḫώૼἋὊἣὊἅὅἦἷὊἑỉࣱᏡḬώʮỉМဇỆӼẬẺἩἿἂἻἲ᧏ႆ

ḭώ

ộểỜ

1

2

Japan Atomic Energy Agency

Japan Atomic Energy Agency

Ძ

Ძ
Წ
Ჭ
Ხ
Ჯ

Ҿ‫܇‬щೞನᄂᆮ᧏ႆਗໜ

Ҿ‫܇‬щᄂᆮ᧏ႆਗໜ
Ҿ‫܇‬щᄂᆮ᧏ႆᾃ‫ٻ‬ἩἿἊỹἁἚҾ‫܇‬щᄂᆮỆấẬỦᚘምᅹ‫ܖ‬ỉࢫлҾ‫܇‬щᄂᆮЎ᣼ỉኰʼ഑቟ỆấẬỦҾ‫܇‬щᄂᆮ᧏ႆểᚘምᅹ‫ܖ‬ỉྵཞ
3

4

Japan Atomic Energy AgencyᲬJapan Atomic Energy AgencyҾ‫܇‬щᄂᆮ᧏ႆᾃ‫ٻ‬ἩἿἊỹἁἚᲭҾ‫܇‬щᄂᆮỆấẬỦᚘምᅹ‫ܖ‬ỉࢫл Ҿ‫܇‬щỉᄂᆮ᧏ႆỆấẟềẆᚘምᅹ‫ܖ‬২ᘐỊྸᛯẆ᬴ܱểɳốᇹᾂỉ௵ ᄂᆮ᧏ႆỉјྙ҄ỉҾѣщ¾ Ҿ‫܇‬щЎ᣼ỆấẟềỊẆ‫ᙹٻ‬೉ễ଀ᚨὉᚨͳửဇẟỦ᬴ܱộẺỊᧈ஖᧓ửᙲẴỦ᬴ܱởẆᚇยầ‫׉‬ᩊễྵᝋỆếẟềẆᚘምᅹ‫ܖ‬২ᘐỊẸỉᚐଢởʖยửӧᏡỆẴỦ Ҿ‫܇‬щ଀ᚨỉ‫ܤ‬μᚸ̖Ệ࣏ᙲɧӧഎ
¾ ᚘምᅹ‫ܖ‬২ᘐỊẆҾ‫܇‬໐஬૰Ὁఋ༓૰ỉኺ࠰‫҄٭‬ẆҾ‫܇‬щ଀ᚨỉ᎑ᩗࣱሁỉᛇኬửᚸ̖ὉʖยӧᏡỆẴỦ¾ ‫ܤ‬μࣱὉͤμࣱᚸ̖ỆஇૼჷᙸửӕụλủỦẺỜỉ࣏᪰২ᘐ ‫׎‬ᨥᇤʗщࢍ҄ỉỽἀử੮Ủ২ᘐ
¾ Ҿ‫܇‬щЎ᣼ồỉᚘምᅹ‫ܖ‬২ᘐỉࣖဇỆợụẆẐ᬴ܱὉᚨᚘỉጮụᡉẲỆợỦ᧏ႆẑẦỤẐ᭗ችࡇἉἱἷἾὊἉἹὅʖยỆؕỀẪ᧏ႆỉјྙ҄ẑồể২ᘐ᪃ૼửӧᏡỆẴỦ¾ ቟ᵢᵭᵣᵊᴾᴾ഑ᵣᵳᵰᵟᵲᵭᵫỆấẟềờẆҾ‫܇‬໐ỉᚨᚘẆ‫ܤ‬μẆ஬૰Ệ̞ỦἉἱἷἾὊἉἹὅ
২ᘐ᧏ႆሁửܱ଀
5

Japan Atomic Energy Agency

6

Japan Atomic Energy AgencyҾ‫܇‬щ‫ۀ‬Ճ˟ẦỤỉᙲᛪҾ‫܇‬щᄂᆮЎ᣼ỉኰʼᲮὼ ᚘምᅹ‫ܖ‬২ᘐử෇ဇẲẺҾ‫܇‬щᄂᆮ᧏ႆỉ࣏ᙲࣱ ὼ ἉἱἷἾὊἉἹὅ২ᘐỉ᭗ࡇ҄ሁỆợỦ‫ᙹٻ‬೉ễ২ᘐἉἋἘἲ᧏ႆỉјྙ҄¾ Ҿ‫܇‬щ૎ሊ‫ٻ‬ዠ இ᭗൦แỉᚘምೞἉἱἷἾὊἉἹὅᏡщửૢͳὉዜਤὉႆ‫ޒ‬ ᧏ႆἉἋἘἲỉᢘӳࣱửଔẟെ᨞ẦỤᚘምೞỆợỦἴἙἼὅἂὉ
ἉἱἷἾὊἉἹὅ২ᘐሁửᬝ̅Ẳề‫ٶ‬᩿ႎỆᚸ̖¾ ᇹᾄ‫ׅ‬Ҿ‫܇‬щ‫ۀ‬Ճ˟᝻૰ᇹᾀӭ ί཯ᇌᘍ૎ඥʴଐஜҾ‫܇‬щᄂᆮ᧏ႆೞನỉഏ஖ɶ஖Ⴘ೅ỉሊ‫ܭ‬Ệếẟềίᙸᚐὸὸ ᡈ࠰࣯ᡮỆᡶഩẲềẨẺऴ‫إ‬২ᘐẆἴἙἼὅἂểἉἱἷἾὊἉἹὅ
২ᘐửᬝ̅ẲềẆࣱᏡႸ೅ửᢋ঺ẴỦἉἋἘἲܱྵửẆᚨᚘẆᙌᡯὉ࡫ᚨẆᢃ᠃ẆࡑూỆᐱỦẴỔềỉἩἿἍἋỆếẟềẆᄂᆮ᧏ႆỉӧᏡễᨂụИ஖ỉെ᨞ẦỤ‫ٶ‬᩿ႎẦế࣋ࡁႎỆ౨᚛ẴỦἧἿὅἚἿὊἙỵὅἂ‫׹‬ỉᄂᆮ᧏ႆ෇ѣỉ‫ݰ‬λử౨᚛¾ Ҿ‫܇‬щ‫ۀ‬Ճ˟ ᄂᆮ᧏ႆ‫ᧉݦ‬ᢿ˟᝻૰ Ҿ‫܇‬щ૎ሊ‫ٻ‬ዠỆᅆẲềẟỦҾ‫܇‬щᄂᆮ᧏ႆỆ᧙ẴỦӕኵỉؕஜႎᎋả૾ỉᚸ̖ᾀఋᗡӳἩἻἌἰʏ්ἉἱἷἾὊἉἹὅ

ᾁҾ‫܇‬щೞ֥ϋඖᬸʚႻ්ᚐௌ

ᾂἜἚἼỸἲϬҲ᭗ᡮ໐ỆấẬỦ᩼‫්ࠝܭ‬ѣྵᝋᾃᇹɟҾྸᚘምỆợỦ஬૰э҄ἳỽἝἌἲ
ίቩမᏤ҄ὸỉᄂᆮᾄẸỉ˂ᚘምᅹ‫ܖ‬ᄂᆮʙ̊

7

8

Japan Atomic Energy AgencyᾀJapan Atomic Energy AgencyఋᗡӳἩἻἌἰʏ්ἉἱἷἾὊἉἹὅ

ᚘምἅὊἛӸᾉᵥᵲᵓᵢᾁᚘምἅὊἛӸᾉᵲᵮᵤᵧᵲ‫׎‬ᨥ༏ఋᗡӳ᬴ܱ໐ ᵧᵲᵣᵰᵓഏΨᢃѣᛯἴἙἽỆợỦఋᗡӳ໐࣎μ˳ỉἩἻἌἰʏ්᠞ᡛἉἱἷἾὊἉἹὅ

‫ᙹٻ‬೉ૠ͌ᚐௌƴؕƮƖ‫ܱ׹ٻ‬᬴ƴ̔‫܍‬ƠƳƍҾ‫܇‬໐༏ᚨᚘ৖ඥƷ᧏ႆ

ᚘምỉႸႎ

ᚘምϋܾ

ᐮမἩἻἌἰᚾ᬴ᘺፗ ᵨᵲᵔᵎᵳ

ൢ෩ʚႻ්ਫѣǛ᬴ܱࡸǛ̅ဇƤƣŴൢ෩မ᩿Ʒ࢟ཞ‫҄٭‬ሁǛႺ੗ᚐௌƢǔƜƱưŴҾ‫܇‬໐ϋƷᛇኬƳʚႻ්ᚐௌǛᘍƏ‫׹ݱ‬ᘺፗἴἙἽ
ᵆྵཞἇỶἌᵇ‫׹ݱ‬ᘺፗ

ᵨᵲᵔᵎᵳ

ᵧᵲᵣᵰ

໐࣎˳ᆢ

6m3

60m3

800m3

఍‫܇‬ૠ

5.24 x 109

1.38 x 1011

1.23 x 1012

∇∈∐᣽

800GB

14TB

147TB

30TFlopsὉday

750TFlopsὉday

7PFlopsὉdayᚘም᣽‚ܱјࣱᏡ∝ଐ‛Ҿ‫܇‬щೞ֥ϋඖᬸʚႻ්ᚐௌ

‫ᙹٻ‬೉ ᭗᫇ȷᧈ଺᧓ Ƴ᬴ܱኽௐƕɧᙲ̅ဇᎍƷኺ᬴ƴ̔‫܍‬ƠƳƍ ኺ᬴ƴ̔‫܍‬ƢǔᚐௌȑȩȡȸǿƕƳƍҥɟƷǳȸȉưಮŷƳᚐௌƕӧᏡ

‚⁓‛ൢණ්

‚⁔‛ ්֩

ʚႻ්ᚐௌኽௐ

Ҿ‫܇‬໐ϋʚႻ්ᚐௌኽௐ

ಮẉễ࢟७ỉʚႻ්ầᚐௌӧᏡьᡮ֥ᬝѣ໐ỉఋᄊᄃἑὊἄἕἚ

9

10

Japan Atomic Energy AgencyἜἚἼỸἲϬҲ᭗ᡮ໐ỆấẬỦ᩼‫්ࠝܭ‬ѣྵᝋᚘምἅὊἛӸᾉᵟᵯᵳᵟᵊᴾᵫᵳᵥᵲᵦᵣᵱᾃᚘምἅὊἛӸᾉᵴᵟᵱᵮ

ქ଺ỉภࡇ්ᡮЎࠋί‫׶‬Ⴚૺ᩿ὸ
ហᾉ᭗ภἜἚἼỸἲẆ᩷ᾉ˯ภἜἚἼỸἲ᭗ἇỶἁἽ༏၅іᚐௌወᚘϼྸஜᄂᆮỂỊẐቩမᏤ҄ẑểẟạэ҄ỆếẟềẆҾ‫܇‬Ὁᩓ‫܇‬ἾἫἽẦỤẆẸỉἳỽἝἌἲửଢỤẦỆẴỦẇ

᭗˯ภἜἚἼỸἲỉฆӳỆợỦภࡇ‫٭‬ѣửἉἱἷἾὊἉἹὅẇ᭗ἇỶἁἽ༏၅іỉҾ‫׆‬ểễỦภࡇ‫٭‬ѣỉႆဃử৮СẴỦዼԧሊỉ੩ᚕểẸỉјௐử౨ᚰẇϬҲኒᣐሥϋử්ủỦϬҲ஬ίἜἚἼỸἲὸỉ්ủửἉἱἷἾὊἉἹὅẇᡞᾛ‫܌‬ᣐሥỆấẟềỴὊἓཞỉพầႆဃẲềẟỦཞ७ẇẮỉพỉႆဃỆợỦᣐሥਰѣồỉࢨ᪪ửᚐௌẇ

Japan Atomic Energy Agency‫ٳ‬਴ỆợỦ
சஹỉэ҄ʖย

Ҿ‫܇‬໐ನᡯ஬૰ỉэ҄ἳỽἝἌἲᚐଢửᡫẲềẆҾ‫܇‬໐ỉ᭗ኺ࠰҄‫ݣ‬ሊỆᅹ‫ܖ‬ႎὉӳྸႎఌਗử੩̓ẴỦẮểẇ

ዼԧሊᾉᵡᵧᵮửɥଞίᵓᵎᶋᶋḵᵏᵎᵎᶋᶋὸ

ᚘምἅὊἛӸᾉᵫᵳᵥᵲᵦᵣᵱᵊᴾᵱᵲᵟᵰᵋᵡᵢᵊᴾᵟᵠᵟᵯᵳᵱэ҄ἳỽἝἌἲử৭੮ẲễẬủịẆᅹ‫ܖ‬ႎὉӳྸႎఌਗỆؕỀẪэ҄ʖยầỂẨễẟ

ᚘምỉႸႎẆಒᙲḤჵҮỊСࣂొԗụỉཎࣉႎễ්ủ

‫ٻ‬ӝࢲᣐሥỉ්ѣਰѣᚐௌᇹɟҾྸᚘምỆợỦ஬૰э҄ἳỽἝἌἲίቩမᏤ҄ὸỉᄂᆮ

஬૰э҄

ᾂ

Japan Atomic Energy Agency࣯ນỆэ҄ẴỦ
ӧᏡࣱỊᾎ

э҄ἙὊἑ
ܱย͌

˴࠰έộỂ
‫ٳ‬਴ỂẨỦẦᾎ
ᢅӊ

ྵ‫נ‬

சஹ

଺᧓

ᚘ ም ϋ ܾኽ୒ቩမỉҾ‫܇‬ἴἙἽử˺ụẆᇹɟҾྸᚘምỆợẾềɧኝཋΨእỉቩမồỉᨼộụởẴẰẆቩမࢍࡇỉ‫҄٭‬ửᛦỔỦẇ

ỴὊἓཞพ
ನᡯỉ࢟঺
11

12

Japan Atomic Energy Agencyᚘምᅹ‫ܖ‬ᄂᆮʙ̊ᾄ᣻ໜ‫ܤ‬μᄂᆮᚘဒᾉ᎑ᩗ‫ܤ‬μᚸ̖ỉẺỜỉᵑഏΨˎेਰѣӨẐờỮẳỠẑᔕൢႆဃ֥ỉನᡯὼ්ѣὼᩓᄬ‫ئ‬ἉἱἷἾὊἉἹὅ

‫ע‬ᩗᵮᵱᵟểᡲઃẲẆμ˳ᘽࡇᚸ̖ửӧᏡỆẇᚨᚘᚸ̖২ᘐồỉ‫᧏ޒ‬Ὁᚾ᬴‫ׅ‬ૠỉЪถ‫ע‬ᩗᵮᵱᵟểᡲઃẲẆμ˳ᘽࡇᚸ̖ửӧᏡỆẇᚨᚘᚸ̖২ᘐồỉ‫᧏ޒ‬Ὁᚾ᬴‫ׅ‬ૠỉЪถὼҾ‫܇‬щೞನ ᵆᄂᆮ঺ௐỆ‫ݣ‬ẴỦᚘምᅹ‫ܖ‬ỉᝡྂᵇὼ᭗ภ߻‫ܖ‬ᚾ᬴ᄂᆮ໐ᵆᵦᵲᵲᵰᵇỉʚ᣻ሥᚐௌỉ‫ܤ‬μᄩᛐỆᝡྂᙐᩃನᡯỉཎࣱửദᄩỆ৭੮௥߃ᙹ೉ỉ‫ע‬ᩗỂờͤμἉἋἘἲᚘምᅹ‫ܖ‬ἍὅἑὊᾂഏΨˎेਰѣӨʚ᣻ሥᵘ ࢟ཞầᙐᩃ‫ٳ‬ሥ ᛯ૨ૠỂỊẆᵓ࠰᧓Ểኖᵐ̿Ệ‫ف‬ь᬴ܱᜂΨᾉὉᢿԼૠᵓᵎᵎ
Ὁμᧈᵏᵎᵎᶋ

ἋἬὊἇ
⏺
⏷
␈
⏣
ὺ
న
ᙲ
እ
␌
⏱
␕

 Ҿ‫܇‬щೞನ঺ௐί௹ᛠ˄ᛯ૨ὸỉ ᵐ὿ήˌɥầᚘምᅹ‫ܖ‬২ᘐႎ৖ඥỆợỦʚ᣻ሥᡫࠝᣐሥᾉ࢟ཞầҥኝễẺỜᚘምầܾତ Ҿ‫܇‬щؕᄽẆఋᗡӳẆഏɭˊᢿᧉỂỊᢿᧉμ˳ỉ঺ௐỉᵏᵍᵒ῍ᵏᵍᵑᴾửҩỜỦϋሥܱยኵᇌನᡯᚐௌ

ܱἋἃὊἽܱἴἙἽᚐௌ

᭗ࢍࡇἾὊἈὊỆợỦ᭗Ỻ἟ἽἀὊቩ‫܇‬ίૠҗᵫᶃᵴኢᨗ‫܇‬ዴὸႆဃ્‫ݧ‬ዴỆợỦ੷ͻᵢᵬᵟỉ̲ࣄἑὅἣἁឋೞᏡử੕ኧᵑᵎỶỼὅầᨼᆢᩓမửᛔឪᵓᵎᵎᵦᶘᩭⲢว⎇ⓥ㐿⊒ㇱ㐷Ў‫܇‬ѣщ‫ܖ‬ἉἱἷἾὊἉἹὅίᵱᵡᵳᵠᵟὸ ỆợỦဃԡؕஜྵᝋửᚐଢἼἮἏὊἲೞᏡႆྵἉἱἷἾὊἉἹὅ

ᶗᵋᶁᶍᶍᶐᶂᶇᶌᵿᶒᶃᴾᵹᶋᶋᵻᵑഏΨቩ‫܇‬ἉἱἷἾὊἉἹὅỆợỦૼẲẟьᡮೞನửႆᙸσਰԗඬૠܱย͌ểൔ᠋౨ᚰ

ᄬൢӑಊ‫܇‬พᵆᄬ‫ࡇࢍئ‬ЎࠋὸἉἱἷἾὊἉἹὅኽௐ

䎃ᓥ᧪
䎃ឭ᩺

ਰࠢ

ʚ᣻ሥૺ᩿

ᵏᵎ
ᵒᵑ

ᶖᵋᶁᶍᶍᶐᶂᶇᶌᵿᶒᶃᴾᵹᶋᶋᵻᵔᵖᰴ਎ઍේሶജ䉲䉴䊁䊛⎇ⓥ㐿⊒ㇱ㐷䉲䉴䊁䊛⸘▚⑼ቇ䉶䊮䉺䊷

㪈㪇㪇㩼

㪈㪇㪇㩼

㪈㪇㪇㩼

㪏㪇㩼

㪏㪇㩼

㪏㪇㩼

㪏㪇㩼

㪍㪇㩼

㪍㪇㩼

㪍㪇㩼

㪍㪇㩼

㪋㪇㩼

㪋㪇㩼

㪋㪇㩼

㪉㪇㩼

્‫ݧ‬ዴỆợỦ
੷ͻᵢᵬᵟ̲ࣄ
ἑὅἣἁឋೞᏡ
ἉἱἷἾὊἉἹὅ

ේሶജၮ␆Ꮏቇ⎇ⓥㇱ㐷

㪈㪇㪇㩼

㪇㩼

㪏㪅㪋㩼
㩿㪈㪐ઙ㪀

㪉㪋㪅㪎㩼
㩿㪋㪈ઙ㪀

㪊㪇㪅㪌㩼
㩿㪍㪉ઙ㪀

㪉㪈㪅㪊㩼
㩿㪊㪍ઙ㪀

㪉㪎㪅㪋㩼
㩿㪋㪏ઙ㪀

㪟㪈㪎ᐕᐲ 㪟㪈㪏ᐕᐲ 㪟㪈㪐ᐕᐲ 㪟㪉㪇ᐕᐲ 㪟㪉㪈ᐕᐲ䋨ో㪉㪉㪍ઙ䋩 䋨ో㪈㪍㪍ઙ䋩 䋨ో㪉㪇㪊ઙ䋩 䋨ో㪈㪍㪐ઙ䋩 䋨ో㪈㪎㪌ઙ䋩

㪉㪇㩼
㪇㩼

㪈㪐㪅㪉㩼
㩿㪉㪐ઙ㪀

㪈㪐㪅㪊㩼
㩿㪊㪊ઙ㪀

㪊㪇㪅㪌㩼
㩿㪌㪇ઙ㪀

㪊㪉㪅㪈㩼
㩿㪌㪈ઙ㪀

㪊㪊㪅㪌㩼
㩿㪌㪉ઙ㪀

㪟㪈㪎ᐕᐲ 㪟㪈㪏ᐕᐲ 㪟㪈㪐ᐕᐲ 㪟㪉㪇ᐕᐲ 㪟㪉㪈ᐕᐲ䋨ో㪈㪌㪈ઙ䋩 䋨ో㪈㪎㪈ઙ䋩 䋨ో㪈㪍㪋ઙ䋩 䋨ో㪈㪌㪐ઙ䋩 䋨ో㪈㪌㪌ઙ䋩㪉㪇㩼㪇㩼㪈㪇㪇㪅㪇㩼
㩿㪉㪌ઙ㪀㪈㪇㪇㪅㪇㩼
㩿㪊㪌ઙ㪀㪈㪇㪇㪅㪇㩼
㩿㪊㪍ઙ㪀㪈㪇㪇㪅㪇㩼
㩿㪋㪐ઙ㪀㪈㪇㪇㪅㪇㩼
㩿㪋㪍ઙ㪀

㪋㪇㩼

㪌㪅㪏㩼
㩿㪌ઙ㪀

㪉㪍㪅㪉㩼
㩿㪈㪍ઙ㪀

㪊㪉㪅㪏㩼
㩿㪉㪇ઙ㪀

㪉㪏㪅㪍㩼
㩿㪉㪉ઙ㪀

㪊㪌㪅㪈㩼
㩿㪊㪐ઙ㪀

㪟㪈㪎ᐕᐲ 㪟㪈㪏ᐕᐲ 㪟㪈㪐ᐕᐲ 㪟㪉㪇ᐕᐲ 㪟㪉㪈ᐕᐲ䋨ో㪏㪍ઙ䋩 䋨ో㪍㪈ઙ䋩 䋨ో㪍㪈ઙ䋩 䋨ో㪎㪎ઙ䋩 䋨ో㪈㪈㪈ઙ䋩㪉㪇㩼㪇㩼㪟㪈㪎ᐕᐲ 㪟㪈㪏ᐕᐲ 㪟㪈㪐ᐕᐲ 㪟㪉㪇ᐕᐲ 㪟㪉㪇ᐕᐲ䋨ో㪉㪌ઙ䋩 䋨ో㪊㪌ઙ䋩 䋨ో㪊㪍ઙ䋩 䋨ో㪋㪐ઙ䋩 䋨ో㪋㪍ઙ䋩

13

14

Japan Atomic Energy Agency

Japan Atomic Energy Agency഑቟ỆấẬỦҾ‫܇‬щᄂᆮ᧏ႆểᚘምᅹ‫ܖ‬ỉྵཞᲯὼ഑߸ίἧἻὅἋҾ‫܇‬щ࠻ὸỆấẬỦҾ‫܇‬щᚘምᅹ‫ܖ‬ỉѣӼὼὼ቟‫׎‬ỆấẬỦҾ‫܇‬щᚘምᅹ‫ܖ‬ᄂᆮỉѣӼὼ

ሥᠤ

Ў᣼

Ҿ‫܇‬щ

DOE

ೞ᧙Ӹό

᪯ˮ

ORNL

ᾀ

LANL

ᾂ

LLNL

ᾇ

ANL

ᾈ

SNL

ᾀ὿

NSF

ؕᄽὉؕႴ

Ἐ἟ἉὊ‫ٻ‬ᾃ

NASAᑋᆰ‫ܬܢ‬

ARC

ᾅ

PRACE

ỴἽἆὅ἞‫׎‬ᇌᄂᆮ৑ỉἩἾἋႆᘙ
ίᾁ὿὿ᾈ࠰ᾀᾁஉᾂᾀଐᾏἝἷὊἺὊἁἑỶἲἌὸ

“At Argonne Lab, a Shift FromRadioactivity to Supercomputers”

ἋὊἣὊἅὅἦἷὊἑᵲᵭᵮᵓᵎᵎίᾁ὿ᵏᵎ࠰ᵔஉὸ
ᙀឱᾉᵐˮểᾆˮỊẆᵬᵿᶒᶇᶍᶌᵿᶊᴾᵱᶓᶎᶃᶐᶁᶍᶋᶎᶓᶒᶇᶌᶅᴾᵡᶃᶌᶒᶐᶃᴾᶇᶌᴾᵱᶆᶃᶌᶘᶆᶃᶌᵆɶ‫׎‬ᵇᵓˮỊẆᵤᶍᶐᶑᶁᶆᶓᶌᶅᶑᶘᶃᶌᶒᶐᶓᶋ ᵨᶓᶃᶊᶇᶁᶆ ᵆ཯‫׎‬ᵇᾀώἡὊἛỸỹỴίἋὊἣὊἅὅἦἷὊἑሁὸ

ᾁώἏἧἚỸỹỴίἉἱἷἾὊἉἹὅểἴἙἼὅἂὸ

Ṽᡲᢰ૎ࡅỆợỦᄂᆮὉ‫ܖ‬ᘐೞ᧙ӼẬૅੲίࠊ‫ئ‬ᾃᾄήὸṼᵲᵭᵮᵓᵎᵎỉᵓᵎˮˌϋɶẆᵏᵖӨỊ‫׎‬ᇌᄂᆮ৑ỂᢃဇṼέᇢᅹ‫ܖ‬ἅὅἦἷὊἑὊᄂᆮόἩἿἂἻἲሁỆợỦਗໜ҄ίᵭᵰᵬᵪẆᵟᵬᵪሁỺ἟ἽἀὊ᪃ૼਗໜẑửоᚨὉᢃփὸ
Ṽዮ᫇ᵑᵔᵔႊɢἛἽỉ৲᝻ႆᘙίᵏᵐᵐႊɢἛἽᵍᵓ࠰Ὁਗໜὸ

όᵭᵰᵬᵪᵘᴾᵭᵿᶉᴾᵰᶇᶂᶅᶃᴾᵬᵿᶒᶇᶍᶌᵿᶊᴾᵪᵿᶀᶍᶐᵿᶒᶍᶐᶗᵊᴾᵪᵟᵬᵪᵘᴾᵪᶍᶑᴾᵟᶊᵿᶋᶍᶑᴾᵬᵿᶒᶇᶍᶌᵿᶊᴾᵪᵿᶀᶍᶐᵿᶒᶍᶐᶗᵊ
ᵪᵪᵬᵪᵘᴾᵪᵿᶕᶐᶃᶌᶁᶃᴾᵪᶇᶔᶃᶐᶋᶍᶐᶃᴾᵬᵿᶒᶇᶍᶌᵿᶊᴾᵪᵿᶀᶍᶐᵿᶒᶍᶐᶗᵊᴾᵟᵬᵪᵘᴾᵟᶐᶅᶍᶌᶌᶃᴾᵬᵿᶒᶇᶍᶌᵿᶊᴾᵪᵿᶀᶍᶐᵿᶒᶍᶐᶗᵊ
ᵱᵬᵪᵘᴾᵱᵿᶌᶂᶇᵿᴾᵬᵿᶒᶇᶍᶌᵿᶊᴾᵪᵿᶀᶍᶐᵿᶒᶍᶐᶗᵊᴾᵟᵰᵡᵘᴾᵟᶋᶃᶑᴾᵰᶃᶑᶃᵿᶐᶁᶆᴾᵡᶃᶌᶒᶃᶐ

ᵣᵳἩἿἊỹἁἚᾉᵮᵰᵟᵡᵣ

ᵡᵣᵟỆấẬỦᚘምᅹ‫ܖ‬ਖ਼ᡶਗໜᚨᇌ

ᾀώἡὊἛỸỹỴίἋὊἣὊἅὅἦἷὊἑሁὸ

ᾁώἏἧἚỸỹỴίἉἱἷἾὊἉἹὅểἴἙἼὅἂὸ

ṼႸ೅ᾉӼẮạᾄ࠰᧓ỂᵔẦ৑ỆૠἬἑኢᚘምೞử‫ݰ‬λṼ৲᝻ᾉᾃ὿὿ႊɢἸὊἿᵍᾄ࠰ṼࢼஹᾉᵡᵣᵟϋᾆਗໜỂᚘምᅹ‫ܖ‬ửਖ਼ᡶṼૼ˳Сᾉᚘምᅹ‫ܖ‬ỆợỦҾ‫܇‬щᄂᆮỉьᡮᘙଢί഑߸ỆấẬỦέᇢᚘምᅹ‫ܖ‬ᄂᆮᡲઃὸ

όᵟᶂᶔᵿᶌᶁᶃᶂᴾᵱᶁᶇᶃᶌᶒᶇᶄᶇᶁᴾᵡᶍᶋᶎᶓᶒᶇᶌᶅᴾᵰᶃᶑᶃᵿᶐᶁᶆ

ίἧἻὅἋҾ‫܇‬щ࠻ỆấẬỦᚘምᅹ‫ܖ‬ỉ෇ࣱ҄ὸ

15

16

Japan Atomic Energy Agency

Japan Atomic Energy Agencyὼ഑቟ỉἧἻἕἂἉἕἩἰἉὅỆấẬỦᚘምೞ᝻เлụ࢘ềὼᵭᵰᵬᵪᵋᵨᵿᶅᶓᶃᴾ
ᵡᶐᵿᶗᵶᵲᵓᵊᴾᵐᵌᵑᵮᵤᶊᶍᶎᶑᵆᵲᶍᶎᵓᵎᵎᵋᵰᵿᶌᶉᵏᵇ
Geosciences, 10,000,000

Computer
Science,8,000,000

Physics,
44,000,000ᵤᵸᵨᵋᵨᵳᵥᵣᵬᵣ
ᵧᵠᵫᴾᵠᶊᶓᶃᵥᶃᶌᶃᵍᵮᵊᴾᵏᵮᵤᶊᶍᶎᶑᵆᵲᶍᶎᵓᵎᵎᵋᵰᵿᶌᶉᵓᵇ

Biology,
23,600,000

Astrophysics,
88,500,000

Chemistry,
24,660,000

Physics,
115,000,000
Chemistry,
46,283,200

Materials,
64,200,000
Fusion,74,000,000ᲫAstrophysics,
43,600,000

Climate,61,100,000

ᲬClimate,35,000,000

Materials,
40,260,000

Fusion,50,000,000ᲭᲮḤᵭᵰᵬᵪἙὊἑᵘᴾᶆᶒᶒᶎᵘᵍᵍᶕᶕᶕᵌᶌᶁᶁᶑᵌᶅᶍᶔᵍᶊᶃᵿᶂᶃᶐᶑᶆᶇᶎᵋᶑᶁᶇᶃᶌᶁᶃᵍᶎᶐᶍᶈᶃᶁᶒᵋᵿᶐᶁᶆᶇᶔᶃᵋᶊᶇᶑᶒᵍᶄᶗᵎᵗᵋᶎᶐᶍᶈᶃᶁᶒᶑᵍḤᵤᵸᵨἙὊἑᵘᴾᶆᶒᶒᶎᵘᵍᵍᶕᶕᶕᵌᶎᶐᵿᶁᶃᵋᶎᶐᶍᶈᶃᶁᶒᵌᶃᶓᵍᶆᶎᶁᵋᵿᶁᶁᶃᶑᶑᵍᶎᵿᶅᶃᵋᵏᵏᵍᲯɭမႎễѣӼểẲềఋᗡӳỊᵦᵮᵡ᧏ႆửཏࡽẴỦ᣻ᙲễЎ᣼ểễẾềẟỦ

཯ᇌᘍ૎ඥʴ҄ễỤỎỆʚඥʴወӳỆợỦἋὊἣὊἅὅἦἷὊἑ᝻เỉૢྸὉወӳᚘምᩔᙲѣӼểἋὊἣὊἅὅἦἷὊἑૢͳ
૾ᤆૼἋὊἣὊἅὅἦἷὊἑỉನ঺ૼἋὊἣὊἅὅἦἷὊἑỉМဇཞඞ‫ٻف‬ẴỦᚘምᩔᙲồỉ‫ࣖݣ‬

17

Japan Atomic Energy Agency

18

Japan Atomic Energy Agency཯ᇌᘍ૎ඥʴ҄ễỤỎỆʚඥʴወӳỆợỦᲫἋὊἣὊἅὅἦἷὊἑ᝻เỉૢྸὉወӳҾᅹᄂᵴᵮᵮᵓᵎᵎᵎ
ᵴᵮᵮᵓᵎᵎᵎ

᢯ྣᄂᵭᶐᶇᶅᶇᶌᵑᵖᵎᵎ

ᵦᵏᵔ࠰ࡇ

ᵦᵏᵕ࠰ࡇ

ᵦᵏᵖ࠰ࡇ

ᵦᵏᵗ࠰ࡇ

ᵦᵐᵏ࠰ࡇ

ᚘምᩔᙲѣӼểἋὊἣὊἅὅἦἷὊἑૢͳ૾ᤆ
ᚘምᩔᙲѣӼ

ᵦᵐᵐ࠰ࡇ῍ೞನᚘምᩔᙲ
ഏɭˊίᵦᵏᵎᵊᵏᵓᵊᵏᵖᛦ௹ኽௐὸ ἋἣἅὅᵠᵶᵗᵎᵎᵟᶊᶒᶇᶖᵑᵕᵎᵎᵠᶖᵐወӳὉӳྸ҄

ᵧᵲᵠᵪᚘምೞᵮᵰᵧᵫᵣᵮᵭᵵᵣᵰ

᧙ᙱᄂ

ᵦᵐᵎ࠰ࡇ

Წ

ή᣽‫܇‬ἉἱἷἾὊἉἹὅ‫ݦ‬ဇᚘምೞίᵟᶊᶎᶆᵿᵱᶃᶐᶔᶃᶐὸ

‫ٻ‬ඹᄂɭမᵬᶍᵌᵏࣱᏡೞࡑഥᵦᵮᵡᵐᵓᵎᵎ

ወӳὉӳྸ҄

BX900
250[TFLOPS]

200
150
100
50
0

BX900

Ҿ‫܇‬щೞನỂỊẆҾᅹᄂẆ᢯ྣᄂẆ᧙ᙱᄂӏỎ‫ٻ‬ඹᄂỉᾃ‫ע‬ғỂἋἣἅὅửᢃဇ

200

Altix3700Bx2
HPC2500
AlphaServer
PRIMEPOWER
Origin3800
VPP5000
6.4
H16ᐕᐲ

18.2

18.2

15.5

15.5

15.5

H17ᐕᐲ

H18ᐕᐲ

H19ᐕᐲ

H20ᐕᐲ

H21ᐕᐲ H22ᐕᐲ䌾• ࠯঺ᵏᵔ࠰ࡇ஛ỆҾᅹᄂể᢯ྣᄂửወӳẇ• ࠯঺ᵏᵖ࠰ࡇ஛ỆỊඥ‫ܭ‬᎑ဇ࠰ૠửኺᢅẲẺ᧙ᙱᄂỉἉἋἘἲửࡑഥẇ• ࠯঺ᵐᵏ࠰ࡇ஛ỆҾᅹᄂể‫ٻ‬ඹᄂί଒ᵨᵬᵡὸửወӳẆҾ‫܇‬щೞನỆấẬỦ՗ɟỉἉἋἘἲẇ• ወӳὉӳྸ҄ᚘဒử‫ܦ‬ʕẇ Ҿ‫܇‬щ↝ᚘምᩔᙲ↞ਘ‫↝ٻ‬ɟᡦ ᚘምೞ᝻เ↝ௗญ↞ขЦ↙ཞඞ ⇟∞⇷∞⇙∙⇺∋∞⇥ૢͳ૾ᤆℲ ଒≕ඥʴ↝⇟∞⇷∞⇙∙⇺∋∞⇥⇁ወӳ∝ӳྸ҄ↆ⅚↷↹⇙⇟⇮⇷⇻⇏∞
BX900∄∙⇟↝᭗ⅳૼ⇝⇟⇬∆↧୼ૼ
FX1ℳ ʮ⇙∙⇺∋∞⇥⇁෇ဇↈ↺↎↰↝࿢‫ͳૢؾ‬

19

Japan Atomic Energy AgencyᲭೞನᚘምೞᙹ೉

200TFLOPS

20

Japan Atomic Energy AgencyૼἋὊἣὊἅὅἦὊἑỉನ঺ᾕᾧᵏᵮᵰᵧᵫᵣᵰᵥᵷᴾᵠᵶᵗᵎᵎᵏᵐᵲᵤᵪᵭᵮᵱᵍᵑᵎᵎἠὊἛίᵏᵊᵐᵎᵎἅỴὸᵍᵒᵌᵔᵲᵠᴾᶋᶃᶋᶍᶐᶗ

ᵐᵎᵎᵲᵤᵪᵭᵮᵱᵍᵐᵊᵏᵑᵒἠὊἛίᵏᵕᵊᵎᵕᵐἅỴὸᵍᵓᵎᵲᵠᴾᶋᶃᶋᶍᶐᶗ

ഏɭˊἅὊἛ᧏ႆᢿ

‫ᙹٻ‬೉ɳЗ๫ምᢿᵟᶎᶎᶊᶇᶁᵿᶒᶇᶍᶌᴾᵢᶃᶔᶃᶊᶍᶎᶋᶃᶌᶒᴾᵳᶌᶇᶒᴾᶄᶍᶐᴾᶒᶆᶃᴾᵥᶃᶌᶃᶐᵿᶒᶇᶍᶌᴾᵱᶓᶎᶃᶐᶁᶍᶋᶎᶓᶒᶃᶐ

ᵪᵟᵬᵪᵿᶐᶅᶃᵋᶑᶁᵿᶊᶃᴾᵮᵿᶐᵿᶊᶊᶃᶊᴾᵡᶍᶋᶎᶓᶒᶃᶐᴾᵳᶌᶇᶒᵥᶇᶅᵿᶀᶇᶒᴾᵣᶒᶆᶃᶐᶌᶃᶒ

ᵧᶌᶄᶇᶌᶇᵠᵿᶌᶂᄬൢἙỵἋἁᘺፗ
ᵢᶇᶑᶉᴾᵱᶒᶍᶐᵿᶅᶃ

ᄬൢἘὊἩἻỶἨἻἼᘺፗ

σஊἳἴἼ‫׹‬๫ምἇὊἢ

ᄬൢἙỵἋἁᘺፗ

ᵲᵿᶎᶃᴾᵱᶒᶍᶐᵿᶅᶃ

ᵱᵫᵮᴾᵱᶃᶐᶔᶃᶐ

ᵢᶇᶑᶉᴾᵱᶒᶍᶐᵿᶅᶃ

ᵣᵲᵣᵰᵬᵳᵱᴾᵢᵶᵖᵎᵆᶣᵑᵔᵇ ᵣᵲᵣᵰᵬᵳᵱᴾᵪᵲᵐᵕᵎᵆᶣᵐᵇ
ᵏᵌᵐᵮᵠ
ᵏᵮᵠ

ᵱᵮᵟᵰᵡᴾᵣᶌᶒᶃᶐᶎᶐᶇᶑᶃᴾᵫᵗᵎᵎᵎᵏᵌᵗᵲᵤᵪᵭᵮᵱᵍ ᵏἠὊἛίᵏᵗᵐἅỴὸ ᵍᵑᵖᵒᵥᵠᴾᶋᶃᶋᶍᶐᶗ

ᵣᵲᵣᵰᵬᵳᵱᴾᵒᵎᵎᵎᵫᶍᶂᶃᶊᴾᵔᵎᵎ

ᵐᵓᵲᵠ

21

Japan Atomic Energy Agency

22

Japan Atomic Energy Agency

23

Japan Atomic Energy Agency

24

Japan Atomic Energy Agencyὼ ᵪᶇᶌᶎᵿᶁᾺ ἫὅἓἰὊἁἘἋἚ ὼ‾⁛⁠⁢⁓⁕⁝ࣱᏡ

⇺∞⇕ࣱᏡ

BX900

191.40

200.1

95.66

13.40

2,401,344

FX1

11.66

12.9

90.37

5.68

709,632⁍⁆‸‾⁁⁂⁅⁏јྙ⁍⁆‸‾⁁⁂⁅⁏

ܱᘍ଺᧓

⁍‗⁏

⁍⁚⁏

ૼἋὊἣὊἅὅἦἷὊἑỉМဇཞඞᲮ䋭 BX900 䋭բ᫆ᙹ೉Ὁ ᢃဇ᧏‫ڼ‬ᵑଐႸίᵑஉᵑଐὸỆẲềẆᵗᵎᵃỉМဇྙửᢋ঺Ὁ ᡵ൑ỉਖ਼ᆆờᵒஉˌᨀᵗᵎήˌɥỉཞ७ầዒዓ

⁍Ψ⁏

98%

100%

90%

90%

87%

91%

91%

90%

92%

92%

94%
90%

84%

92%

94%

92%

95%

94%

95%

90%

80%

93%

94%

94%
93%
86%

78%
75%

70%

ᵧᶌᶄᶇᶌᶇᵠᵿᶌᶂᡫ̮ኺែ
Џஆ‫ٶ‬ႆᨦܹ

60%

ίᵲᶍᶎᵓᵎᵎᴾᵐᵎᵏᵎᵌᵔὸ৑ϋɟ૪ͣᩓ

ᵱᵣ̬‫˺ܣ‬ಅᵱᵣ̬‫ܣ‬
˺ಅᵱᵣὉᵡᵣ
̬‫˺ܣ‬ಅ

40%

191.4

ἍὅἑὊίࣱᏡᚸ̖ὸ
Ὁᵱᵣ̬‫˺ܣ‬ಅ

51%

50%

30%

122.4

ᵮᵿᶐᵿᶊᶊᶃᶊᶌᵿᶔᶇ
ᨦܹ

74%

68%

70%

ᵠᵶᵗᵎᵎỉᵪᶇᶌᶎᵿᶁᶉࣱᏡỊẆ‫׎‬ϋᵏˮίܱᘍјྙᵏˮὸ ẆɭမᵐᵐˮίܱᘍјྙᵐˮὸҾ‫܇‬щೞನ
‫ྶע‬ἉἱἷἾὊἑ
‫ܬܢ‬ᑋᆰᄂᆮ᧏ႆೞನ
ிʮ‫ܖٻ‬ίᵲᵐᵩὸྸ҄‫ܖ‬ᄂᆮ৑
ிʮ߻ಅ‫ܖٻ‬ሇඬ‫ܖٻ‬
ఋᗡӳᅹ‫ܖ‬ᄂᆮ৑ிʮ‫ܖٻ‬ίᵦᵥᵡὸ

91%

87%

81%

29%

20%

110.6

䉮䉝೑↪₸
Ⓙേ₸

10%

101.7

᭗ẟᚘምᩔᙲ

97.9
87.0

0%

77.3
56.6
54.2
0

100

200

‾⁛⁠⁢⁓⁕⁝‒ܱјࣱᏡൔ᠋ ⁍⁆‸‾⁁⁂⁅⁏ ≋‣••ˮˌϋ≌25

Ὁ ἉἋἘἲМဇỆ‫ݣ‬ẴỦΪܱẲẺἇἯὊἚ˳СầᄩᇌẰủềẟỦίἸὊἈἩἿἂ
Ἳἲỉஇᢘ҄ἓἷὊἝὅἂẆἩἿἂἻἲᆆౡẆᜒ፼˟᧏͵ẆМဇႻᛩ˳СὸὉ ଒ἉἋἘἲ଺ˊẦỤɼᙲἅὊἛỉ᭗ɳЗ҄Ὁஇᢘ҄ầᡶỮỂẟỦὉ ᭗ɳЗἋὊἣὊἅὅἦἷὊἑử̅ạᏡщửஊẴỦᄂᆮᎍầૠ‫ٶ‬ẪᏋẾềẟỦJapan Atomic Energy Agencyὼ Ҿ‫܇‬щೞನỉἋὊἣὊἅὅἦἷὊἑМဇૅੲ˳С ὼМဇᎍૅੲί‫ᧉݦ‬ἋἑἕἧỆợỦಅѦᛪ᝟ὸὼ ‫׎‬ϋೞ᧙ỉἋὊἣὊἅὅἦἷὊἑМဇૅੲ˳С ὼҾ‫܇‬щೞನ

ᜒ፼˟ὉἍἱἜὊ
ίМဇ২ᘐỉἾἫἽỴἕἩὸἩἿἂἻἲỉஇᢘ҄ί᭗ᡮ҄ὸởМဇႻᛩ‫ࣖݣ‬ễỄẆΪܱẲẺМဇૅੲ˳СỉɦẆᄂᆮᎍỉἇἯὊἚểᚘምೞ᝻เỉஊјМဇ

ೞ᧙

МဇႻᛩ

ἩἿἂἻἲஇᢘ҄ἩἿἂἻἲ˺঺

ᵨᵟᵣᵟ

Ṽ

Ṽ

Ṽ

ί ὸϋỊᙲՃૠ

ᵟೞ᧙

Ṽ

ᵠೞ᧙

Ṽ

ᵡೞ᧙

Ṽ

Ṽ

Ṽ

ἩἿἂἻἲஇᢘ҄ỊႻᛩὉἓἷὊἝὅἂૅੲἾἫἽ

ᵢೞ᧙

Ṽ

Ṽ

ᵣೞ᧙

Ṽ

ᵆᵓᵇ

ᵤೞ᧙

Ṽ

ᵥೞ᧙

Ṽ

ᵦೞ᧙

Ṽ

ᵆᵕᵇ

ᵆᵔᵇ

ͳᎋ

Ṽ

27

28

Japan Atomic Energy AgencyᲯJapan Atomic Energy Agency‫ٻف‬ẴỦᚘምᩔᙲồỉ‫ࣖݣ‬ὼ Мဇᛢ᫆ဎᛪཞඞểᣐЎ ὼ᭗ẟ๼‫נ‬ᚘምᩔᙲ‫׹ٻ‬ᚘምೞ᝻เỉјྙႎὉјௐႎМဇử̟ᡶẴỦẺỜỆẆ࠯঺ᵏᵕ࠰ࡇợụẆẐ‫׹ٻ‬ᚘምೞМဇ‫ۀ‬Ճ˟ẑửᚨፗẲẆ‫ᙹٻ‬೉Мဇᛢ᫆ửᚸ̖Ẇᚘም଺᧓ửᣐЎ‫ݣ‬ᝋᚘምೞ
ᛢ᫆ဎᛪவˑ

ᵠᵶᵗᵎᵎᴾί᝻เỉኖᵗᵎήử১ᛐᛢ᫆ỆᣐЎὸᚘምἅὊἛỉܱᘍјྙẆɳЗ҄јྙṟẐᄂᆮ঺ௐỉ஖ࢳࡇẑẆẐ࣏ᙲࣱӏỎዬࣱ࣯ỉᆉࡇẑẆẐᚘም଺᧓ᚨ‫ܭ‬ỉ‫ࣱ࢘ڲ‬ẑỉᵑ᪮ႸỆếẟề‫ۀ‬Ճ˟ỆợỦᵓെ᨞ᚸ̖

ṠὉᚘምೞᏡщỉᵏᵌᵓ̿ửឬảỦᛢ᫆ဎᛪὉૼἉἋἘἲỉ๫ምࣱᏡỊẆ଒ἉἋἘἲỉኖᵏᵒ̿ể᫠៫ႎỆӼɥẲẺầẆӲἸὊἈỉᚘምᙹ೉ờ‫ࠢٻ‬Ệਘ‫ٻ‬ίᵦᵐᵐ࠰ࡇὸ࠰᧓ ᵐᵓᵎᵊᵎᵎᵎἅỴ଺᧓ឬẆộẺỊᵐᵓᵔɳЗឬ

Ṟ
ᚸ ̖

26

Japan Atomic Energy Agency࠰ࡇ஛ỆМဇኽௐẐࢽỤủẺ঺ௐỉ᣻ᙲࡇẆᢋ঺ࡇӏỎᝲဇίᵡᵮᵳ଺᧓ὸ‫ݣ‬јௐẑỆếẟề‫ۀ‬Ճ˟ỆợỦᵓെ᨞ᚸ̖ẇഏ࠰ࡇồỉዒዓᛢ᫆ỆếẟềỊẆẮỉኽௐửഏ࠰ࡇᚸ̖ỆӒପ
29

Japan Atomic Energy Agency

30

Japan Atomic Energy AgencyὼҾ‫܇‬щೞನỆấẬỦᚘምᅹ‫ܖ‬ửἼὊἛẴỦᄂᆮᢿᧉὼ

ఋ⇛ᄂ„‣‥Ӹ„‒…‗Ҿᅹᄂ„‫‫‬Ӹ„‒․‗έᇢؕᄽ„ ‫ޖע‬ϼЎ„‒‫‫‬Ӹ„‒‥‗ؕᄽ߻„‒․Ӹ„‒‣‗…„…‣‧Ҙ଺᧓„‒

↌↝˂„‒
Ӹ„‒․‗

‫ܤ‬μࣱᄂᆮ„‒‣‫‫‬Ӹ„‒‧‗

ఋᗡӳ„

…‗

ᚘምᅹ‫‒„ܖ‬․Ӹ„‒․•‗᣽‫‒„∆∞⇹܇‬․…Ӹ„‒ ‗ഏɭˊ„‒․„••‫‫‬Ҙ଺᧓„‒

‫‗‫‬

ఋᗡӳ„‒

‫‥„‫‬‪•Ҙ଺᧓„‣‫„‫‬‪••Ҙ଺᧓„‒

‣‫‗‫‬

ؕᄽ߻„
ᚘምᅹ‫‒„ܖ‬‫ٻ‬ඹᄂ„‥‣Ӹ„‒‫‗‫‬․…Ӹ„‒ ‗Ძ…•‗‣Ӹ„‒‣ ‗Ҿ‫܇‬щἩἿἂἻἲỉཎࣉഏɭˊ„‒‧‧Ӹ„‒‣ ‗᣽‫‒„∆∞⇹܇‬‼‟⁂″⁄‵„‒‣…„․ ‥Ҙ଺᧓„‒․‧Ӹ„‒ ‗Წ․‪‗ዮᚘᵘᵑᵓᵏӸఋἇᄂᾉἩἽἚἝỸἲ༓૰২ᘐ᧏ႆἍὅἑὊẆἇỶἁἽ߻‫ܖ‬ᚾ᬴ᢿሁ‫ٻ‬ඹᄂᾉༀ‫ݧ‬ᚾ᬴໐ἍὅἑὊẆ᭗ภ߻‫ܖ‬ᚾ᬴ᄂᆮ໐ᢿሁ
Ҿᅹᄂᾉ‫ܤ‬μᚾ᬴଀ᚨሥྸᢿẆᄂᆮ໐ьᡮ֥ሥྸᢿሁ
ᚘምᅹ‫ܖ‬ᾉἉἋἘἲᢃ᠃ӏỎМဇૅੲࢼʙᎍửᨊẪᵐᵎᵏᵎᵌᵖᵌᵑᵏᴾྵ‫נ‬ૼἋὊἣὊἅὅἦἷὊἑỉؕஜࣱᏡ Ḥᵵᶃᶀਫ਼᠍᝻૰ẦỤỊЪᨊ

31

Japan Atomic Energy Agency

Japan Atomic Energy AgencyҾ‫܇‬щἩἿἂἻἲỉཎࣉ

Ძ

‫ݣ‬ᝋ

৖ඥ

ɳЗ҄

ཎࣉ

ᵥᵲᵓᵢ

ἅὊἛ

ἩἻἌἰʏ්

ࠀЎඥ
ஊᨂᙲእඥ
ᵤᵤᵲ

ᵦᶗᶀᶐᶇᶂ

᭗๫ምјྙίἳἴἼỴἁἍἋầἮἚἽ἟ἕἁὸ

ᵬᵭᵮᵧᵡἾὊἈὊˡછ

ࠀЎඥᵤᶊᵿᶒᵫᵮᵧᵏ‫ݣ‬ᵏᡫ̮ίᶃᶖᶁᶆᵿᶌᶅᶃὸ

ᶃᶖᵿᶁᶒᵋᶂᶇᵿᶅ ‫˳׍‬ɶỉᩓ‫܇‬‫׍‬ஊ͌բ᫆
ίᵡᵥὸ

ᵦᶗᶀᶐᶇᶂ

ᨼ‫ׇ‬ᡫ̮ίᶑᶁᵿᶒᶒᶃᶐὸ

ᵲᵮᵤᵧᵲ‫ן‬጑්ࣱ˳

ᘍЗᚐඥίᵧᵪᵳᵡᵥᵱὸᵤᶊᵿᶒᵫᵮᵧ˯ỿἵἕἉἷἤἕἚྙ
ίἳἴἼỴἁἍἋầἮἚἽ἟ἕἁὸᵟᵯᵳᵟ᩼‫ן‬጑්ࣱ˳

ࠀЎඥίᵧᵡᵡᵥὸ

ᵭᶎᶃᶌᵫᵮ

ίσஊἳἴἼ‫׹‬ὸᲫᵥᵲᵓᵢἅὊἛ

ᲬἡỶἨἼἕἛɳЗ҄ᲭᵤᵶᵏửဇẟẺࣱᏡʖยᲮᵏᵮᵤᵪᵭᵮᵱộỂỉἋἃὊἻἥἼἘỵ๫ምࣱᏡẆἳἴἼἢὅἛࠢӏỎᡫ̮ἢὅἛࠢỉἢἻὅἋỉểủẺᚘምೞầ࣏ᙲ

34

Japan Atomic Energy AgencyᲫJapan Atomic Energy Agency

ὼᵥᵲᵓᵢἅὊἛỉࠀЎ๫ምỽὊ἟Ἵỉ๫ምࣱᏡൔ᠋ὼ

ᵥᵲᵓᵢᵘᴾఋᗡӳἩἻἌἰʏ්ἉἱἷἾὊἉἹὅἅὊἛᵈ
ᵈᴾᵧᶂᶍᶋᶓᶐᵿ ᶃᶒᴾᵿᶊᵌᵊᵡᶍᶋᶎᶓᶒᵌᴾᵮᶆᶗᶑᵌ ᵡᶍᶋᶋᶓᶌᵌᵆᵐᵎᵎᵖᵇᚘምἅὊἛӸᾉᵥᵲᵓᵢಒ ᙲఋᗡӳἩἻἌἰʏ්ỉᇹɟҾྸἴἙἽỂẝỦᵓഏΨἊἵỶἿᢃѣᛯἴἙἽỉႺ੗ૠ͌ἉἱἷἾὊἉἹὅửᘍẟẆఋᗡӳ໐ࣱ࣎Ꮱửᚸ̖ẴỦẇỴἽἆἼἌἲ

4ᰴర⒖ᵹ㗄䈱䋴ᰴ♖ᐲ᫪⷏Ꮕಽ䉦䊷䊈䊦䇮㈩೉䉰䉟䉵䋺48x80x64x100=200MB
䊶
䊶
䊶

vA

 ᵓഏΨˮႻᆰ᧓ỉᆆ්Ὁਘ૝
໯૝᡹Ὁ̬‫ࠀ׹܍‬ЎἋỿὊἲ ଺᧓ᆢЎ
ҞᨏႎἽὅἄὉἁἕἑඥ ἡỶἨἼἕἛɳЗ
ᵫᵮᵧᶣᵆᐯѣɳЗ҄ᵉᵭᶎᶃᶌᵫᵮᵇ

Altix3700Bx2
BX900
FX1

Itanium2 (6.4GF/core,L3=6MB,B/F=0.5)
NehalemEP (11.72GF/core,L3=8MB,B/F=0.5)
SPARC64VII (10GF/core,L2=6MB,B/F=1)

1or2䉮䉝૶↪
1or8䉮䉝૶↪
1or4䉮䉝૶↪

asis
asis
FX1↪ᦨㆡൻ

⇊∙⇬∑‸⁡⁤⁦⁤⁓⁠≝‟⁁‥‒‚‟⁡⁢⁗⁠ ⁢‛„‒‫ܦ‬μ⁁⁢⁗⁠‿⁂݈ٟ҄ᡫ‸⁡⁤⁦⁤⁓⁠≝‟‽⁘⁓⁥⁦‒㡟‽⁡⁕⁞‒㡟⁪․••‒⁍㡟‽ ⁘⁧⁠⁕ ․„‒‟‽⁢⁤⁗⁘⁗⁦⁕⁚⁑⁕⁓⁕⁚⁗⁑⁞⁗⁨⁗⁞ ‣⁏‒‚‟‽⁢⁓⁤⁓⁞⁞⁗⁞„⁁‿⁂‛„‒ᐯѣɳ
З҄”⁁⁢⁗⁠‿⁂҄⅚
⁍‒⁏‒‬‸⁊‣ဇ⇐⇽⇝∍∙⅚‚‛‬⁅‿⁂⇐⇽⇝∍∙⃸‿⁂※↞ᡫ̮↙ↆ↝⁗ ⁔⁓⁤⁤⁓⁥⁥⁛⁠⁙⁞⁫‒⁢⁓⁤⁓⁞⁞⁗⁞↖⇴∞⇯≋∇∈∐⇷⇟≌⇁؈↰↎ᚘምv//zἅỴ๫ምࣱᏡểἳἴἼἢὅἛࠢỉᵥᵲᵓᵢỽὊ἟ἽϼྸࣱᏡồỉࢨ᪪

vA
y
x

v//

ᵓഏΨˮႻᆰ᧓ίᡮࡇᵐഏΨὸỉઅѣቩ‫܇‬Ўࠋʻࢸỉᚘဒ ᐮမἩἻἌἰᚾ᬴ᘺፗᵨᵲᵋᵔᵎᵳሁỉ᬴ܱἙὊἑỆ‫ݣ‬ẴỦܱᚰᚐௌửܱ଀ẲẆ໐ࣱ࣎Ꮱᚸ̖ỉᄩࡇửӼɥẇ
ᾀἬἑἧἿἕἩἋᚘም ίբ᫆ἇỶἌᾉ 240ᶣ240ᶣ256ᶣ128ᶣ32ὸ ‫׎‬ᨥ༏ఋᗡӳ᬴ܱ໐ᵧᵲᵣᵰỉ໐ࣱ࣎ᏡỉʖยởૼẺễᢃ᠃৖ඥỉ᧏ႆỆ෇ဇẇ ఋᗡӳҾ‫׹‬໐ỉ᧏ႆỆấẟềẆܱೞᚾ᬴ầ‫׉‬ᩊễఋᗡӳ໐࣎ỉᚨᚘૅੲỆ෇ဇẇἠὊἛẝẺụᵏἅỴỂỊᵧᶒᵿᶌᶇᶓᶋᵐᵊᵬᶃᶆᵿᶊᶃᶋᵋᵣᵮầᵑᵎᵃᆉࡇỉܱјࣱᏡἠὊἛầ؈ộẾẺཞ७ỂỊᵏᵓᵃᆉࡇộỂܱᘍࣱᏡầ˯ɦ

35

Japan Atomic Energy Agency

36

Japan Atomic Energy Agencyὼ ᵦᶗᶀᶐᶇᶂᴾɳЗ ὼὼᵥᵲᵓᵢἅὊἛỉࠀЎ๫ምỽὊ἟Ἵỉ๫ምࣱᏡൔ᠋ὼ
ᵥᵲᵓᵢỆợỦἡỶἨἼἕἛϼྸࣱᏡἫὅἓἰὊἁ ἋἾἕἛɳЗỆợỦἳἴἼ̅ဇ᣽ỉ‫ࠢٻ‬ễЪถ ᵫᵮᵧἩἿἍἋ᧓ᡫ̮᣽ỉถ‫ݲ‬ỆợỦμ˳ϼྸࣱᏡỉ᭗ᡮ҄բ᫆ἇỶἌᾉ ᵐᵒᵎᶖᵐᵒᵎᶖᵑᵐᶖᵏᵐᵖᶖᵑᵐᵠᵶᵗᵎᵎᵘᵬᶃᶆᵿᶊᶃᶋᵋᵣᵮᵆᵏᵏᵌᵕᵐᵥᵤᵍᶁᶍᶐᶃᵊᵪᵑᵛᵖᵫᵠᵊᵠᵍᵤᵛᵎᵌᵓᵇᵊᵒᵎᵗᵔἅỴ̅ဇỶὅἘἽᵤᶍᶐᶒᶐᵿᶌᾉᵋᵭᵑᵊᴾἧἻἕἚᵫᵮᵧᵆἅὊἛμ˳ỉ‫ܦ‬μᵭᶎᶃᶌᵫᵮ҄Ịச‫ࣖݣ‬ᵇ݈ٟᡫᵤᶍᶐᶒᶐᵿᶌᾉᵋᵩᶄᵿᶑᶒᴾ㘝ᵩᶍᶁᶊᴾ㘝ᶖᵐᵎᵎᴾᵋᵩᶎᵿᶐᵿᶊᶊᶃᶊᵊᵭᵫᵮᵊᴾἡỶἨἼἕἛɳЗᵆᵫᵮᵧᵊᐯѣɳЗ҄ᵊᵭᶎᶃᶌᵫᵮᵇ

BX900
FujitsuSMP1

μ˳ᵍᶑᶒᶃᶎᴾᵆᶋᶑᶃᶁᵇ

10231.35

10397.27

ᡫ̮ᵍᶑᶒᶃᶎᴾᵆᶋᶑᶃᶁᵇ

2414.72ἳἴἼ̅ဇ᣽ᵆᵥᵠᵇܱјࣱᏡᵆᵥᶄᶊᶍᶎᶑᵇ

16

BX900
FujitsuSMP8

2608.57

BX900
FujitsuSMP4
9286.57
1516.63

3641.14

3754.09

1545.49

1249.91

4979.06

4899.60

5485.61

4661.37

81533.82 ἡỶἨἼἕἛɳЗỆợỦἳἴἼἅἋἚỉ‫ࠢٻ‬ễЪถầӧᏡ¾ᵤᶊᵿᶒᵫᵮᵧ ᵦᶗᶀᶐᶇᶂᴾ
ᵆᵏᵓᵑᵔᵎᵇ ᵆᵑᵖᵒᵎᶣᵒᵇ

10928.65
ᡮࡇӼɥ

BX900
IntelSMP1

4

2

ἫὅἓἰὊἁἃὊἋỂỊ᪸؏Ўлᘨ᪸؏ởἧỵὊἽἛἏἽἢ๫ም‫܇‬ἾἩἼỽỉЪถỆợẾềᵖᵱᵫᵮỂኖᵏᵍᵑộỂἳἴἼ̅ဇ᣽ửЪถ ᵫᵮᵧᡫ̮ἅἋἚỉถ‫ݲ‬ỆợỦμ˳ϼྸࣱᏡỉ᭗ᡮ҄ ᵠᵶᵗᵎᵎỂỊᵒᵱᵫᵮỂஇ‫ࣱٻ‬Ꮱầ஖ࢳỂẨỦ ݈ٟᡫᵤᶍᶐᶒᶐᵿᶌỉᐯѣɳЗ҄ỊẦễụỉᢿЎỂஊј

1
1024

2048

4096
ἅỴૠ

8192

16384

ኺᢅ଺᧓
ᵍᵏᵎᶑᶒᶃᶎᴾᵆᅺᵇ

188.3

75.0

ϋẆᡫ̮଺᧓
ᵆᅺᵇ

145.0

34.7

ἳἴἼ̅ဇ᣽
ᵆᵲᵠᵇ

15.0

4.7

݈ٟᡫᵤᶍᶐᶒᶐᵿᶌỉᐯѣɳЗ҄ỊẦễụỉᢿЎỂஊј

37

38

Japan Atomic Energy Agency

Japan Atomic Energy Agency

ὼᵥᵲᵓᵢἅὊἛỉɳЗϼྸࣱᏡỉᶑᶒᶐᶍᶌᶅἋἃὊἼὅἂὼ

ᲭࣱᏡʖยὼᵤᵶᵏẦỤʮồᾉᵒᵎᵗᵔɳЗίᵓᵎᵎᵲᵤᶊᶍᶎᶑὸỉ‫ئ‬ӳὼ๫ም଺᧓ỉਖ਼‫ܭ‬ բ᫆ửᵏἩἿἍἋẝẺụỉᙹ೉ử̬ẾẺộộẆᵒᵎᵗᵔἩἿἍἋɳЗẦỤᵐᵓᵔἩἿἍἋɳЗỆἋἃὊἽἒỸὅίᶕᶃᵿᶉ ᶑᶁᵿᶊᶇᶌᶅὸ

ܱјࣱᏡ`6( 

 ᵤᵶᵏỉᵐᵓᵔᵡᵮᵳίᵏᵎᵐᵒἅỴὸửဇẟềἩἿἧỳỶἼὅἂẇ㪧㫆㫊㫋㪄㪝㪯㪈㩷㪚㪸㫃㪺㪅㪈㪋㪇㪋㫀㫅㫊㫋㪄㪺㫆㫄㫄㫀㫋㫋㪼㪻㪉㪆㪊㫀㫅㫊㫋㪄㪺㫆㫄㫄㫀㫋㫋㪼㪻㪈㪉㪇ᡫ̮଺᧓ỉਖ਼‫ܭ‬㪽㫃㫆㪸㫋㪄㫉㪼㪾㫀㫊㫋㪼㫉㪄㫎㪸㫀㫋㫀㫅㫋㪼㪾㪼㫉㪄㫉㪼㪾㫀㫊㫋㪼㫉㪄㫎㪸㫀㫋㪈㪇㪇 ᡫ̮ỉᆔ᫏ύἙὊἑᧈύᡫ
̮‫ׅ‬ૠửᛦ௹ẇ ỶὅἑὊἅ἟ἁἚỉˁಮίἚἯἿἊὊửˎ‫ܭ‬ὸử ờểỆதɥᚘምỆợụਖ਼‫ܭ‬ẇ㪫㫀㫄㪼㪲㫊㪼㪺㪴$:`6( 
54M`6( (:`6( 
#NVKZ`6( 
6-`6( $)2`6(  ‫٭‬੭ᘙửဇẟề๫ም଺᧓ửਖ਼‫ܭ‬ẇ㪈㫀㫅㫊㫋㪄㪺㫆㫄㫄㫀㫋㫋㪼㪻㫆㫋㪿㪼㫉㪄㫎㪸㫀㫋㪏㪇㫌㪦㪧㪄㪺㫆㫄㫄㫀㫋㫋㪼㪻㪽㪼㫋㪺㪿㪄㫎㪸㫀㫋㪍㪇㪹㫉㪸㫅㪺㪿㪄㫎㪸㫀㫋㪽㫃㫆㪸㫋㪄㫀㫅㫊㫋㪄㫎㪸㫀㫋㪋㪇㪉㪇㫀㫅㫋㪼㪾㪼㫉㪄㫀㫅㫊㫋㪄㫎㪸㫀㫋໧㗴䉰䉟䉵:240x240x128x128x32㪝㪯㪈ᩰሶᢙ 䋺 240x240x64x100x32(Altix,T2K),240x240x64x128x32(BX900,FX1,SR16k,BG/P)
BX900

NehalemEP (11.72GF/core,L38MB)

InfinibandQDR (8GB/s)⇵⇊⇼∐⇩⇯ɳЗ…⁅‿⁂∝

SR16000

POWER6 (18.8GF/core,L332MB)

InfinibandDDR (32GB/s)⇵⇊⇼∐⇩⇯ɳЗ…⁅‿⁂‚⁅‿⁆‛

∝

FX1

∝

Altix3700Bx2

Itanium2 (6.4GF/core,L36MB)∝

T2K(HA8000)

Opteron (9.2GF/core,L32MB)∝

BlueGene/P

PowerPC450 (3.4GF/core,L38MB)

InfinibandD (2GB/s)⇵⇊⇼∐⇩⇯ɳЗ༿…⁅‿⁂

NUMAlink (3.2GB/s)⇻∏⇩⇮‿⁂※

Myrinet10G (5GB/s)
BG/PNetwork (5.1GB/s)㫀㫅㫋㪼㪾㪼㫉㪄㪣㪈㫄㫀㫊㫊㪄㫎㪸㫀㫋㪩㪠㪢㪜㪥㫊㫋㫆㫉㪼㪄㫎㪸㫀㫋㪽㫃㫆㪸㫋㫀㫅㪾㪄㪣㪉㫄㫀㫊㫊㪄㫎㪸㫀㫋㫀㫅㫋㪼㪾㪼㫉㪄㪣㪉㫄㫀㫊㫊㪄㫎㪸㫀㫋∝

SPARC64VII (10GF/core,L26MB)

㪽㫃㫆㪸㫋㪄㪣㪈㫄㫀㫊㫊㪄㫎㪸㫀㫋㫀㫆㪄㫎㪸㫀㫋

㪇⇵⇊⇼∐⇩⇯ɳЗ…⁅‿⁂⇻∏⇩⇮‿⁂※

39

Japan Atomic Energy AgencyḮώộ ể ỜᾀᵮᵤᵪᵭᵮᵱộỂỉἋἃὊἻἥἼἘỵᲮᵏᵮᵤᶊᶍᶎᶑỆấẟềờᑣẟɳЗࣱ҄ᏡίἋἃὊἻἥἼἘỵὸầᙸᡂộủỦҾ‫܇‬щᄂᆮ᧏ႆửᡶỜỦɥỂẆᚘምᅹ‫ܖ‬২ᘐỉᆢಊႎ෇ဇỊ࣏᪰Ҿ‫܇‬щೞನỂỊẆଏỆ࠰᧓ỉᛯ૨ૠỉᾁ὿ήˌɥầᚘምᅹ‫ܖ‬২ᘐửဇẟẺᄂᆮỆἉἧἚᚘምೞ᝻เỉɧឱỊขЦỂẝụẆɟᄂᆮ৑ỂแͳỂẨỦ᝻เ᣽ửឬᢅʮἅὅἦἷὊἑỉᆢಊႎМဇầɧӧഎᵤᵶᾀửဇẟẺʮἅὅἦἷὊἑဇἓἷὊἝὅἂỊಊỜềஊјҾ‫܇‬щἅὊἛỆếẟềẆᾀᵮᵤᶊᶍᶎᶑộỂỉᑣ‫ڤ‬ễἋἃὊἻἥἼἘỵửᄩᛐ

16

ᵡᵮᵳ
ૠ

଺᧓ਖ਼‫͌ܭ‬240ᶣ240

512

227.6

ᶣ

ίᅺᵍᵏᵎᶑᶒᶃᶎὸ

64ἋἦὊἛỴἕἩ

8

բ᫆ἇỶἌ

4

2

61.2

ᶣ128ᶣ322048
240ᶣ240ᶣ

225.9

ᶣ128ᶣ32

1
512

256
8192

71.0

1024

(66TFlops)

40Japan Atomic Energy Agency

2048

ᵡᵮᵳૠ

4096

8192
(1PFlops)

41

Japan Atomic Energy Agency

42

Japan Atomic Energy Agencyὼ ᵨᵟᵣᵰᵧὉᵨᵟᵣᵟᴾɼᙲ‫ݰ‬λᚘምೞ ὼ‫ ׎‬ϋ ίᵓᵎᵎᵲᶄᶊᶍᶎᶑˌɥὸ

ഏ஖ᛦᢋᙹ೉

ᵏᵮᵤᶊᶍᶎᶑ

Alpha Serverᵏᵲᵤᶊᶍᶎᶑ

VPP5000ὼɭမỉἋὊἣὊἅὅἦἷὊἑૢͳѣӼί‫ݰ‬λᚘဒὸὼ

BX900

ᾀὸ

Altix3700
HPC2500

SR8000Paragon-MP

VPP500⁂⁗⁤⁘⁡⁤ ⁓⁠⁕⁗

Monte-4ᵐὸ

VP2600ᵏᵥᵤᶊᶍᶎᶑ
VP100
F230-75APU
F230-75ᵏᵫᵤᶊᶍᶎᶑ

ᵑὸ

F230-60
IBM7044ᵏᵫᶇᶎᶑ

IBM650

ᵒὸ

൮ဇೞ
ᵏᵗᵓᵓᴾ

ᵏᵗᵔᵎᴾ

ᵏᵗᵔᵓᴾ

ᵏᵗᵕᵎᴾ

ἋὊἣὊἅὅἦἷὊἑ ίἫἁἚἽ‫׹‬ὉἋỽἻ‫׹‬ὸ
ᵏᵗᵕᵓᴾ

ᵏᵗᵖᵎᴾ

ᵏᵗᵖᵓᴾ

ᵏᵗᵗᵎᴾ

⁋⁗⁓⁤

ᵏᵗᵗᵓᴾ

ᵐᵎᵎᵎᴾ

ᵐᵎᵎᵓᴾ

ᵐᵎᵏᵎᴾ

ʋ߸‫ܖٻ‬

䋱䋩ỶἼἠỶ‫ٻ‬ᵠᶊᶓᶃᵵᵿᶒᶃᶐᶑ

ዮ๫ምࣱᏡᾉᵏ῍ᵏᵎᵮᶄᶊᶍᶎᶑ

ᆙ΁᧏‫ڼ‬ᾉᵐᵎᵏᵏ࠰

ἿὊἾὅἋὉἼἢἴỴᵱᶃᶏᶓᶍᶇᵿ

ᆙ΁᧏‫ڼ‬ᾉᵐᵎᵏᵏ࠰ᵍᵓஉˌᨀிʮ‫ܖٻ‬‫ᙹٻ‬೉ឬɳЗἋὊἣὊἅὅἦἷὊἑὊ
ἉἋἘἲዮ๫ምࣱᏡᾉᵏᵮᶄᶊᶍᶎᶑ

ᆙ΁᧏‫ڼ‬ᾉᵐᵎᵏᵏ࠰ᵍᵏᵎஉˌᨀிʮ߻ಅ‫ܖٻ‬ἁἻỸἛ‫׹‬ἂἼὊὅἋὊἣὊἅὅἦἷὊἑ

5䋩ዮ๫ምࣱᏡᾉᵐᵎᵮᶄᶊᶍᶎᶑ

ᆙ΁᧏‫ڼ‬ᾉᵐᵎᵏᵐ࠰

ዮ๫ምࣱᏡᾉᵐᵌᵒᵮᶄᶊᶍᶎᶑ

ᆙ΁᧏‫ڼ‬ᾉᵐᵎᵏᵎ࠰

6䋩

ᵣᵳ

ᵮᵰᵟᵡᵣ

ዮ๫ምࣱᏡᾉ ᵝᴾᵮᶄᶊᶍᶎᶑ

ᆙ΁᧏‫ڼ‬ᾉᵐᵎᵏᵎ࠰ྸ҄‫ܖ‬ᄂᆮ৑

ʮ

7䋩

ᵣᵳ

ᵧᵲᵣᵰᵋᵠᵟᆙ΁᧏‫ڼ‬ᾉᵐᵎᵏᵐ࠰ᵍᵔ

2䋩

3䋩

4䋩

8䋩

ዮ๫ምࣱᏡᾉᵐᵎᵮᶄᶊᶍᶎᶑ

ᆙ΁᧏‫ڼ‬ᾉᵐᵎᵏᵐ࠰ᵬᵟᵱᵟᵮᶊᶃᶇᵿᶂᶃ

ዮ๫ምࣱᏡᾉᵏᵎᵮᶄᶊᶍᶎᶑ

ᆙ΁᧏‫ڼ‬ᾉᵐᵎᵏᵐ࠰

ἿἋỴἻἴἋ

ᵡᶇᶃᶊᶍዮ๫ምࣱᏡᾉᵏᵮᶄᶊᶍᶎᶑ

ᆙ΁᧏‫ڼ‬ᾉᵐᵎᵏᵎ࠰ἿἋỴἻἴἋ

ᵰᶍᵿᶂᶐᶓᶌᶌᶃᶐᴾᵝዮ๫ምࣱᏡᾉᵏᵮᶄᶊᶍᶎᶑ

ᆙ΁᧏‫ڼ‬ᾉᵐᵎᵏᵐ࠰ɶ‫׎‬ᵬᶃᶀᶓᶊᵿᶃ

ዮ๫ምࣱᏡᾉᵑᵮᶄᶊᶍᶎᶑᴾᵝ

ᆙ΁᧏‫ڼ‬ᾉᵐᵎᵏᵎ࠰

43

Japan Atomic Energy Agency‫ٳ‬ዮ๫ምࣱᏡᾉᵓᵎᵎᵲᶄᶊᶍᶎᶑ

ዮ๫ምࣱᏡᾉᵏᵎᵮᶄᶊᶍᶎᶑ

ᵐᵎᵏᵓᴾ

‫׎‬

ἋὊἣὊἅὅἦἷὊἑ
ἉἋἘἲ

44

Japan Atomic Energy AgencyὼɭမỉἋὊἣὊἅὅἦἷὊἑѣӼίᵲᶍᶎᵓᵎᵎὸὼɶ ‫׎‬ᶆᶒᶒᶎᵘᵍᵍᶕᶕᶕᵌᶒᶍᶎᵓᵎᵎᵌᶍᶐᶅ ợụࡽဇᵐᵎᵏᵎᵌᵔ

Өૠ

቟‫׎‬
ᒍ‫׎‬
ἧἻὅἋ
ɶ‫׎‬
ἛỶ἖
ἿἉỴ
ỶὅἛ
᪡‫׎‬
ଐஜ

ᵐᵖᵐ
ᵑᵖ
ᵐᵕ
ᵐᵒ
ᵐᵒ
ᵏᵏ
ᵓ
ᵏ
ᵏᵖ

лӳ
ᵰᶋᵿᶖӳᚘ
ᵹᵃᵻᵹᵲᵤᵪᵭᵮᵱᵻ
ᵓᵔᵌᵒᴾ ᵏᵕᵊᵗᵔᵗᵌᵑᴾᵕᵌᵔᴾᵏᵊᵕᵖᵓᵌᵒᴾ
ᵓᵌᵒᴾᵏᵊᵕᵎᵔᵌᵗᴾᵒᵌᵖᴾᵐᵊᵗᵗᵐᵌᵔᴾᵒᵌᵖᴾᵐᵊᵐᵒᵖᵌᵓᴾᵐᵌᵐᴾ
ᵖᵏᵒᵌᵕᴾᵏᵌᵎᴾᵐᵖᵑᵌᵒᴾᵎᵌᵐᴾᵐᵕᵒᵌᵖᴾᵑᵌᵔᴾ
ᵏᵊᵐᵓᵐᵌᵕᴾ

лӳ
ɭမἻὅἁ
ᵰᶋᵿᶖᵈ
ᵹᵃᵻ
ί‫׎‬ϋᵏˮὸ ᵹᵲᵤᵪᵭᵮᵱᵻ
ᵓᵓᵌᵒᴾ
ᵏᴾᵏᵊᵕᵓᵗᴾ
ᵓᵌᵓᴾ
ᵏᵔᴾ
ᵐᵕᵓᴾ
ᵓᵌᵑᴾ
ᵏᵖᴾ
ᵐᵑᵖᴾ
ᵗᵌᵐᴾ
ᵐᴾ
ᵏᵊᵐᵕᵏᴾ
ᵔᵌᵗᴾ
ᵓᴾ
ᵖᵐᵔᴾ
ᵐᵌᵓᴾ
ᵏᵑᴾ
ᵑᵓᵎᴾ
ᵎᵌᵗᴾ
ᵑᵑᴾ
ᵏᵑᵑᴾ
ᵎᵌᵖᴾ
ᵏᵒᴾ
ᵐᵕᵓᴾ
ᵑᵌᵗᴾ
ᵐᵐᴾ
ᵏᵗᵏᴾ
ḤᴾᵰᶋᵿᶖᾉᵪᶇᶌᶎᵿᶁᶉࣱᏡ͌

ଐஜỉᚘምೞ᝻เỉлӳỊẆҾ‫܇‬щೞನỉἋἣἅὅ‫ݰ‬λỆợụЭ‫ׅ‬ίᵐᵎᵎᵗᵌᵏᵏὸợụỊ;ẦỆ‫ࣄׅ‬ẲẺờỉỉẆ
഑቟ởɶ‫׎‬ỆൔỔ࣯ถẲềẟỦẇ
ɶ‫׎‬ỊờỊở቟‫׎‬ỆഏẫἋἣἅὅ‫׎ٻ‬ỆẇଐஜểỉࠀỊ࣯ਘ‫ٻ‬ɶẇଐஜỉ‫׎‬ϋᵏˮίҾ‫܇‬щೞನὸỉᚘምೞỊẆἿἉỴẆ᪡‫׎‬ỉᵏˮỆờӏịễẟẇJapan Atomic Energy Agency

45

46

Japan Atomic Energy Agency

科 学 技 術 計 算 分 科 会

選 出2010 年度 科学技術計算分科会 会合 より

3 次元 MHD コードによる FX1 の性能評価

名古屋大学太陽地球環境研究所
荻野 竜樹

2010 年 10 月 20 日

サイエンティフィック・システム研究会
SS 研科学技術計算分科会

3次元MHDコードによる FX1の性能評価
荻野竜樹
名古屋大学太陽地球環境研究所[アブストラクト]
並列型スパコン FX1 や HX600 の利用により、地球磁気圏のグローバル構造とメソスケールの境界層渦乱流の自己無撞着な大規模高精度シミュレーションができる時代が訪れてきたが、その実現にはさらに高効率の並列計算コードの開発が不可欠である。ここに、キャッシュヒット率向上と多次元領域分割／一括転送による通信量最小化を可能にした高効率の 3 次元
MHD コード開発に成功し、FX1 の 3072 コア数まで 15-20%以上の実行効率を得ることができた。Flat MPI と Hybrid(Impact)の比較では、Flat MPI が最速だったが、コア数によらず Hybrid もよい実行効率を得た。通信速度と計算速度の比は 3072 コアでも 4%以下であり、通信速度は 10 万コア程度までボトルネックにならずにスケーラビリティが伸びることが期待できる。もちろん、実際にテストして実証する必要がある。

[キーワード]地球磁気圏の MHD シミュレーション、高効率の並列コード開発、多次元領域分割と通信量最小化、Flat MPI と Hybrid の比較、スーパーコンピューティング

１．はじめにスペースプラズマや核融合プラズマの最も特異な性質はその異常輸送現象にあるといえる。特に顕著な例として温度の輸送や磁場の拡散は粒子間衝突から得られる古典的な輸送係数の千倍から 1 万倍に達することもあることが観測や実験から知られている。しかし、その基本的な物理過程の説明は今日でも一致した考えに達していないといえる。プラズマの異常輸送の有力な説明には二つある。一つは、マクロ－メソ－ミクロスケール
が必ず結合していてメソスケール現象が決定的な役割を果たしているとする説である。もう一つは、マクロとミクロスケールの直接結合が本質的でメソスケールは重要な役割を果たしていないとする説である。ここに、最近の並列型スパコンの急速な進歩により MHD（電磁流体力学的）モデルからマクロ－メソスケール現象を自己無撞着に解くことができるような時代が実際に訪れてきた。即ち、メソスケール現象がプラズマの異常輸送
現象に本質的な役割を果たしているかどうかに決着をつけるような大規模な 3 次元 MHD シミュレーションを実行できる段階に達してきたといえる。もちろん、ミクロスケール現象は MHD モデルで扱うことができないので、超粒子モデルやブラソフモデルなどの運動論的モデルによるシミュレーションが不可欠である。
そのマクロ－メソスケール結合を調べるには、太陽風と地球磁気圏相互作用のグローバル３次元 MHD シミ
ュレーションが一つの典型的な対象となる。なぜなら、磁気圏のマクロ構造の中に物理量が急峻に空間変化する境界層があり、そこにメソスケールのプラズマ乱流が発生してプラズマの異常輸送を引き起こしている可能性が高く、グローバルモデルから境界層のプラズマ不安定とその非線形発展と結果としての渦乱流発生を自己
矛盾なく解ける段階に達したからである。しかし、その大規模 MHD シミュレーションを実行するためには大規模並列型スパコンの効率を最大化するプログラムの開発が不可欠である。

２．MHD コードの並列化と超並列スパコンの有効利用
MHD モデルでは流体の方程式と Maxwell 方程式を高精度の数値計算法の一つである Modified Leap-Frog 法
で初期値境界値問題として解く。その 3 次元 MHD コードを MPI Fortran を用いて並列化する。その際、CPU数が 1 千個を越えて 1 万個、10 万個程度まで計算速度が劣化しないようなよいスケーラビリティが得られる並列計算コードの開発を目指す。

私達は、これまで富士通の VPP5000/64、PRIMEPOWER HPC2500 1536core などで MPI を利用してそれぞれ 60％、20％を超える実行効率を出す 3 次元 MHD コードを開発してきた。その知識と経験を活かし、高効率の並列計算 3 次元 MHD コードを開発して、平成 21 年度に名古屋大学情報基盤センターに導入された富士通の FX1 3072core と HX600 2048core を用いてテストした。作成した MHD コードは基本的に 4 種類に分類できる。それらは、1 次元領域分割法（1Da）、2 次元領域分割法（2Da）、3 次元領域分割法（3Da）およびキャッシュヒットを上げるために MHD 方程式の配列成分を第 1 変数に移動した 3 次元領域分割法（3Db）である。
2、3 次元領域分割法を用いると分散した CPU 間の通信量が小さくなり、これまでのテスト計算からは、スカラー並列機 HPC2500 では（3Db）が最速、ベクトル並列機 Earth Simulator では（2Da）が最速であった。

３．FX1 と HX600 における３次元 MHD コードの計算速度
FX1 は計算速度とメモリバンド幅が同程度との特徴があるスパコンで、Flat MPI と Hybrid（Impact）両方の利用ができて、Hybrid は 1 ノード 4 コアを共有メモリとしてスレッド並列化し、ノード間をプロセス並列（MPI）で利用する。そのどちらが高速計算できるかが最初の注目点であったが、ほとんどの場合 Flat MPI が最速になっている。ただし、Hybrid の場合もそれほど劣化しない。また、かなりバラつきはあるが、3072 コア
利用までスケーラビリティはよく保たれていた。前章の 4 種類の MHD コードを比較した場合、計算速度の速い順に並べると（3Db）＞（3Da）＞（2Da）＞（1Da）となり、（3Db）で 15-20％以上の実行効率を、（1Da）
で 5-15%程度の実行効率を得ることができた。特に、（3Db）ではコア数が 3072 まで多くなってもほとんど計算速度の劣化は起らず、バランスが良い場合は若干ではあるがむしろ計算効率が向上する場合もあった。JAXAの FX1 でテストした場合は、多数コア（4096、5760 コア）で Hybrid（Impact）が Flat MPI よりも高速になる場合があった。これは大変興味ある結果であるが、MHD 変数の大きさや 3 次元方向の並列分割数がより適切に取られていたかの疑問もあり、継続的なテストが必要である。また、計算時間と通信時間を分離して計測したところ、通信時間と計算時間の比は 256-3072 コアの範囲で 3-4％であり、しかもその比は 3072 コアまであまり変らないので、スケーラビリティは 1 万コアを超えてもよく成り立つことが期待される。しかし、実際はより多くのコア数で実証確認する必要がある。
HX600 も Flat MPI が最速であり、スレッド並列数を増やして Hybrid にすると計算速度がかなり劣化する傾向が明確であった。私のテストでは、最適値を求めた場合 HX600 は FX1 より常に少し計算速度が低めであった。一方、共同研究者のほとんどは逆の結果を得ていて、HX600 が FX1 よりも並列効率がより良いと結論付けている。その結果の違いがどこからきているかはまだ明確ではないが、一つの可能性として 1 コア当りのメモ
リ使用量、即ち粒度が関係していると予想される。

４．おわりに学際大規模情報基盤共同研究・共同拠点のプロジェクトで他の大学の情報基盤センターのスパコンを利用する機会を得た。それらは SX-9、HA8000、SR16000、TSUBAME である。4 種類の MHD コードでテストしたが、どのスパコンも期待したとおりのよい結果が得られ、スケーラビリティもテストしたコア数（3072 コア）の範囲でよく成り立っていた。気がついた点として、T2K のスパコン（HX600，HA8000）は（2Da）が最速で（3Da）がそれに続き、（3Db）は逆に遅かった。一方、SR16000 は FX1 と同様に（3Db）が最速で両者は似た傾向を示した。これらの結果は FX1 と SR16000 ではキャッシュのヒット率向上が重要であることを意味している。また、SR16000 は SMT が非常によく効き約 2 倍の速度がでた。一方、FX1 では SMT による計算速度向上の効果は僅かであった。T2K のスパコンで（2Da）と（3Da）が速いのは｢擬似ベクトル機能が効くためと推測しているが、理由究明にはさらなる系統的なテストが必要である。

SS⎇⑼ቇᛛⴚ⸘▚ಽ⑼ળ
䍀䊊䉟䊌䊐䉤䊷䊙䊮䉴䊶䉮䊮䊏䊠䊷䊁䉞䊮䉫䈱⃻࿷䈫ᧂ᧪䍁
2010ᐕ10᦬20ᣣ䋨᳓䋩䇮 ANA䉪䊤䉡䊮䊒䊤䉱䊖䊁䊦␹ᚭࠕ࠙࠻࡜ࠗࡦ
㧝㧚⢛᥊

3 ᰴరMHD 䉮䊷䊄䈮䉋䉎
FX1 䈱ᕈ⢻⹏ଔ㧞㧚࿾⃿⏛᳇࿤ߩ㧟ᰴరࠣࡠ࡯ࡃ࡞MHDࡕ࠺࡞㧟㧚PRIMEPOWER HPC2500߆ࠄFX1ߣHX600߳ߩ⒖ⴕ
㧠㧚FX1䈫HX600߅ߌࠆ㧟ᰴరMHDࠦ࡯࠼ߩ⸘▚ㅦᐲฬฎደᄢቇᄥ㓁࿾⃿ⅣႺ⎇ⓥᚲ
⩆㊁┥᮸

㧡㧚⒳‫▚⸘ߩࡦࠦࡄࠬߩޘ‬ㅦᐲߩᲧセߣ⠨ኤ㧢㧚࿾⃿⏛᳇࿤ߩ㧟ᰴరMHDࠪࡒࡘ࡟࡯࡚ࠪࡦߩ዁᧪

౒ห⎇ⓥ⠪

㧣㧚߹ߣ߼

᪢↰㓉ⴕ 䋨ฬฎደᄢቇᄥ㓁࿾⃿ⅣႺ⎇ⓥᚲ䋩ᷓᴛ࿻৻㇢ 䋨਻Ꮊᄢቇᄢቇ㒮ℂቇ⎇ⓥ㒮࿾⃿ᖺᤊ⑼ቇㇱ㐷䋩
1

2

Solar-Terrestrial Environment㧝㧚⢛᥊Coronal Mass Ejections࡮ᄥ㓁࿾⃿♽⑼ቇ㧦ᄥ㓁ᵴേߣࠫࠝࠬࡍ࡯ࠬ㧔࿾⃿ᄖ࿤㧕ⅣႺᄌൻߩ࿃ᨐ㑐ଥࠍ⸃᣿ߔࠆ⎇ⓥ࡮ᄖㇱႺ⇇ࠍߢ߈ࠆߛߌ㆙ߊߦ⸳ቯߒߡ߆ߟⓨ㑆ಽ⸃⢻ࠍߢ߈ࠆߛߌ਄ߍࠆ
࡮⸘▚ᣇᴺߩᡷ⦟ߣᦨᄢ⚖ߩࠬ࡯ࡄ࡯ࠦࡦࡇࡘ࡯࠲
ߩല₸⊛ߥ೑↪
࡮ਗ೉⸘▚౒ㅢࡊࡠࠣ࡜ࡓ㧛ᚻᴺߩ㐿⊒
Message Passing Interface (MPI)࡮⿥ਗ೉ࠬ࡯ࡄ࡯ࠦࡦࡇࡘ࡯࠲ߩല₸⊛ߥ೑↪
ን჻ㅢᩣᑼળ␠㧦PRIMEPOWER HPC2500
߆ࠄFX1ߣHX600߳

In te rpla n e ta

ry M aFie ldg n e tic

X- raysᄥ㓁ߣ࿾⃿ߩ㑐ଥTheThe Sun’s
Sun’s magnetic
magnetic field
field isis propagatedpropagated far
far
beyondbeyond ourour planetaryplanetary systemsystem byby thethe solar
solar wind.
wind.
The
The interaction
interaction between
between this
this interplanetaryinterplanetary
magnetic
magnetic field
field (IMF)(IMF) andand Earth’s
Earth’s own
ownmagnetic
magnetic field
field isis aa significant
significant component
component ofofSpaceSpace Weather.
Weather.

Satellite
Satellite anomalies
anomalies related
relatedtoto Space
Space Weather
Weather areare onon thetheriserise duedue toto thethe increased
increased useuseofof composite
composite materials
materials
insteadinstead ofof metal,
metal, andand smaller,
smaller,
fasterfaster chip
chip designs.
designs. The
The three
three
principle
principle anomaly
anomaly types
types are:are:surfacesurface charging,charging, internalinternal
charging,
charging, andand Single
Single Event
Event
Effects
Effects (SEE).
(SEE).

Magnetosphere

Solar WindTheThe SunSun powers
powers both
both thethe sspace
pace weather
weather andand thetheterrestrial
terrestrial weather
weather machines.
machines. Solar
Solar events,
events, i.e.,
i.e.,
explosions
explosions ofof charged
charged particles
particles andand thethe dynamics
dynamics
ofof magnetic
magnetic andand electric
electric fields,
fields, cause
cause huge
hugechangeschanges inin thethe near-Earthnear-Earth space
space environment.
environment.
Satellites
Satellites andand communication
communication signals
signals must
must
traverse
traverse this
this electric
electric space.
space.

FlaresIonosphere

Polar

Geosynchronous㕒ᱛ゠㆏ⴡᤊThe
The Ionosphere
Ionosphere isis aa layer
layer ofof thethe Earth’s
Earth’s
upper
upper atmosphere
atmosphere thatthat contains
contains free
free electrons
electrons
andand ions
ions produced
produced byby solarsolar UVUV radiation.
radiation.
Disruptions
Disruptions ofof thethe ionosphereionosphere cancansignificantly
significantly affectaffect radar,
radar, andand radio
radio
communication.
communication.

3

Y. K ami deᄥ㓁⴫㕙῜⊒⃻⽎䈫ᖺᤊ㑆ᡓੂ䈱વ᠞⏛᳇࿤䊶㔚㔌࿤䊶ᾲ࿤⚿ว䋺㗔ၞ㑆⚿วᄥ㓁ࡈ࡟ࠕߥߤߩᄥ㓁ᵴേߪࠫࠝࠬࡍ࡯ࠬⅣႺᄌൻߩḮᄥ㓁㘑䈱䉣䊈䊦䉩䊷䈲⏛᳇࿤䊶㔚㔌࿤䊶ᾲ࿤䈱㗔ၞ㑆⚿ว䉕੺䈚䈩࿾⃿ౝㇱ䈮ㆇ䈳䉏䇮ᭂၞ䈪䉥䊷䊨䊤䉕ノ䈎䈞䉎䇯ቝቮᄤ᳇⎇ⓥ䈲䈠䈱㗔ၞ㑆⚿ว䉕⺞䈼䇮੍ႎ䈮⚿䈶䈧䈔䉎䇯

4

ISASឭଏ

䇸䉋䈉䈖䈉䇹䈮䉋䉎ᄥ㓁䈱エX✢↹௝NASAឭଏ

ᖺᤊ㑆ⓨ㑆䉕વ᠞䈜䉎CME䋨䉮䊨䊅⾰㊂᡼಴䋩ᄥ㓁㘑䋭⏛᳇࿤䋭㔚㔌࿤䊶ᾲ࿤䋭ᄢ᳇࿤⚿ว䉲䉴䊁䊛
5⏛᳇፲ᤨ䈱ⴡᤊ䉥䊷䊨䊤↹௝
6ർᭂၞ䈱䉥䊷䊨䊤࿾⃿⏛᳇࿤䈱Ⴚ⇇ጀ䈫䉫䊨䊷䊋䊦䉲䊚䊠䊧䊷䉲䊢䊮⏛᳇࿤䈱䉫䊨䊷䊋䊦᭴ㅧ䈫Ⴚ⇇ጀ䈱‛ℂ䉕self-consistent⸃䈒䈖䈫䈏㊀ⷐ

Plasma Mantle
Bow ShockPlasma Sheet
Magnetic
Reconnection

MirrorFire-hose

Inner Boundaryof Plasma Sheet

Rayleigh-Taylor

Filamentary

Ballooning
Interchange

Entry Layer
Magnetic
Reconnection

Low Latitude
Boundary Layer
Kelvin-Helmholtz

7⏛᳇࿤Ⴚ⇇ጀ䈪䈱᷵ੂᵹ䈱⊒↢䈫䊒䊤䉵䊙䈱⇣Ᏹャㅍ⏛᳇䊥䉮䊈䉪䉲䊢䊮䈫䊒䊤䉵䊝䉟䊄᡼಴

Plasmoid ejection in earth’s magnetotail
magnetic
reconnection

8

Southward IMF Bz = -20 nT n = 5/cc Vsw = 300 km/s t = 120 min

plasmoidearth䊐䉞䊤䊜䊮䊃᭴ㅧ᷵೉⏛᳇䊥䉮䊈䉪䉲䊢䊮

Northward IMF Bz = 20 nT n = 5/cc Vsw = 300 km/s t = 340 min㜞✲ᐲየㇱ⏛᳇䊥䉮䊈䉪䉲䊢䊮

Ⴚ⇇ጀ᷵೉

᷵೉䈱ᵹ䉏

9

Southward IMF Bz = -20 nT n = 5/cc ⏛᳇࿤Ⴚ⇇ጀ䈪䈱᷵ੂᵹVsw = 300 km/s t = 120 min䈱⊒↢10⏛᳇࿤Ⴚ⇇ጀ䈪䈱᷵ੂᵹ䈱⊒↢TemperatureEc

K Jc K| Bu J ||B|

Neutral line
Filamentary
structurevortex train
Green 䋺 CloseBlue 䋺 Open
Red, Purple䋺 unconnect to the Earth
11

Sun

Northward IMF
Bz = 20 nT n = 5/cc
Vsw = 300 km/s
t = 340 min
Green 䋺 Close
Red, Purple 䋺 unconnect to the Earthmagnetopause
Formation of vortex train12㜞ㅦ࿁ォ䈜䉎ᧁᤊ⏛᳇࿤䈪䈱䊒䊤䉵䊝䉟䊄䈱᭴ㅧ䋲䋮࿾⃿⏛᳇࿤䈱䋳ᰴర䉫䊨䊷䊋䊦
MHD䉲䊚䊠䊧䊷䉲䊢䊮䊝䊂䊦

Patchy plasma sheet with IMF By and Bzධะ䈐ᖺᤊ㑆⏛႐ർะ䈐ᖺᤊ㑆⏛႐

13䉴䉦䊤䊷ਗ೉ᯏ䈪㜞ㅦ⸘▚䉕ታ⃻䈜䉎䈢䉄䈮

ၮ␆ᣇ⒟ᑼ䋺MHDᣇ⒟ᑼ䈫Maxwellᣇ⒟ᑼ
wU
wt
wv
wt
wp
wt
wB
wt

  ( vU )  D 2 U(p )( v   ) v 

U



g

U



3ᰴరMHD䉮䊷䊄䈱㗔ၞಽഀᴺ䈮䉋䉎ਗ೉ൻ(2)U

( v  ) p  Jp  v  D p  p2䋱ᰴర㗔ၞಽഀ

(3)䋲ᰴర㗔ၞಽഀ

 u ( v u B )  K B

(4)

 u (B  B d )

(5)

2

J

ਗ೉⸘▚䈱䌣䌰䌵ᢙ䈏ᄢ᏷䈮Ⴧട
ㅢା㊂䉕ᄢ᏷䈮ᷫ䉌䈜䉨䊞䉾䉲䊠䈱䊍䉾䊃₸䉕਄䈕䉎

(1)
JuB

䋳ᰴర㗔ၞಽഀ

15

⸘
▚
ᤨ
㑆
义 102
Ts
乊

ㅢ
ା
ᤨ
㑆
义
102 Tc乊3ᰴర

Tc 3 v 3( P  1)

101

102
䊒䊨䉶䉾䉰ᢙ䋨P䋩Ⴚ⇇᧦ઙ㗔ၞಽഀ㑆䊂䊷䉺䈱ォㅍ (send+recv)
First Step 䈱⸘▚㗔ၞಽഀ㑆䊂䊷䉺䈱ォㅍ (send+recv)
Second Step 䈱⸘▚

1

1

16

CPU㑆䈱䊂䊷䉺
ォㅍ䉕䋲▎ᚲ䈮㓸䉄䈩৻᜝ォㅍ䈠䈱႐ว䇮᧦ઙᢥ䈫
do loopᢥ䉕ਇ૶↪

ౝㇱႺ⇇䈱ୃᱜ

101

13

਄ᵹႺ⇇䈱ᦝᣂ

Tc 2 v 2( P 2  1)1㪫㪺㪔㪊㫂㪉 㪥㪉 㩿㪧㪈㪆㪊㩷㪄㪈㪀೨䊂䊷䉺䈱 read1P

Tc1 v ( P  1)

k1䈫k2䋺 ৻ቯ䈱ଥᢙN䋺 䋳ᰴర㈩೉䈱䋱ᣇะ䈱ᄌᢙ㊂P䋺 ਗ೉CPU䈱ᢙ㪫㪺㪔㪉㫂㪉 㪥㪉 㩿㪧㪈㪆㪉㩷㪄㪈㪀

103

2ᰴర

101

㪫㪺㪔㫂㪉 㪥㪉 㩿㪧㪄㪈㪀

ೋᦼ୯

1ᰴర
Ts v

ㅢାᤨ㑆

㪫㫊㪔㫂㪈㩷㪥㪊㩷㪆㪧㩷㪫㫊㪔㫂㪈㩷㪥㪊㩷㪆㪧㩷㩷㪫㫊㪔㫂㪈㩷㪥㪊㩷㪆㪧㩷㩷⸘▚ⅣႺ⸳ቯ

104

䋱䇮䋲䇮䋳ᰴర㗔ၞಽഀᴺ䈮䉋䉎ਗ೉⸘▚ല₸, ਗ೉⸘▚ᤨ㑆䈲⸘▚ᤨ㑆䋨Ts)䈫ㅢାᤨ㑆䋨Tc䋩䈱๺䈫䈭䉎䇯

103

⸘▚ᤨ㑆

MPI䉕↪䈇䈢MHD䉮䊷䊄䈱᭴ㅧ㗔ၞಽഀ䈮䉋䉎ਗ೉⸘▚ല₸
104

14

103

104

䉰䊮䊒䊥䊮䉫䊂䊷䉺䈱 write

1
17

⸘▚⚳ੌ

18

㗔ၞಽഀ䈘䉏䈢CPU㑆䈱䊂䊷䉺ォㅍ1䋳ᰴర㗔ၞಽഀ䈱ᣇᴺ৻᜝ォㅍ䈱䋲ᰴర䊋䉾䊐䉜䉕ዉ౉CC MPI START
parameter (npex=2,npey=2,npez=2)
parameter (npe=npex*npey*npez,npexy=npex*npey)
integer itable(-1:npex,-1:npey,-1:npez)cparameter(nzz=(nz2-1)/npez+1)
parameter(nyy=(ny2-1)/npey+1)
parameter(nxx=(nx2-1)/npex+1)
parameter(nxx3=nxx+2,nyy3=nyy+2,nzz3=nzz+2)cdimension f(nb,0:nxx+1,0:nyy+1,0:nzz+1)
dimension ftemp1x(nb,nyy3,nzz3),ftemp2x(nb,nyy3,nzz3)
dimension ftemp1y(nb,nxx3,nzz3),ftemp2y(nb,nxx3,nzz3)
dimension ftemp1z(nb,nxx3,nyy3),ftemp2z(nb,nxx3,nyy3)c19MPI䈪ਔ┵䈫ਛ㑆䈱CPU㑆䈱ォㅍ䉕ห䈛ᒻ䈮䈜䉎䈢䉄䈮䇮ਇታⴕ䉕ት⸒䈜䉎䋳ᰴర䈱䊁䊷䊑䊦䉕૞ᚑdo k=-1,isizez
do j=-1,isizey
do i=-1,isizex
itable(i,j,k)=MPI_PROC_NULL
end doitable(-1:npex,-1:npey,-1:npez)cirank1=0
do k=0,isizez-1
do j=0,isizey-1
do i=0,isizex-1
itable(i,j,k)=irank1
if(irank.eq.irank1) thenirankx=iiranky=jirankz=k
end ifirank1=irank1+1
end doCC MPI START
irightx = itable(irankx+1,iranky,irankz)
ileftx = itable(irankx-1,iranky,irankz)
irighty = itable(irankx,iranky+1,irankz)
ilefty = itable(irankx,iranky-1,irankz)
irightz = itable(irankx,iranky,irankz+1)
ileftz = itable(irankx,iranky,irankz-1)
C
CC MPI END

c20䊔䉪䊃䊦ਗ೉ᯏ䋨Earth Simulator䋩䈫䉴䉦䊤䊷ਗ೉ᯏ
PRIMEPOWER HPC2500䈪䈱⸘▚ㅦᐲ䈱Ყセ㗔ၞಽഀ䈘䉏䈢CPU㑆䈱䊂䊷䉺ォㅍ2

㪊㪌㪇㪇
㪊㪇㪇㪇

㪈㪛
㪉㪛
㪊㪛㪸
㪊㪛㪹

㪉㪌㪇㪇
㪉㪇㪇㪇

䋲ᰴర㗔ၞಽഀ
䋳ᰴర

㪈㪌㪇㪇
㪈㪇㪇㪇

䋳ᰴర

㪌㪇㪇
㪇

䋱ᰴర
㪇

㪈㪇㪇

㪉㪇㪇

㪊㪇㪇

㪋㪇㪇

㪌㪇㪇

㪍㪇㪇

㪚㫆㫄㫇㫌㫋㪸㫋㫀㫆㫅㩷㪪㫇㪼㪼㪻㩷㫇㪼㫉㩷㪧㫉㫆㪺㪼㫊㫊㫆㫉㩿㪞㪽㫃㫆㫇㫊㪆㫇㫉㫆㪺㪼㫊㫊㫆㫉㪀㪚㫆㫄㫇㫌㫋㪸㫋㫀㫆㫅㩷㪪㫇㪼㪼㪻㩷㩿㪞㪽㫃㫆㫇㫊㪀䊔䉪䊃䊦ਗ೉ᯏ䋺 䋲ᰴర㗔ၞಽഀ䈏ᦨ㜞ല₸

㪎
㪍
㪌
㪋
㪊

㪈㪛
㪉㪛
㪊㪛㪸
㪊㪛㪹

㪉
㪈
㪇

㪇

㪉㪇㪇

㪊㪇㪇

㪋㪇㪇

㪌㪇㪇

㪍㪇㪇

㪌㪇㪇

㪍㪇㪇

㪥㫆㪅㩷㫆㪽㩷㪧㫉㫆㪺㪼㫊㫊㫆㫉㫊

㪈㪉㪇㪇
㪈㪇㪇㪇
㪏㪇㪇

㪈㪛
㪉㪛
㪊㪛㪸
㪊㪛㪹

䋳ᰴర㗔ၞಽഀ
䋳ᰴర

㪍㪇㪇
㪋㪇㪇

䋲ᰴర

㪉㪇㪇
㪇

䋱ᰴర
㪇

21

㪈㪇㪇

㪉㪇㪇

㪊㪇㪇

㪋㪇㪇

㪌㪇㪇

㪍㪇㪇

㪚㫆㫄㫇㫌㫋㪸㫋㫀㫆㫅㩷㪪㫇㪼㪼㪻㩷㫇㪼㫉㩷㪧㫉㫆㪺㪼㫊㫊㫆㫉㩿㪞㪽㫃㫆㫇㫊㪆㫇㫉㫆㪺㪼㫊㫊㫆㫉㪀䉴䉦䊤䊷ਗ೉ᯏ:䋺 䋳ᰴర㗔ၞಽഀ䈪㈩೉ᄌᦝ䈏ᦨ㜞ല₸
㪉㪅㪌
㪉
㪈㪅㪌
㪈
㪇㪅㪌
㪇

㪇

㪥㫆㪅㩷㫆㪽㩷㪧㫉㫆㪺㪼㫊㫊㫆㫉㫊

㪈㪛
㪉㪛
㪊㪛㪸
㪊㪛㪹

㪈㪇㪇

㪉㪇㪇

㪊㪇㪇

㪋㪇㪇

㪥㫆㪅㩷㫆㪽㩷㪧㫉㫆㪺㪼㫊㫊㫆㫉㫊

22ฬฎደᄢቇᖱႎၮ⋚䉶䊮䉺䊷䈱ᣂ䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺

䋳䋮PRIMEPOWER HPC2500䈎䉌
FX1䈫HX600䈻䈱⒖ⴕ

䉲䉴䊁䊛S1

M9000ᄢⷙᮨ䈭౒᦭䊜䊝䊥3䊉䊷䊄 x 128䉮䉝 䋨1䊉䊷䊄䈲FX1䈱䊐䊨䊮䊃䉣䊮䊄䋩䊉䊷䊄ᒰ䉍䋺Ṷ▚ᕈ⢻䋺1.28TFlops, 䊜䊝䊥䋺1TB

䋨ฬฎደᄢቇᖱႎၮ⋚䉶䊮䉺䊷䋩䉲䊚䊠䊧䊷䉲䊢䊮⚿ᨐ䈱⸃ᨆ䈫↹௝ಣℂ䈮೑↪

3䊉䊷䊄䋨SPARC䋩㪈㪇㪇㪥㫆㪅㩷㫆㪽㩷㪧㫉㫆㪺㪼㫊㫊㫆㫉㫊㪚㫆㫄㫇㫌㫋㪸㫋㫀㫆㫅㩷㪪㫇㪼㪼㪻㩷㩿㪞㪽㫃㫆㫇㫊㪀CC MPI START
ftemp1x=f(:,is,:,:)
หᦼဳ䈱৻᜝ォㅍ䉕೑↪
ftemp1y=f(:,:,js,:)
ftemp1z=f(:,:,:,ks)
call mpi_sendrecv(ftemp1x,nwyz,mpi_real,ileftx,200,&
ftemp2x,nwyz,mpi_real,irightx,200,&
mpi_comm_world,istatus,ier)call mpi_sendrecv(ftemp1y,nwzx,mpi_real,ilefty,210,&
ftemp2y,nwzx,mpi_real,irighty,210,&
mpi_comm_world,istatus,ier)call mpi_sendrecv(ftemp1z,nwxy,mpi_real,ileftz,220,&
ftemp2z,nwxy,mpi_real,irightz,220,&
mpi_comm_world,istatus,ier)Cf(:,ie+1,:,:)=ftemp2xf(:,:,je+1,:)=ftemp2yf(:,:,:,ke+1)=ftemp2z
CC MPI END

c160䊉䊷䊄䋨Opteron䋩䉲䉴䊁䊛S2

HX600

ᄢⷙᮨ䉲䊚䊠䊧䊷䉲䊢䊮䈲䉲䉴䊁䊛S3 (FX1)
Hybrid (Impact)䈱೑↪
䉕ផᅑ䉪䊤䉴䉺䊷ဳ⸘▚ᯏ䋨T2Kဳ䋩䊉䊷䊄ౝ䈲౒᦭䊜䊝䊥160䊉䊷䊄 x 16䉮䉝䊉䊷䊄ᒰ䉍䋺Ṷ▚ᕈ⢻䋺160GFlops, 䊜䊝䊥䋺64GB✚䊉䊷䊄䋯䉮䉝ᢙ䋺768䋯3072✚Ṷ▚ᕈ⢻䋺30.72TFlops✚䊜䊝䊥䋺24TB䉲䉴䊁䊛S3

FX1೑↪䈱⸘▚ⷙᮨਛⷙᮨ䉲䊚䊠䊧䊷䉲䊢䊮䈮೑↪
FX1ᄢⷙᮨಽᢔਗ೉ဳ䇮ᰴ਎ઍ䉴䊌䉮䊮䈫䈱ㅪ៤
768䊉䊷䊄 x 4䉮䉝䊉䊷䊄ᒰ䉍䋺Ṷ▚ᕈ⢻䋺40GFlops, 䊜䊝䊥䋺32GB
䊜䊝䊥䊋䊮䊄᏷䋺40GB/s

768䊉䊷䊄 䋨SPARC䋩ᄢⷙᮨ䉲䊚䊠䊧䊷䉲䊢䊮䈮೑↪

23

䉮䉝ᢙ
256 512 1024䊜䊝䊥 (TB)
2
48Ṷ▚ᕈ⢻ 2.56 5.12 10.24(Tflops)24

Four Key Functions of Supercomputer
Speed
cpu 12.48 Tflops 30 Tflops
Main Memory
11.5 TB 24TB

Disc
50 TB 1PB

Network
SuperSINET (10 Gbps)
䉴䊌䉮䊮䈪䈱㜞ല₸ਗ೉⸘▚䈱ታ⃻䉴䊌䉮䊮䈱ᦨᄢᕈ⢻䉕ᒁ䈐಴䈜䊒䊨䉫䊤䊛㐿⊒⛘ኻᕈ⢻䈱10-20%⒟ᐲએ਄䈱Ṷ▚ㅦᐲ䈪䉋䈇䉴䉬䊷䊤䊎䊥䊁䉞䈏଻䈢䉏䉎䈖䈫䈏⋡ᮡ

HPC2500/1536 (scalar-parallel)
FX1/256䊉䊷䊄/1024䉮䉝䋨2009.5.18䋩
FX1/768䊉䊷䊄/3072䉮䉝䋨2009.10.1䋩

㧗Graphics
Animation,
3D Visualization䉲䊚䊠䊧䊷䉲䊢䊮⚿ᨐ䈱นⷞൻ䊂䊷䉺ಣℂ䈫↹௝ಣℂേ↹3ᰴరนⷞൻ (VRML)
VR (Virtual Reality)䉴䊌䉮䊮䈪ⴕ䈉䈎䇮WS䉇PC䈪ⴕ䈉䈎䋿Ꮒᄢ䈭䊂䊷䉺䈱นⷞൻ䉕䈬䈉䈜䉎䈎

Flat MPI䈫Hybrid䋨userਗ೉䋫⥄േਗ೉䋩䈲䈬䈤䉌䈏ᦨㅦ䈎䋿Hybrid䈪䈲䍀Nodeౝ䈲䊔䊮䉻䊷䈏ᦨ㜞ല₸䈱⥄േਗ೉ൻ䉕ឭଏ䈜䉎
Node㑆䈲䊡䊷䉱䊷䈏ᦨ㜞ല₸䈱䊒䊨䉶䉴ਗ೉䊒䊨䉫䊤䊛䉕૞ᚑ䈜䉎䈖䈱⚿ᨐ䇮ᦨ㜞ല₸䈱䊒䊨䉫䊤䊛䈏ᓧ䉌䉏䉎䈲䈝䈪䈅䉎䋿䋿䋿䍁
䈖䈱๮㗴䈲ᱜ䈚䈇䈎䋿
䈠䉏䈫䉅Flat MPI䈏ᦨㅦ䈎䋿

25

Hybrid䈪䈲䊉䊷䊄ౝ䈱ਗ೉ൻ䈫䊉䊷䊄㑆䈱ਗ೉ൻ䈮㥿㦉䈲↢䈛䈭䈇䈱䈎䋿䊶䊜䊝䊥਄䈮ᄌᢙ䈏䈬䈱᭽䈮㈩⟎䈘䉏䉎䈱䈎䋿䊶䊉䊷䊄㑆䈪䈬䈱᭽䈮㗔ၞಽഀ䈚䈩䇮ಽᢔ䊜䊝䊥䈮㈩ಽ䈚䈩䈇䉎䈎䈲ᧄ⾰⊛䈮㊀ⷐ䊶䊉䊷䊄ౝ䈪䈬䈱᭽䈮㗔ၞಽഀ䈚䈩䇮䊜䊝䊥䈮ഀ䉍ઃ䈔䉎䈎䇮⇼໧䋿䋨䊉䊷䊄ౝ⥄േਗ೉ൻ䈲䈬䈉䈚䈩䈇䉎䈱䈎䋿䋩䊶䉨䊞䉾䉲䊠䈱䊍䉾䊃₸ะ਄䈫ㅢା㊂䈱ᦨዊൻ26䉅䈤䉐䉖䇮Flat MPI䈫Hybrid䈲䈬䈤䉌䈏ᦨㅦ䈎䈲䉴䊌䉮䊮䈮䉋䉎䊶Fujitsu FX1䈲䋱node 4 core䈪䇮1 nodeౝ䈪䈲౒᦭䊜䊝䊥䉕ᜬ䈧䊶ᓥ䈦䈩䇮Flat MPI䈫Hybrid䋨Impact䋩䈲䈬䈤䉌䈏ᦨㅦ䈎䇮ᬌ⸽䈏ᔅⷐቢో䈭ಽᢔဳ䉴䊌䉮䊮䈪䈅䉏䈳䇮Flat MPI䈏ᦨㅦ䈮䈭䉎䈫৻⥸䈮ା䈛䈩䉌䉏䈩䈇䉎䇯䈠䈱ઁ䈱ో䈩䈱䉴䊌䉮䊮䈪Flat MPI䈏ᦨㅦ䈮䈭䉎䈫੍ᗐ䈚䈩䈇䉎䇯䈖䉏䉅⃻࿷䉁䈪䈱⚻㛎䈎䉌䈱੍ᗐ

Flat MPI䈪䈲ోㇱ䈱㈩೉ᄌᢙ䉕䈬䈱᭽䈮䊜䊝䊥䈮ഀ䉍ઃ䈔䉎䈎䉕ᜰቯ䈪䈐䉎
ㅢା㊂䈱ᦨዊൻ䈫䉨䊞䉾䉲䊠䈱䊍䉾䊃₸䉕䊃䊷䉺䊦䈪ᦨㆡൻ䈢䈣䈚䇮㜞ᐲ䈭ᛛⴚ䈏ᔅⷐ䈠䈱䊁䊮䊒䊧䊷䊃䋨䊒䊨䉫䊤䊛䈱᭴ㅧ䋩䉕૞䉏䈳⺕䈪䉅೑↪
䈪䈐䉎䈲䈝ㅢା㊂ᦨዊൻ䋫ਗ೉ൻ䉥䊷䊋䊷䊓䉾䊄䋨Flat MPI䋩䈫౒᦭䊜䊝䊥㑆ⴣ⓭䈫䉨䊞䉾䉲䊠䈱䊍䉾䊃₸ᄌൻ䋨Hybrid䋩䈲䊃䊧䊷䊄䉥䊐䈱㑐ଥ
27

䉴䊷䊌䊷䉴䉦䊤䊷ਗ೉䉴䊌䉮䊮䈪ᦨ㜞ല₸䈱ਗ೉䊒䊨䉫䊤䊛䉕૞ᚑ䈜䉎䈮䈲䋱䋮వ䈝䇮䊒䊨䉫䊤䊛䈱᭴ㅧ䈱⏕┙䈏ᦨ䉅㊀ⷐ

28䉴䊷䊌䊷䉴䉦䊤䊷ਗ೉䉴䊌䉮䊮䈪ᦨ㜞ല₸䈱ਗ೉䊒䊨䉫䊤䊛䉕૞ᚑ䈜䉎䈮䈲䋨䈠䈱䋲䋩䊶⸘▚䈪䈱ᄌᢙෳᾖ䉕ర䈮䊒䊨䉫䊤䊛᭴ㅧ䉕᳿ቯ㈩೉ᄌᢙቯ⟵䈱ᦨዊൻ⸘▚䈱᣿⏕䈭䊑䊨䉾䉪ൻ⸘▚䈫ㅢା䈱ቢో䈭ಽ㔌ቯᢙ䈫ᄌᢙ䈲ᗧ⼂䈚䈩඙೎䋨dependency䉕⸃䈒䋩a(i)=a(i+j)䈱ᒻ䈪 j 䈲ቯᢙ䈪ቯ⟵䊶㗔ၞಽഀᴺ䈱ዉ౉䋨䋲䇮䋳ᰴర㗔ၞಽഀ䋩ㅢା䈪䈲৻᜝ォㅍ䉕ታᣉ䊶Dependency䉕น⢻䈭㒢䉍ข䉍㒰䈒⸘▚䈱䊜䉟䊮ㇱಽ䈪䈲Ifᢥ䉇᧦ઙᢥ䈲⛘ኻ䈮૶↪ਇนቯᢙቯ⟵䈱೑↪
Mask䇮List vector䇮Gather and scatter䈱ᦨㆡ䈭૶↪
䊶ᄌᢙ䈱৻᜝ᄌ឵䈫৻᜝ォㅍ䈖䉏䉕᧦ઙᢥ䉇do loop䉕ዉ౉䈞䈝䈮ታⴕ䊶 ㈩೉䈱ᄢ䈐䈘䇮do loop䈱࿁ᢙ䋨ೋᢙ䈫⚳ᢙ䋩䇮㈩೉ౝ䈱ᄌᢙ䈲ቯᢙ䈪ቯ⟵ቯᢙቯ⟵䈲parameterᢥ䉕೑↪

Ifᢥ䉇᧦ઙᢥ䈏ਗ೉ൻ䋨ᡆૃ䊔䉪䊃䊦ൻ䋩䈪䈐䈢䈫䈱⴫␜䈮䈣䉁䈘䉏䈩䈲䈇䈔䈭䈇䇯䈠䈱ല₸䈲ታ㓙㕖Ᏹ䈮ᖡ䈇䇯䋨ᔅ䈝ታ᷹䈜䉎䈖䈫䋩
29

30

㧠㧚FX1䈫HX600߅ߌࠆ㧟ᰴరMHDࠦ࡯࠼ߩ⸘▚ㅦᐲ

PRIMEPOWER HPC2500䈫FX1䈪䈱⸘▚ㅦᐲ䈱Ყセ
2151Gflops 1024core 256node 4thread
㪉㪅㪌

㪉㪇㪇㪇

㪉

㪚㫆㫄㫇㫌㫋㪸㫋㫀㫆㫅㩷㪪㫇㪼㪼㪻㩷㫇㪼㫉㩷㪧㫉㫆㪺㪼㫊㫊㫆㫉㪚㫆㫄㫇㫌㫋㪸㫋㫀㫆㫅㩷㪪㫇㪼㪼㪻㩷㩿㪞㪽㫃㫆㫇㫊㪀

FX1 2243Gflops 1024core Flat MPI
㪉㪌㪇㪇

㪈㪌㪇㪇

1093Gflops
512core 128node 4thread

㪈㪇㪇㪇
㪌㪇㪇
㪇

㪇

㪌㪇㪇

㪈㪇㪇㪇

㪈㪌㪇㪇

㪉㪇㪇㪇

FX1
2.19Gflops/core
2.10Gflops/core

2.17

㪈㪅㪌
㪈
㪇㪅㪌
㪇

㪇

㪥㫆㪅㩷㫆㪽㩷㪧㫉㫆㪺㪼㫊㫊㫆㫉㫊

㪌㪇㪇

㪈㪇㪇㪇

㪈㪌㪇㪇

㪉㪇㪇㪇

㪥㫆㪅㩷㫆㪽㩷㪧㫉㫆㪺㪼㫊㫊㫆㫉㫊࿑䋶 㪧㪩㪠㪤㪜㪧㪦㪮㪜㪩㩷㪟㪧㪚㪉㪌㪇㪇䈪㪚㪧㪬ᢙ䉕Ⴧ䉇䈚䈢႐ว䈱⸘▚ㅦᐲ䋨㪞㪽㫃㫆㫇㫊䋩䈫㪈㪚㪧㪬ᒰ䈢䉍䈱⸘▚ㅦᐲ䋨㪞㪽㫃㫆㫇㫊㪆㪺㫇㫌䋩䇯 䊶㪈㪌㪊㪍㩷㪺㫇㫌䉁䈪䉴䉬䊷䊤䊎䊥䊁䉞䈲㕖Ᏹ䈮⦟䈇

Fujitsu FX1䈲䇮䋳ᰴర㗔ၞಽഀ䈫䉨䊞䉾䉲䊠䊍䉾䊃䉕ᡷༀ䈚䈢䋳ᰴరMHD䉮䊷䊄䈪
128node, 512core䈪22%䈏ᓧ䉌䉏䇮 256node, 1024core䈪21%䈱㜞ല₸⸘▚.

䋶೉⋡䋺Tc䋺䋱࿁ᤨ㑆䉴䊁䉾䊒䉕ㅴ䉄䉎䈱䈮ⷐ䈜䉎CPUᤨ㑆䋨sec䋩䋷೉⋡䋺Tcg䋺䋱䉫䊥䉾䊄䈮䈧䈐䋱࿁ᤨ㑆䉴䊁䉾䊒䉕ㅴ䉄䉎䈱䈮ⷐ䈜䉎CPUᤨ㑆䋨nsec䋩䋸೉⋡䋺Tcg*Ng䋺Tcg䈫✚CPU/COREᢙ䈱Ⓧ䋨nsec䋩䇮ᢙ୯䈏ዊ䈘䈇䈾䈬㜞ല₸⸘▚䉕␜䈜䇯ᄢ☸ᐲ⸘▚䈪䈱ᦨ㜞ㅦ䈲1024core Flat MPI䈪21%䉕㆐ᚑ䇯

31

FX1䈱⸘▚ㅦᐲ 1
䉮䊮
䊏䊠䊷䉺

䊒䊨䉫䊤
䊛

䉫䊥䉾䊄ᢙ

✚䉮䉝
ᢙ

FX1

1Da

1024**3

256

FX1

1Da

1024**3

128

FX1

1Da

1124*1024**2

128

䊒䊨䉶䉴
ਗ೉ᢙ

32

FX1䈱⸘▚ㅦᐲ 2

⥄േ
ਗ೉ᢙ

CPUᤨ㑆
(sec)

⸘▚ㅦᐲ
(Gflops)ല₸(%)

䉮䊮䊏䊠䊷䉺

䊒䊨䉫䊤
䊛

䉫䊥䉾䊄ᢙ

✚䉮䉝
ᢙ

䊒䊨䉶䉴
ਗ೉ᢙ

⥄േ
ਗ೉ᢙ

CPUᤨ㑆
(sec)

⸘▚ㅦᐲ
(Gflops)

ല₸
(%)

64

4

128

1

152.0

9

0.4

FX1

3Db

1024**3

1024

1024

1

0.645

2096

20.5

232.2

6

0.5

FX1 (SMT)

3Db

1024**3

1024

1024

1

0.661

2043

128

20.0

1

28.4

52

4.1

FX1

3Db

1024**3

1024

258

4

0.732

1846

18.0
17.7

FX1

2Da

1024**3

128

128

1

17.1

79

6.2

FX1 (SMT)

3Db

1024**3

1024

258

4

0.783

1810

FX1

2Da

1124*1024**2

128

128

1

8.23

180

14.1

FX1

3Db

1024**3

2048

2048

1

0.355

3813

18.6

FX1

3Da

1024**3

128

128

1

7.32

185

14.4

FX1

3Db

1024**3

2048

512

4

0.380

3555

17.4

FX1

3Db

1024**3

128

128

1

5.22

259

20.2

FX1 (SMT)

3Db

2048**3

1024

1024

1

5.09

2127

20.8

FX1

2Da

3072*2048**2

3072

3072

1

17.2

1004

3.3

FX1

3Db

2048**3

2048

2048

1

2.72

3979

19.4

FX1

2Da

3072*2048**2

3072

768

4

19.7

822

2.7

FX1

3Db

2048**3

2048

512

4

2.88

3752

18.3

FX1

3Da

3072*2048**2

3072

3072

1

3.91

4145

13.5

FX1

3Db

3072

3072

1

2.70

5997

19.5

FX1

3Da

3072*2048**2

3072

768

4

4.36

2782

9.1

3072*
2048**2

FX1

3Db

3072*2048**2

3072

3072

1

3.29

4932

16.1

FX1

3Db

768

4

2.92

5556

18.1

3Db

3072*2048**2

3072

768

4

3.76

4321

14.1

3072*
2048**23072

FX1

1Da䋺1ᰴర㗔ၞಽഀ䇮2Da䋺2ᰴర㗔ၞಽഀ䇮3Da䋺3ᰴర㗔ၞಽഀ䇮3Db䋺3ᰴర㗔ၞಽഀ䋫f(m,i,j,k)䉫䊥䉾䊄ᢙ䈱ㆬ䈶ᣇ䈮䉋䈦䈩䈲ᭂ┵䈮⸘▚ല₸䈏ഠൻ䈜䉎႐ว䈏䈅䉎䈏䇮ዋ䈚⺞▵䈜䉎䈫ᡷ⦟䈪䈐䉎䇯 33

2Da䋺2ᰴర㗔ၞಽഀ䇮3Da䋺3ᰴర㗔ၞಽഀ䇮3Db䋺䋳ᰴర㗔ၞಽഀ䋫f(m,i,j,k)
3Db䈲⸘▚ല₸䈏㜞䈇䇮䉁䈢Flat MPI䈏Hybrid䋨⥄േਗ೉ᢙ=4䋩䉋䉍௖䈎䈮㜞ല₸
34

FX1䈱⸘▚ㅦᐲ 3
䉫䊥䉾䊄ᢙ

✚䉮䉝
ᢙ

䊒䊨䉶䉴
ਗ೉ᢙ

FX1 (SMT) 3Db

2048**3256

FX1 (SMT) 3Db

2048**3

FX1

3Db

FX1
FX1

䉮䊮䊏䊠䊷
䉺
JAXAJAXA JAXA

HX600䈱⸘▚ㅦᐲ

⥄േ
ਗ೉ᢙ

CPUᤨ㑆
(sec)

⸘▚ㅦᐲ
(Gflops)

ല₸
(%)

256

1

19.8

541

21.3

1024

1024

1

5.09

2127

2048**3

2048

2048

1

2.72

3979

3Db

3072*2048**2

3072

3072

1

2.70

3Db

2048**3

512

512

1

10.53

䊒䊨䉫
䊤䊛

䉮䊮䊏䊠䊷䉺

䊒䊨䉫䊤
䊛

䉫䊥䉾䊄ᢙ

✚䉮䉝
ᢙ

䊒䊨䉶䉴
ਗ೉ᢙ

⥄േ
ਗ೉ᢙ

CPUᤨ㑆
(sec)

⸘▚ㅦᐲ
(Gflops)

ല₸
(%)

HX600

2Da

1024**3

256

256

1

4.95

273

10.7

HX600

3Da

1024**3

256

256

1

3.56

379

14.8

20.8

HX600

3Db

1024**3

256

256

1

5.22

259

10.1

19.4

HX600

3Db

1024**3

2048

2048

1

0.464

2912

15.9

5997

19.5

HX600

3Db

1024**3

2048

512

4

0.685

1972

9.6

1028

20.1

HX600

3Db

1024**3

2048

128

16

0.894

1511

7.4
16.3

3Db

1024**3

HX600

3Da

1024**3

2048

2048

1

0.406

3327

JAXA FX1

3Db

1024**3

1024

1024

1

0.701

1929

18.8

HX600

䋲Da

1024**3

2048

2048

1

0.674

2005

9.8

JAXA FX1

3Db

1024**3

4096

4096

1

0.220

6160

15.0

HX600

䋲Da

2048**3

2048

2048

1

6.27

1724

8.4

JAXA FX1

3Db

1024**3

4096

1024

4

0.211

6406

15.6

HX600

3Da

2048**3

2048

2048

1

3.54

3047

14.9

JAXA FX1

3Db

1000*1200**2

5760

5760

1

0.247

7338

12.7

HX600

3Db

2048**3

2048

2048

1

4.99

2217

10.6

JAXA FX1

3Db

1000*1200**2

5760

1440

4

0.228

7966

13.8

HX600

3Da

2048**3

2048

128

16

3.54

151

1.5

1Da䋺1ᰴర㗔ၞಽഀ䇮2Da䋺2ᰴర㗔ၞಽഀ䇮3Da䋺3ᰴర㗔ၞಽഀ䇮3Db䋺3ᰴర㗔ၞಽഀ䋫f(m,i,j,k)ᄙ䉮䉝ᢙ䈱⸘▚䉅㜞ല₸䇮JAXA FX1䈪䈲ᄙ䉮䉝䈪Hybrid䈏Flat MPI䉋䉍䉅㜞ല₸䈱႐ว䉅䈅䈦䈢䇯
35

2Da䋺2ᰴర㗔ၞಽഀ䇮3Da䋺3ᰴర㗔ၞಽഀ䇮3Db䋺3ᰴర㗔ၞಽഀ䋫f(m,i,j,k)ᄢ☸ᐲ⸘▚䈪䈲HX600䈲FX1䉋䉍⸘▚ല₸䈲ૐ䈇䇮䉁䈢䇮⥄േਗ೉ᢙ䉕਄䈕䉎䈫⸘▚ല₸䈏䈎䈭䉍ૐ䈒䈭䉎䇯

36

FX1 Flat MPI
computation

1 dimension
2 dimension
3 dimension

101

3072 core1Computation Time (sec)Computation Time (sec)101

HX600 Flat MPI

1536 coreᄢ☸ᐲᄙ䉮䉝⸘▚

10-1

communication

10-2

101

1

103

102
CPU or Core Number

37

1 dimension
2 dimension
3 dimension

1

communication
10-1

10-2

104

computationㅢାᤨ㑆䈱ഀว䈏FX1䈱
႐ว䈫Ყ䈼䈩ᄢ䈐䈇

1

101

102

103

104

CPU or Core Number

38

MHD䉮䊷䊄䈫Vlasov䉮䊷䊄䈪䈱ᕈ⢻⹏ଔ

MHD䉮䊷䊄䈱ᕈ⢻⹏ଔ
1024core䈪⸘᷹䋨ℂ⺰ᕈ⢻10TFlops䋩
1core䈅䈢䉍256MB䈮⸳ቯ

HX600

FX1
㗔ၞಽഀ䈱ᰴర䉕ᄌᦝ Type A䋺f(i, j, k, m) Type B䋺f(m, i, j, k)i, j, k 䈏ⓨ㑆⇟ภ䇮 m 䈏ᄌᢙ⇟ภЈห䈛ⓨ㑆䈪ᄌᢙ䈮ㅪ⛯䉝䉪䉶䉴
HPC2500䈪䈲᦭ല䈣䈦䈢• FX1䈲HPC2500䈫ห䈛௑ะ
• HX600䈲SSE䈏᦭ല• ታലᕈ⢻䈲䈬䈤䉌䉅⚂21%

39

ฬᄢ䉴䊌䉮䊮䈱䉁䈫䉄

3D MHD䉮䊷䊄䈮䉋䉎⸘▚ㅦᐲ䈱Ყセ
䋨GFlops䋩䊶ฬฎደᄢቇᖱႎၮ⋚䉶䊮䉺䊷䈱ᣂ䉴䊌䉮䊮䉲䉴䊁䊛䈲ታ↪
䈱䋳ᰴరMHD䊒䊨䉫䊤䊛䉕↪䈇䈩ᦼᓙ䈚䈢䈫䈍䉍䈱ᕈ⢻䈏䈪䈩䈇䉎䇯ComputationSpeed
Computation Speede

100000FX1/JAXA

10000

SR16000(SMT)䊶ో࿖ᄢቇ౒ห೑↪ᖱႎၮ⋚䉶䊮䉺䊷䈪໑৻䈱䊒䊥䊕䉺䉮䊮䈪䈅䉎FX1䈲Flat MPI䈱2048 core䈪ᦨ㜞ㅦ
4.3 Tflops䋨⛘ኻല₸21%䋩䉕ታ⃻䈚䈢䇯
1024 core䈪䈱ᦨ㜞ㅦ䈲2.2 Tflops䋨⛘ኻല₸22%䋩䇯

HX600

1000

HA8000(2GB)100

䊶FX1䈱䊊䉟䊑䊥䉾䊄ਗ೉䋨䊒䊨䉶䉴ਗ೉䋫⥄േਗ೉䋩䈲512
node 4 thread䈪4.1 Tflops䋨⛘ኻല₸20%䋩䉕ᓧ䈢䇯

FX1(8GB)

101

mpifrt progmpi.f -o progmpi -Kprefetch_model=FX1 -Z mpilist

SR16000

HPC2500

HX600(4GB)

1

10

100

NumberofCore

1000

40

mpifrt progmpi.f -o progmpi -Kimpact -Kprefetch_model=FX1 -Z mpilist

䊶HX600䈱Flat MPI䈱1024 core䈪䈲ᦨ㜞ㅦ2.2 Tflops䋨⛘ኻല₸21%䋩䉕ᓧ䈢䇯

10000
Number of Core4142㧡㧚⒳‫▚⸘ߩࡦࠦࡄࠬߩޘ‬ㅦᐲߩᲧセߣ⠨ኤ䊑䊤䉸䊐䉮䊷䊄ᕈ⢻⹏ଔ

MHD䉮䊷䊄䈱䊔䊮䉼䊙䊷䉪䊁䉴䊃

SR16000@Kyushu

SR16000@Kyushu

ታⓨ㑆(x,y,z)䉕MPIਗ೉ㅦᐲⓨ㑆䉕OpenMPਗ೉FX1@Nagoya
HX600@Nagoya

HX600@Nagoya(Fujitsu)

1core䈅䈢䉍1G䈮⸳ቯ䈚䈢ᒙ䈇䉴䉬䊷䊥䊮䉫FX1@JAXA

FX1@Nagoya

T2K@Tokyo(Hitachi)̪4096䈫12032䈲JAXA䈪⸘᷹TSUBAME(PGI)

T2K@Tokyo(Intel,PGI)

vz

vy
vx

• HX600䈪ታലᕈ⢻⚂15%• FX1䈪䈲ታലᕈ⢻⚂12%
 T2K@᧲ᄢ䈫䈾䈿หㅦyPEnx+1

PEnx

x
PE0

䊶䊶䊶
PE1
䊶䊶䊶

43

 ⒳䇱䈱䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺䈱⸘▚ㅦᐲ䈱Ყセਗ೉䊔䉪䊃䊦⸘▚ᯏ䈎䉌⿥ਗ೉䉴䉦䊤⸘▚ᯏ䉁䈪ᣂ䈚䈇ᛛⴚ䈮䈧䈇䈩45

 䊔䉪䊃䊦ᯏ䋺Fujitsu䋺VPP5000䇮NEC䋺SX-6䇮SX-8R䇮SX-9䇮ES 䉴䉦䊤ᯏ䋨x86㒰䈒䋩䋺Fujitsu䋺HPC2500䇮FX1䇮PRIMQUEST䇮Hitachi䋺SR16000
 X86ᯏ䋺Hitachi HA8000䇮Fujitsu HX600䇮Sun䋺TSUBAME䇮Fujitsu PRIMERGY
Coreᢙ
/CPUᢙ

ታലᕈ⢻ ℂ⺰ᕈ⢻ ታⴕല₸(GFlops) (GFlops)
(%)

㗔ၞಽഀ

SMT䋨Simultaneous Multithreading䋩䈲᦭ല䈎䋿
Coreౝ䈪ⶄᢙ䈱ታⴕ䉴䊧䉾䊄䉕หᤨ䈮ታⴕ䈜䉎䊒䊨䉶䉾䉰䈱ᯏ⢻
Node – Multi-Core – Multi-Thread

CPU⒳㘃

SX-9

64/64

2058

6553

31

2ᰴర

䊔䉪䊃䊦

HA80008192/1024

10038

75366

13

3ᰴరA

Opteron

HX600

1024/256

2166

10240

21

3ᰴరA

Opteron

FX1

1024/256

2081

10240

21

3ᰴరB

SPARC64VII

SR16000

1344/672

5375

25267

21

3ᰴరB

POWER6

SX-9

HA8000HX600

FX1SR16000@core

1.00000.04000.06580.06320.1244@CPU

1.00000.15950.26310.25280.248744ᣣ┙SR16000䈪䈲SMTലᨐ䈏㗼⪺䈮⃻䉏䉎ን჻ㅢFX1䈪䈲SMTലᨐ䈲ᓸዋ
SMT䉇䉮䉝ౝⶄᢙṶ▚ᯏ䈏䈇䈧䉅ᯏ⢻䈜䉎䈎䈲⇼໧

45䋹䋹䋮䋹䋹䋦䉕⿥䈋䉎ਗ೉ൻ₸䈫䋲䋰䋦⒟ᐲએ਄
䈱⛘ኻല₸䉕ᓧ䉎䈢䉄䈱䊍䊮䊃46੹ᓟ⸃᣿䈜䈼䈐䈖䈫䋱䋮䊒䊨䉫䊤䊛䈱䊜䉟䊮ㇱಽ䈪ో䈩䈱do loop䉕ਗ೉ൻ䋨䋱୘䈪䉅ᱷ䈚䈢䉌䉻䊜䋩䋲䋮ో䈩䈱do loop䈪ਗ೉ൻOK䈱⴫␜䈏಴䈩䉅቟ᔃ䈚䈩䈲䈇䈔䈭䈇䋨ifᢥ䉇᧦ઙᢥ䈲ૐല₸䈱ਗ೉ൻ䉕䉇䈦䈢䈣䈔䈎䉅⍮䉏䈭䈇䋩䈾䈫䉖䈬䈱႐วᢙ୚⒟ᐲ
䋳䋮 ifᢥ䉇᧦ઙᢥ䋨dependency䋩䉕ਗ೉ൻ䈜䉎䈢䉄䈮䈲䇮
Mask, List vector, Gather and scatter䈱ਛ䈎䉌ᦨ䉅ㆡಾ䈭䉅䈱䉕ᦨ䉅ㆡಾ䈭ᣇᴺ䈪૶䈉ᔅⷐ䈏䈅䉎䋴䋮ታ᷹䈜䉎႐ว䈮䈲☸ᐲ䋨䋱୘䈱CPU䈱䊜䊝䊥භ᦭₸䋩䉕ឥ䈋䉎ᔅⷐ䈏䈅䉎䋵䋮ᦨༀ䈱䊁䉴䊃䈲ᦨᄢᢙ䈱CPU䉕↪䈇䈩䇮☸ᐲ䉕ᗧ⼂䈚䈩⛘ኻല₸䉕ታ᷹䈜䉎䈖䈫

䋱䋮Coreᢙ䉕1-10ਁ୘䈫ᦝ䈮Ⴧ䉇䈚䈢႐ว䉅scalability䈲଻䈢䉏䉎䈎䋿䋨䈬䈉䈚䈢䉌੍᷹䈪䈐䉎䈎䋿䋩䋲䋮ㅢା䈲ᧄᒰ䈮䊗䊃䊦䊈䉾䉪䈮䈭䉎䈱䈎䋿䈖䈱㒢⇇䉕᣿⏕䈮␜䈜䈮䈲䈬䈉䈜䉏䈳䉋䈇䈱䈎䋿䋳䋮Cache䈱䊍䉾䊃₸䉕ᦝ䈮਄䈕䉎䈮䈲䈬䈉䈜䉎䈱䈎䋿䋴䋮Flat MPI䈫Hybrid䋨䊒䊨䉶䉴ਗ೉䋫⥄േਗ೉䋩䈲Coreᢙ䈏Ⴧ䈋䈢ᤨ䇮䈬䈤䉌䈏㜞ല₸䈭䈱䈎䋿䋵䋮䉴䊌䉮䊮䈱⒳㘃䈮䉋䈦䈩㜞ല₸䈱䊒䊨䉫䊤䊛䈲⇣䈭䉎䈱䈎䋨FX1ဳ䈫T2Kဳ䋩䋿
47

48

11

10

㧢㧚࿾⃿⏛᳇࿤ߩ㧟ᰴరMHDߣVlasovࠪࡒࡘ࡟࡯࡚ࠪࡦߩ዁᧪

4 times / 3 years or 10 times / 5 years

2D and 3D
MHD
Simulation䊶䈬䈱䉲䉴䊁䊛䈮䈍䈇䈩䉅䈾䈿✢ᒻ䈭䉴䉬䊷䊤䊎䊥䊁䉞䊶䈬䈱䉲䉴䊁䊛䈮䈍䈇䈩䉅䇮ታലല₸䈲10 - 20%એ਄

䋳ᐕ䈪䋴୚䇮
䋵ᐕ䈪䋱䋰୚
⒟ᐲ䈱ഀว
䈪⸘▚ⷙᮨ
䈏Ⴧᄢ

䊶੹ᓟ䈲䇮128 – 1024 䉮䉝䈱ਗ೉⸘▚䈮䉋䉍䇮䉴䉬䊷䊦㑆⚿ว䈱⎇ⓥ䉕ផㅴ4096*4096*4096
2048*2048*2048

1011

䃩㜞⸃௝ᐲ⏛᳇࿤䉫䊨䊷䊋䊦MHD䉲䊚䊠䊧䊷䉲䊢䊮䃩ਛ㑆䉴䉬䊷䊦ⷙᮨ䈱╙৻ේℂ䊑䊤䉸䊐䉲䊚䊠䊧䊷䉲䊢䊮
2008
2010Year49ᢙ୯⸘▚䊶䉲䊚䊠䊧䊷䉲䊢䊮䈱⸘▚ⷙᮨ䊕䉺䉮䊮䋺⚂10ਁCPUએ਄Peta Flops
ᰴ਎ઍ䉴䊌䉮䊮
(䊕䉺䉮䊮)䋨⎇ⓥቶ䋩╙䋱ጀ ⿥ᄢⷙᮨ⸘▚䋺ᖱႎㅪ៤ၮ⋚䉶䊮䉺䊷䈱䉴䊌䉮䊮䉕⿧䈋䈩䈱೑↪
䋨cpuᢙ1000⒟ᐲ䉕⿥䈋䈩䋩䇮䊕䉺䉮䊮೑↪䈏ᔅⷐ╙䋲ጀ ᄢⷙᮨ⸘▚䋺ᖱႎㅪ៤ၮ⋚䉶䊮䉺䊷䈱䉴䊌䉮䊮䉕ᄢⷙᮨ䈮೑↪
䋨cpuᢙ1000⒟ᐲ䉁䈪䋩╙䋳ጀ ਛⷙᮨ䉁䈪䈱⸘▚䋺ฦ䉫䊦䊷䊒ᚲ᦭䈱䉪䊤䉴䉺䊷⸘▚ᯏ䈪䉅⸘▚น⢻䋨cpuᢙ100⒟ᐲ䉁䈪䋩⿥ᄢⷙᮨ⸘▚╙䋱ጀ䉶䊮䉺䊷䈎䉌䈱೑↪⚻〝䉕⸳ቯ䈚䈩ᵴ↪ଦㅴᄢⷙᮨ⸘▚䉴䊌䉮䊮೑↪⠪╙䋲ጀฬฎደᄢቇᖱႎㅪ៤ၮ⋚䉶䊮䉺䊷䉴䊌䉮䊮

䊕䉺䉮䊮೑↪䈱⎇ⓥ⸘↹䈱ౕ૕଀䋨ฬฎደᄢቇ䋩⥄↱䈪ㆡಾ䈭೑↪
ਛⷙᮨ䉁䈪䈱⸘▚䉴䊌䉮䊮೑↪⠪
䋨⎇ⓥቶ䉮䊮䊏䊠䊷䉺೑↪⠪䋩╙䋳ጀฬฎደᄢቇᖱႎㅪ៤ၮ⋚䉶䊮䉺䊷䈱䉴䊌䉮䊮೑↪⠪䈎䉌䉂䈢⸘▚ᯏ⾗Ḯ䈱㓏ጀ⊛㈩⟎51ᄢⷙᮨ㜞♖ᐲ⸘▚䋱䋮⎇ⓥ⺖㗴䋺䉳䉥䉴䊕䊷䉴䈮䈍䈔䉎㗔ၞ㑆⚿ว䋨⏛᳇࿤䈱Ⴚ⇇ጀੂᵹ䈫᭴ㅧᒻᚑ䉕⸃᣿䋩䋲䋮⎇ⓥ䈱᭎ⷐ䋺䊶ᄥ㓁࿾⃿♽䈱Ⴚ⇇ጀ䊒䊤䉵䊙ਇ቟ቯ䈱ᚑ㐳䈮䉋䉎᭴ㅧᒻᚑ䈫䉣䊈䊦䉩䊷䊶‛⾰ャㅍ䊶䊒䊤䉵䊙ੂᵹ䉕੺䈚䈩䈱䊙䉪䊨䈫䊜䉸䉴䉬䊷䊦⚿ว䈱㕖✢ᒻ‛ℂ䈱⸃᣿䋳䋮 ⸘▚䈱᭎ⷐ䋺MHD䇮᜛ᒛMHD ෸䈶ᵹ૕䊝䊂䊦䈮䉋䉎䉫䊨䊷䊋䊦䉲䊚䊠䊧䊷䉲䊢䊮䋴䋮 ⃻࿷䉁䈪䈱೔㆐ᐲ䋺 䋳ᰴరMHD 䉮䊷䊄䈪20%એ਄䈱㜞⸘▚ല₸䋨1024 cpu䋩䋵䋮 䊕䉺䉮䊮䈪⁓䈉䉅䈱䈫䈠䈱⸘▚ⷙᮨ
䊶4096 䈱䋳ਸ਼䈱ᩰሶὐ䉕↪䈇䈩⃻࿷䈱HPC2500 䈪10,000 ᤨ㑆䈱䉥䊷䉻䊷䈱⸘▚㊂䊶ᄙᵹ૕䇮Hall MHD 䇮෸䈶䊒䊤䉵䊙䈫ਛᕈᵹ૕䈱⚿ว䈻䈱᜛ᒛ䈱ᔅⷐᕈᄥ㓁㘑ㅦᐲ䈱ᕆỗ䈭Ⴧᄢ䈮ᔕ╵䈜䉎࿾⃿⏛᳇࿤䈱᭴ㅧᄌൻ䈫ੂᵹᒻᚑ䈱䋳ᰴర䉲䊚䊠䊧䊷䉲䊢䊮earthmagnetic
reconnection

plasmoidᖺᤊ㑆⏛႐䈱࿁ォ䈮䉋䉎⏛᳇䊥䉮䊈䉪䉲䊢䊮㗔ၞ䈱⒖േ䈫䊒䊤䉵䊝䉟䊄᡼಴䈏⷗䉌䉏䉎࿾⃿⏛᳇࿤䈱䋳ᰴర䉲䊚䊠䊧䊷䉲䊢䊮

50

53

䋱䋺 ৻᭽㕖╬ᣇMHDੂᵹ䈱ᷫ⴮ᴺೣ䋲䋺 ᐔⴕᐔ᧼㑆ੂᵹ䈱⿥ᄢⷙᮨ⋥ធᢙ୯⸘▚ 䋴䋭䋶䋺䋳䋺 䉺䊮䊌䉪⾰䈱䉲䊚䊠䊧䊷䉲䊢䊮ᄥ㓁࿾⃿ⅣႺ⎇ⓥᚲ䋴䋺 䉳䉥䉴䊕䊷䉴䈮䈍䈔䉎㗔ၞ㑆⚿ว䈱⎇ⓥ⸘↹䋵䋺 ήⴣ⓭ⴣ᠄ᵄ䈮䉋䉎☸ሶടㅦ䋶䋺 䊑䊤䉸䊐䉲䊚䊠䊧䊷䉲䊢䊮䈪⷗䉎ᖺᤊ⏛᳇࿤䈱3ᰴరㆇേ⺰⊛ឬ௝䋷䋺 ಽሶേജቇᴺ䈮䉋䉎ᶧ⤑⎕უ⃻⽎䈱⋥ធ⸘▚䋸䋺 ᄢⷙᮨ㕖✢ᒻ࿕᦭୯໧㗴䈱⸃ᴺ䈫䈠䈱ᔕ↪
䋹䋺 ↢૕ಽሶ䈱┙૕᭴ㅧ੍᷹䉲䊚䊠䊧䊷䉲䊢䊮10䋺 ᒝ⋧㑐ᄙ૕㔚ሶ♽䉲䊚䊠䊧䊷䉲䊢䊮11䋺 㔕䈱䊋䊷䉼䊞䊦䊥䉝䊥䊁䉞12䋺 ⥄Ꮖ⚵❱ൻ䊙䉾䊒䉕↪䈇䈢᳇୥ᄌേ䈱⹏ଔ
52

䋷䋮䉁䈫䉄
䉴䊷䊌䊷䉴䉦䊤䊷ਗ೉ᯏ䇮䉴䊷䊌䊷䉮䊮䊏䊠䊷䉺䈪ᦨ㜞ㅦ䈱ਗ೉⸘▚䊒䊨䉫䊤䊛䉕૞ᚑ䈜䉎䈢䉄䈮䋱䋮䊒䊨䉫䊤䊛䈱᭴ㅧ䉕⏕┙䈜䉎䈖䈫䈏ᦨ䉅㊀ⷐ䋨Dependency䈱䈭䈇᭴ㅧ䋩䋲䋮䉨䊞䉾䉲䊠䈱䊍䉾䊃₸䉕ᦨᄢൻ䋳䋮ㅢା㊂䈱ᦨዊൻ䈫৻᜝ォㅍ䈖䉏䉌䉕ታ⃻䈚䈩䇮⒳䇱䈱䉴䊌䉮䊮䈮䈍䈇䈩䇮ታലല₸䈲10 - 20%એ਄䉕㆐ᚑ䋴䋮䊒䊨䉫䊤䊛䉰䉟䉵䈱ᦨዊൻ䈲੹ᓟ䈱⋡ᮡ䋨䋱ᰴరൻ䈪㗔ၞಽഀ䈲૶↪ਇน䇮ታ⃻น⢻䈎䋿䋩
54

FX1䈱⸘▚ㅦᐲ䋺䋱ᰴర䉮䊷䊄䋺f(i1)FX1䈫HX600⸘▚ㅦᐲ
䉮䊮
䊏䊠䊷䉺

䊒䊨䉫䊤
䊛

䉫䊥䉾䊄ᢙ

✚䉮䉝
ᢙ

FX1

1Da

1024**3

256

FX1

1Da

1024**3

128

FX1

1Da

1124*1024**2

128

FX1

1Da

602*402*402

FX1

1Da

902*402*402

FX1

1Da

1124*1024**2

128

128

1

8.23

FX1

3Da

1024**3

128

128

1

7.32

HX600

1Da

512**3

64

64

1

4.06

HX600

1Da

1024**3

256

64

4

9.81

䊒䊨䉶䉴
ਗ೉ᢙ

⥄േ
ਗ೉ᢙ

CPUᤨ㑆
(sec)

⸘▚ㅦᐲ
(Gflops)

ല₸
(%)

64

4

128

1

152.0

9

0.4

232.2

6

128

0.5

1

28.4

52

4.1

256
256

64

4

0.417

294

64

4

0.704

261

䊶1ᰴర㈩೉f(i1)MHD䉮䊷䊄䈲䊜䊝䊥䉕ᦨዊൻ䈚䈢䊒䊨䉫䊤䊛䊶㗔ၞಽഀᴺ䉕೑↪䈪䈐䈭䈇䈱䈪ᣂ䈚䈇䊡䊷䉱䊷䋨䊒䊨䉫䊤䊛䋩
ಽഀᴺ䈱㐿⊒䈏ᔅⷐ䉮䊮䊏䊠䊷䉺 䉫䊥䉾䊄ᢙ

✚䉮䉝
ᢙ

䊒䊨䉶䉴
ਗ೉ᢙ

⥄േ
ਗ೉ᢙ

11.5

FX1

62*32*32

4

1

10.2

FX1

602*302*302

4

1

180

14.1

FX1

802*402*402

4

185

14.4

FX1

1002*502*502

4

42

6.5

FX1

50*50*26

138

5.4

FX1

1Da䋺1ᰴర㗔ၞಽഀ䋫f(i,j,k,m) m䋺 MHDᣇ⒟ᑼ䈱8୘ᚑಽ
2Da䋺2ᰴర㗔ၞಽഀ䋫f(i,j,k,m)
3Da䋺3ᰴర㗔ၞಽഀ䋫f(i,j,k,m) 3Db䋺䋳ᰴర㗔ၞಽഀ䋫f(m,i,j,k)1ᰴర㗔ၞಽഀ䉅㈩೉ᢙ䉕ㆡಾ䈮ㆬ䈼䈳䈎䈭䉍䈱⸘▚ㅦᐲ䈏ᓧ䉌䉏䉎䇯

CPUᤨ㑆
(sec)

⸘▚ㅦᐲ
(Gflops)

ല₸
(%)

4

0.0227

3.5

8.8

4

14.4

4.8

12.0

1

4

32.6

5.0

12.5

1

4

65.7

4.8

12.1

4

1

4

0.02383.4

8.6

402*402*202

4

1

4

8.78

4.7

11.7

FX1

602*602*302

4

1

4

28.9

4.8

11.9

FX1

802*802*402

4

1

4

66.7

4.9

12.2

f(i1): i1=i+n1*(j-1)+n2*(k-1)+n3*(m-1), n1=nx2, n2=n1*ny2, n3=n2*nz2
f(i1)=f(i,j,k,m), f(n4)=f(nx2,ny2,nz2,nb), n4=n3*nb
55

56