Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Alex Y. Kwok

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

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

Systems, architecture and hardware · 2Software engineering, systems software and programming languages · 2

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
Processor architecture and microarchitecture · 44% Performance modeling and evaluation · 32% High-performance computing · 19%
Software engineering, system software, and programming languages
1 paper
Compilers and program optimization · 100%

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

TopicWeightPapersLastEvidence papers
Compilers and program optimization
instruction scheduling
0.011991
The Floating-Point Performance of a Superscalar SPARC Processor · ASPLOS 1991
Compilers and program optimization › instruction scheduling
software pipelining
0.011991
The Floating-Point Performance of a Superscalar SPARC Processor · ASPLOS 1991
Processor architecture and microarchitecture
superscalar processor
0.011991
The Floating-Point Performance of a Superscalar SPARC Processor · ASPLOS 1991
Performance modeling and evaluation
benchmarking
0.011991
The Floating-Point Performance of a Superscalar SPARC Processor · ASPLOS 1991
Memory systems › memory interference
memory bank conflicts
0.011985
Performance Prediction Tools for Cedar: A Multiprocessor Supercomputer · ISCA 1985

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

software pipelining · 0.0loop unrolling · 0.0simulation · 0.0mean value analysis · 0.0
YearPublicationVenuePosition
1991 The Floating-Point Performance of a Superscalar SPARC Processor
abstract
The floating point performance of superscalar SPARC processors is evaluated based on empirical data horn 12 benchmarks.This evaluation is done in the context of two software instruction scheduling optimization, loop unrolling and software pipelining, and for three machine models we term, 1-scalar, 2-scalar and 4-scalar.We also consider the effect of the memory system on the performance improvements.Superscalar hardware alone exhibit little performance improvement without software optimization.Of the two scheduling methods we study, software pipelining more effectively takes advantage of increased hardware parallelism, and achieves near optimal speedup on the 4-scalar machine model.The performance of loop unrolling is restricted by the limited number of floating point registers in the SPARC architecture.The best performance level is obtained by applying both optimization techniques.A superscalar SPARC processor can provide improved tloating point performance but with significant software and hardware development costs.
Roland L. Lee, Alex Y. Kwok, Faye A. Briggs
ASPLOS2
1985 Performance Prediction Tools for Cedar: A Multiprocessor Supercomputer
abstract
The development of performance prediction tools for highspeed machine organizations has been recognized as a key problem facing the research community in parallel computing [BrAI84].This paper presents a survey of the tools which has been developed for performance prediction of the Cedar multiproce~or supercomputer of the University of Illinois.The system is deterministic, modular, and automatic.The hierarchical organization of the system provides the user with the ability to choose from a set of alternatives for predicting the performance with different levels of accuracy and cost.Using 22 programs, we measure the performance degradation due to conflicts in the shared memory, delay in the Cedar interconnection network, and synchronization overhead.The results confirm that the architecture of Cedar as detailed in [GLYZ84] is balanced.The performance of the Cedar interconnectiou network is very close to a crossbar.Synchronization overhead and shared memory conflicts could degrade performance for some programs considerably.
Walid A. Abu-Sufah, Alex Y. Kwok
ISCA2