Roman Atachiants

dblp:144/5320 · DBLP profile ↗
← Back
2ranked-venue papers
2as first author
0since 2021 · last 2016
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 1 · 1 first-authorHuman-computer interaction and ubiquitous computing · 1 · 1 first-author

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer architecture, parallel and distributed computing, and storage systems
2 papers
Parallel and multicore computing · 59% Performance modeling and evaluation · 41%
Software engineering, system software, and programming languages
1 paper
Debugging and program repair · 100%

Topics — the 3 heaviest of 5, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Parallel and multicore computing
parallel programming environment
0.212014
Design considerations for parallel performance tools · CHI 2014
Debugging and program repair › concurrent program debugging
parallel program debugging
0.112014
Design considerations for parallel performance tools · CHI 2014
Performance modeling and evaluation
performance analysis tools
0.112014
Design considerations for parallel performance tools · CHI 2014

Methods — techniques the papers use, named apart from their topics

systematic analysis · 0.4qualitative interviews · 0.4survey · 0.2expert validation · 0.2
YearPublicationVenuePosition
2016 Parallel Performance Problems on Shared-Memory Multicore Systems: Taxonomy and Observation
abstract
The shift towards multicore processing has led to a much wider population of developers being faced with the challenge of exploiting parallel cores to improve software performance. Debugging and optimizing parallel programs is a complex and demanding task. Tools which support development of parallel programs should provide salient information to allow programmers of multicore systems to diagnose and distinguish performance problems. Appropriate design of such tools requires a systematic analysis of the problems which might be identified, and the information used to diagnose them. Building on the literature, we put forward a potential taxonomy of parallel performance problems, and an observational model which links measurable performance data to these problems. We present a validation of this model carried out with parallel programming experts, identifying areas of agreement and disagreement. This is accompanied with a survey of the prevalence of these problems in software development. From this we can identify contentious areas worthy of further exploration, as well as those with high prevalence and strong agreement, which are natural candidates for initial moves towards better tool support.
Roman Atachiants, Gavin Doherty, David Gregg
IEEE Trans. Software Eng.1
2014 Design considerations for parallel performance tools
abstract
In recent years there has been a shift in microprocessor manufacture from building single-core processors towards providing multiple cores on the same chip. This shift has meant that a much wider population of developers are faced with the task of developing parallel software: a difficult, time consuming and expensive process. With the aim of identifying issues, emerging practices and design opportunities for support, we present in this paper a qualitative study in which we interviewed a range of software developers, in both industry and academia. We then perform a systematic analysis of the data and identify several cross-cutting themes. These analysis themes include the practical relevance of the probe effect, the significance of orchestration models in development and the mismatch between currently available tools and developers' needs. We also identify an important characteristic of parallel programming, where the process of optimisation goes hand in hand with the process of debugging, as opposed to clearer distinctions which may be made in traditional programming. We conclude with reflection on how the study can inform the design of software tools to support developers in the endeavour of parallel programming.
Roman Atachiants, David Gregg, Kim Jarvis, Gavin Doherty
CHI1