DOCSLIB.ORG

Cacheminer: a Runtime Approach to Exploit Cache Locality on SMP

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Cacheminer: a Runtime Approach to Exploit Cache Locality on SMP IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 11, NO. 4, APRIL 2000 357 Cacheminer: A Runtime Approach to Exploit Cache Locality on SMP Yong Yan, Member, IEEE Computer Society, Xiaodong Zhang, Senior Member, IEEE, and Zhao Zhang, Member, IEEE AbstractÐExploiting cache locality of parallel programs at runtime is a complementary approach to a compiler optimization. This is particularly important for those applications with dynamic memory access patterns. We propose a memory-layout oriented technique to exploit cache locality of parallel loops at runtime on Symmetric Multiprocessor (SMP) systems. Guided by application-dependent and targeted architecture-dependent hints, our system, called Cacheminer, reorganizes and partitions a parallel loop using the memory- access space of its execution. Through effective runtime transformations, our system maximizes the data reuse in each partitioned data region assigned in a cache, and minimizes the data sharing among the partitioned data regions assigned to all caches. The executions of tasks in the partitions are scheduled in an adaptive and locality-preserved way to minimize the execution time of programs by trading off load balance and locality. We have implemented the Cacheminer runtime library on two commercial SMP servers and an SimOS simulated SMP. Our simulation and measurement results show that our runtime approach can achieve comparable performance with the compiler optimizations for programs with regular computation and memory-access patterns, whose load balance and cache locality can be well optimized by the tiling and other program transformations. However, our experimental results show that our approach is able to significantly improve the memory performance for the applications with irregular computation and dynamic memory access patterns. These types of programs are usually hard to optimize by static compiler optimizations. Index TermsÐCache locality, nested loops, runtime systems, simulation, symmetric multiprocessors (SMP), and task scheduling. æ 1INTRODUCTION HE recent developments in circuit design, fabrication improvement on the memory performance of applications Ttechnology, and Instruction-Level Parallelism (ILP) is critical to the successful use of SMP systems for technology have increased microprocessor speed about applications. 100 percent every year. However, memory-access speed In order to narrow the processor-memory speed gap, has only improved about 20 percent every year. In a hardware caches have been widely used to build a memory modern computer system, the widening gap between hierarchy in all kinds of computers, from supercomputers processor performance and memory performance has to personal computers. The effectiveness of the memory become a major bottleneck to improving overall computer hierarchy for improving performance of programs comes performance. Since the increase in memory-access speed from the locality property of both instruction executions cannot match that of the processor speed, memory-access contention is increased, which results in a longer memory- and data accesses of programs. In a short period of time, the access latency. This makes memory-access operations much execution of a program tends to stay in a set of instructions more expensive than computation operations. In multi- close in time or close in the allocation space of a program, processor systems, the effect of the widening processor- called the instruction locality. Similarly, the set of instruc- memory speed gap on performance becomes more sig- tions executed tends to access data that are also close in nificant due to the heavier access contention on the network time or in the allocation space, called the data locality. Using and the shared memory and to the cache coherence cost. a fast and small cache close to a CPU is expected to hold the Recently, Symmetric Multi-Processor (SMP) systems have working set of a program so that memory accesses can be emerged as a major class of parallel computing platforms, avoided or reduced. such as HP/Convex Exemplar S-class [3], SGI Challenge [7], Unfortunately, the memory hierarchy is not a panacea Sun SMP servers [5], and DEC AlphaServer [19]. SMPs dominate the server market for commercial applications for eliminating the processor-memory performance gap. and are used as desktops for scientific computing. They are Low-level memory accesses are still substantial for many also important building blocks for large-scale systems. The applications and are becoming more expensive as the processor-memory performance gap continues to widen. The reasons for possible slow memory accesses are: . Y. Yan is with the Computer Systems Labs, Hewlett Packard Laboratories, Palo Alto, CA 94304. Email: [email protected]. Applications may not be programmed with an . X. Zhang and Z. Zhang are with the Computer Science Department, awareness of the memory hierarchy. College of William and Mary, Williamsburg, VA 23187-8709. E-mail: {zhang, zzhang}@cs.wm.edu. Applications have a wide range of working sets which cannot be held by a hardware cache, resulting Manuscript received 1 Oct. 1997; revised 24 June 1999; accepted 6 Jan. 2000. For information on obtaining reprints of this article, please send e-mail to: in capacity misses at cache levels of the memory [email protected], and reference IEEECS Log Number 105746. hierarchy. 1045-9219/00/$10.00 ß 2000 IEEE 358 IEEE TRANSACTIONS ON PARALLEL AND DISTRIBUTED SYSTEMS, VOL. 11, NO. 4, APRIL 2000 . The irregular data-access patterns of applications result in excessive conflict misses at cache levels of the memory hierarchy. In a time-sharing system, the dynamic interaction among concurrent processes and the underlying operating system causes a considerable amount of memory accesses as processes are switched in context. This effect cannot be handled by the memory hierarchy on its own. In a cache coherent multiprocessor system, false data sharing and true data sharing result in considerable cache coherent misses. In a CC-NUMA system, processes may not be perfectly co-located with their data, which results Fig. 1. SMP shared memory system model. in remote memory accesses to significantly degrade overall performance. global memory. When a processor accesses its data, it first Due to the increasing cost of memory accesses, techni- looks up the cache hierarchy. If the data is not found in ques for eliminating the effect of long memory latency have caches, the processor reads the memory block that contains been intensively investigated by researchers from applica- the required data from the shared memory and brings a tion designers to hardware architects. In general, the copy of the memory block in an appropriate cache block in proposed techniques fall into two categories: latency the cache hierarchy. Data is copied into the cache hierarchy avoidance and latency tolerance. The latency tolerance so that the subsequent accesses to the data can be satisfied techniques are aimed at hiding the effect of memory-access from the cache and memory accesses can be avoided. The latencies by overlapping computations with communica- cache locality optimization is aimed at optimizing the tions or by aggregating communications. The latency cache-access pattern of an application so that memory avoidance techniques, also called locality optimization accesses can be satisfied in the cache as often as possible (or techniques, are aimed at minimizing memory accesses by in other words, cache data can be reused as much as using software and/or hardware techniques to maximize possible). To increase the chance of cache data to be reused, the reusability of data or instructions at cache levels of we must reduce the interference that would replace or the memory hierarchy. In a SMP system, reducing the total invalidate the cache data. In a SMP system, there are two number of memory accesses is a substantial solution to types of interference that would affect the reuse of cache reduce cache coherence overhead, memory contention, data: the interference from the local processor which refills and network contention. So, the locality optimization a cache block with new data, and the interference from a techniques, i.e., the latency avoidance techniques, are more remote processor which invalidates stale data copies to demanding than the latency tolerance techniques. In maintain data consistency. The two types of interference in addition, because instruction accesses are more regular a parallel computation are determined by how the data is than data accesses, designing novel data-locality optimiza- accessed in the computation, called the data-access pattern, tion techniques is more challenging and more important for and how the data is mapped into a cache, called the cache- performance improvement. mapping pattern. Hence, it is essential for a cache locality The objective of this work is to propose and implement optimization technique to obtain and use the information an efficient technique to optimize the data cache locality of on the data-access pattern and the cache-mapping pattern parallel programs on SMP systems. The contributions of of a parallel program. this work are: 1) We propose an effective cache locality The data-access pattern of a program is determined by exploitation method on SMP multiprocessors based on program characteristics. Because the compilation time of an simple runtime information, which is complimentary to application is not a part of its execution time, a compiler can compiler optimizations. To our knowledge based
Load more

Recommended publications
  • System Administration
    System Administration Varian NMR Spectrometer Systems With VNMR 6.1C Software Pub. No. 01-999166-00, Rev. C0503 System Administration Varian NMR Spectrometer Systems With VNMR 6.1C Software Pub. No. 01-999166-00, Rev. C0503 Revision history: A0800 – Initial release for VNMR 6.1C A1001 – Corrected errors on pg 120, general edit B0202 – Updated AutoTest B0602 – Added additional Autotest sections including VNMRJ update B1002 – Updated Solaris patch information and revised section 21.7, Autotest C0503 – Add additional Autotest sections including cryogenic probes Applicability: Varian NMR spectrometer systems with Sun workstations running Solaris 2.x and VNMR 6.1C software By Rolf Kyburz ([email protected]) Varian International AG, Zug, Switzerland, and Gerald Simon ([email protected]) Varian GmbH, Darmstadt, Germany Additional contributions by Frits Vosman, Dan Iverson, Evan Williams, George Gray, Steve Cheatham Technical writer: Mike Miller Technical editor: Dan Steele Copyright 2001, 2002, 2003 by Varian, Inc., NMR Systems 3120 Hansen Way, Palo Alto, California 94304 1-800-356-4437 http://www.varianinc.com All rights reserved. Printed in the United States. The information in this document has been carefully checked and is believed to be entirely reliable. However, no responsibility is assumed for inaccuracies. Statements in this document are not intended to create any warranty, expressed or implied. Specifications and performance characteristics of the software described in this manual may be changed at any time without notice. Varian reserves the right to make changes in any products herein to improve reliability, function, or design. Varian does not assume any liability arising out of the application or use of any product or circuit described herein; neither does it convey any license under its patent rights nor the rights of others.
    [Show full text]
  • Ross Technology RT6224K User Manual 1 (Pdf)
    Full-service, independent repair center -~ ARTISAN® with experienced engineers and technicians on staff. TECHNOLOGY GROUP ~I We buy your excess, underutilized, and idle equipment along with credit for buybacks and trade-ins. Custom engineering Your definitive source so your equipment works exactly as you specify. for quality pre-owned • Critical and expedited services • Leasing / Rentals/ Demos equipment. • In stock/ Ready-to-ship • !TAR-certified secure asset solutions Expert team I Trust guarantee I 100% satisfaction Artisan Technology Group (217) 352-9330 | [email protected] | artisantg.com All trademarks, brand names, and brands appearing herein are the property o f their respective owners. Find the Ross Technology RT6224K-200/512S at our website: Click HERE 830-0016-03 Rev A 11/15/96 PRELIMINARY Colorado 4 RT6224K hyperSPARC CPU Module Features D Based on ROSS’ fifth-generation D SPARC compliant — Zero-wait-state, 512-Kbyte or hyperSPARC processor — SPARC Instruction Set Architec- 1-Mbyte 2nd-level cache — RT620D Central Processing Unit ture (ISA) Version 8 compliant — Demand-paged virtual memory (CPU) — Conforms to SPARC Reference management — RT626 Cache Controller, Memory MMU Architecture D Module design Management, and Tag Unit — Conforms to SPARC Level 2 MBus — MBus-standard form factor: 3.30” (CMTU) Module Specification (Revision 1.2) (8.34 cm) x 5.78” (14.67 cm) — Four (512-Kbyte) or eight D Dual-clock architecture — Provides CPU upgrade path at (1-Mbyte) RT628 Cache Data Units module level (CDUs) Ċ CPU scaleable up to
    [Show full text]
  • 12 MULTICHIP MODULES (Mcms)
    12 MULTICHIP MODULES (MCMs) HISTORICAL PERSPECTIVE Virtually every large computer manufacturer, telecommunications products manufacturer, high volume consumer electronics manufacturer and aerospace products manufacturer is working on or considering designs that include multichip modules. There has been a dramatic increase in activity over the last five years, with entire conferences being dedicated to multichip modules. MCMs have gone through three phases in their growth. Phase one was the widespread use in mainframe and super computer products. Some examples of MCMs used for these high-end applications are shown in Figure 12-1. The primary driving force was performance. These systems were predominately ECL based, with relatively low inte- gration levels. The MCM implementation allowed the Òre-integrationÓ of the LSI chips into VLSI modules, while keeping the wiring delays small. Source: DEC Source: IBM Source: Motorola/Siemens Source: ICE, “Roadmaps of Packaging Technology” 22555 Figure 12-1. Early MCMs in ECL Mainframe Computers in the Mid 1980Õs INTEGRATED CIRCUIT ENGINEERING CORPORATION 12-1 Multichip Modules (MCMs) Using a conventional single chip package and circuit board interconnect strategy, the package and interconnects took up over 50% of the timing budget. Decreases in the chip delays could not have much impact on system performance without a significant decrease in the interconnect delays as well. The use of MCMs reduced the interconnect delays significantly. This is shown in Figure 12-2 com- paring the delays in the IBM 3033 with a CPU using single chip packages and four circuit boards, and the IBM 3081, the first mainframe that used the Thermal Conduction Module (TCM).
    [Show full text]
  • Hypersparc Module Installation Guide E ROSS Technology, Inc
    TM hyperSPARC Module Installation Guide E ROSS Technology, Inc. 5316 Highway 290 West Austin, Texas 78735 U.S.A. All rights reserved. This product and related documentation is protected by copyright and distributed under licenses re- stricting its use, copying, distribution, and decompilation. No part of this product or related documentation may be repro- duced in any form by any means without prior written authorization of ROSS Technology and its licensors, if any. Portions of this product may be derived from the UNIXR and Berkeley 4.3 BSD systems, licensed from UNIX Systems Laboratories, Inc. and the University of California, respectively. Third party font software in this product is protected by copyright and licensed from Sun’s Font Suppliers. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19. The product described in this manual may be protected by one or more U.S. patents, foreign patents, or pending applica- tions. TRADEMARKS: ROSS, ROSS Technology, and the ROSS Technology, Inc. logo are registered trademarks of ROSS Technology, Inc. hyperSPARC is a trademark of SPARC International, Inc. and is licensed exclusively to ROSS Technology, Inc. Sun, Sun Microsystems, and the Sun logo are trademarks or registered trademarks of Sun Microsystems, Inc. UNIX, and OPEN LOOK are registered trademarks of UNIX System Laboratories, Inc. All other product names mentioned herein are the trademarks of their respective owners. All SPARC trademarks, including the SCD Compliant Logo, are trademarks or registered trademarks of SPARC Interna- tional, Inc.
    [Show full text]
  • Computer Architectures an Overview
    Computer Architectures An Overview PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information. PDF generated at: Sat, 25 Feb 2012 22:35:32 UTC Contents Articles Microarchitecture 1 x86 7 PowerPC 23 IBM POWER 33 MIPS architecture 39 SPARC 57 ARM architecture 65 DEC Alpha 80 AlphaStation 92 AlphaServer 95 Very long instruction word 103 Instruction-level parallelism 107 Explicitly parallel instruction computing 108 References Article Sources and Contributors 111 Image Sources, Licenses and Contributors 113 Article Licenses License 114 Microarchitecture 1 Microarchitecture In computer engineering, microarchitecture (sometimes abbreviated to µarch or uarch), also called computer organization, is the way a given instruction set architecture (ISA) is implemented on a processor. A given ISA may be implemented with different microarchitectures.[1] Implementations might vary due to different goals of a given design or due to shifts in technology.[2] Computer architecture is the combination of microarchitecture and instruction set design. Relation to instruction set architecture The ISA is roughly the same as the programming model of a processor as seen by an assembly language programmer or compiler writer. The ISA includes the execution model, processor registers, address and data formats among other things. The Intel Core microarchitecture microarchitecture includes the constituent parts of the processor and how these interconnect and interoperate to implement the ISA. The microarchitecture of a machine is usually represented as (more or less detailed) diagrams that describe the interconnections of the various microarchitectural elements of the machine, which may be everything from single gates and registers, to complete arithmetic logic units (ALU)s and even larger elements.
    [Show full text]
  • Colorado 3 RT6226N Hypersparc™ Dual CPU Module/Power Module
    830-0058-00 Rev A 11/15/96 Colorado 3 RT6226N hyperSPARC DualĆCPU Module/Power Module Features D Based on ROSS’ fourth-generation — Hardware support for symmetric, — Zero-wait-state, 512-Kbyte or hyperSPARC processor shared-memory multiprocessing 1-Mbyte 2nd-level cache D Each module consists of two complete — Level 2 MBus support for cache — Demand-paged virtual memory SPARC CPUs coherency management D Each processor includes D SPARC compliant D Module design — RT620C Central Processing Unit — SPARC Instruction Set Architec- — CPU Module fits in MBus-standard (CPU) ture (ISA) Version 8 compliant form factor: 3.30” (8.34 cm) x 5.78” — RT626 Cache Controller, Memory — Conforms to SPARC Reference (14.67 cm) Management, and Tag Unit MMU Architecture — Power Module attaches to the rear (CMTU) — Conforms to SPARC Level 2 MBus of the CPU module through a stan- — Four (512-Kbyte) or eight Module Specification (Revision 1.2) dard 25-pin D shell connector (1-Mbyte) RT628 Cache Data Units D Dual-clock architecture — Provides CPU upgrade path at (CDUs) module level Ċ CPU scaleable up to 142 MHz Ċ IntraĆModule Bus incorporates low — Advanced packaging technology voltage logic to reduce power and— MBus scaleable up to 66 MHz for a compact design D increase speed Each hyperSPARC processor features D High performance * — Dual-level caches — Superscalar SPARC CPU with inte- — 174 SPECint92 (per CPU) D Full multiprocessing implementation grated floating point unit and 8-Kbyte instruction cache — 212 SPECfp92 (per CPU) * in a 50MHz MBus system CPU Module PLL CPU0 RT620C CPU1 RT620C Clock CPU CPU Generator IMCLK IMCLK +5V IMA[31:0] IMA[31:0] Power Module IMD[63:0] IMD[63:0] RT626 RT626 CMTU RT628 RT628 CMTU RT628 RT628 CDU CDU CDU CDU MBus (Level 2) Figure 1.
    [Show full text]
  • Strategic Interactions in Dram and Risc Technology: a Network Approach
    Strategic interactions in dram and risc technology: A network approach Geert Duysters & Wim Vanhaverbeke 93.023 September 1993 MERIT, P.O. Box 616, 6200 MD Maastricht (Netherlands) - telephone (31)43-883875- fax: (31)43-216518 1 STRATEGIC INTERACTIONS IN DRA AND RISC TECHNOLOGY: A NETWORK APPROACH Geert Duysters and WiI Vanhaverbeke1 INTRODUCTION Cooperative agreements have been ignored in business literature for a veiy long time. Only recently, the use of cooperative agreements as part of corporate strategies gained substantial interest. This increase in attention is above all due to the fact that in the last decade the number of cooperative agreements by firms has rocketed. In fact cooperative agreements have outnumbered the fully owned foreign subsidiaries (Contractor and Lorange, 1988). In this paper we will use the term cooperation to denote cooperative agreements between partners which are not connected through (majority) ownership. A cooperative agreement can be seen as an agreement which is positioned between two extremes, arm's length transactions on the one hand and the merger of the two firs on the other hand. Cooperation among companies is usually analyzed in strategic management literature on the dyadic level or on the level of the partcipating firs. Only recently, interest by economists has grown to study cooperative efforts of firs within an inter-organisational network framework (see e.g. Hagedoom and Schakenraad. 1990, 1992, 1993). In high- tech industries where almost all incumbents are linked to each other by means of a network of cooperative agreements, an analysis on the level of the individual players or allances is not appropriate to understand the strategic value of cooperative strategies.
    [Show full text]
  • Company Backgrounder R
    Company Backgrounder R The SPARCTM Solutions Company ROSS Technology, Inc., in its commitment to provide leading-edge SPARCTM solu- tions, offers a full range of hardware products that provide the performance, soft- ware compatibility, and upgradeability demanded by our worldwide market. Our design expertise ranges from SPARC microprocessors and motherboards to com- plete workstations and servers. Founded in 1988, ROSS has supplied high-performance microprocessors to SPARC systems OEMs such as Sun Microsystems, Fujitsu, Tatung, Axil, and ICL, to name a few. To increase our marketshare, ROSS established a program to provide hyperSPARCTM multiprocessing CPU upgrades to end users of Sun SPARCstationTM 10, 20 and SPARCserverTM 600MP systems. Our success in this new market led to the development of motherboard upgrade kits for SPARCstation 5 systems that enable full multiprocessing performance (up to four CPUs) at a cost far below that of a comparable new system. The commitment, experience and design exper- tise developed in the areas of multiprocessing, upgradeability and the SPARC architecture have established ROSS as a leader in the SPARC community and have contributed to the outstanding overall success of SPARC systems in the worksta- tion market today. In keeping with our commitment to provide solutions to the increasing demands of our customers, ROSS recently introduced SPARCplugTM and hyperSTATIONTM workstations. Available in several configurations ranging from a plug-in worksta- tion module for a tower PC to full servers, SPARCplug workstations provide SPARCstationTM 20-level performance in a reduced form factor and at a lower cost. For customers with even greater performance needs, ROSS hyperSTATION work- stations and hyperSERVERTM systems extend the state-of-the-art of 32-bit multipro- cessing to new levels and offer an extensive upgrade path to satisfy future require- ments.
    [Show full text]
  • Solaris 8 (SPARC Platform Edition) Online Release Notes Update
    Solaris 8 (SPARC Platform Edition) Online Release Notes Update Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303–4900 U.S.A. Part Number 806-3771–10 February 2000 Copyright 2000 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, California 94303-4900 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, the Sun logo, docs.sun.com, AnswerBook, AnswerBook2, SunStore, Java, JDK, Solaris Web Start, JumpStart, NFS, HotJava, DiskSuite, Solstice AdminSuite, SunLink, Solstice AutoClient, and Solaris are trademarks, registered trademarks, or service marks of Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK and SunTM Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry.
    [Show full text]
  • Sparcstation 20 Service Manual
    SPARCstation 20 Service Manual Sun Microsystems Computer Company A Sun Microsystems, Inc. Business 901 San Antonio Road Palo Alto, CA 94303-4900 USA 650 960-1300 fax 650 969-9131 Part No.: 801-6189-12 Revision A, July 1996 Send comments about this document to: [email protected] 1997 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, California 94303-4900 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Portions of this product may be derived from the UNIX® system, licensed from Novell, Inc., and from the Berkeley 4.3 BSD system, licensed from the University of California. UNIX is a registered trademark in the United States and in other countries and is exclusively licensed by X/Open Company Ltd. Third-party software, including font technology in this product, is protected by copyright and licensed from Sun’s suppliers. RESTRICTED RIGHTS: Use, duplication, or disclosure by the U.S. Government is subject to restrictions of FAR 52.227-14(g)(2)(6/87) and FAR 52.227-19(6/87), or DFAR 252.227-7015(b)(6/95) and DFAR 227.7202-3(a). Sun, Sun Microsystems, the Sun logo, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc.
    [Show full text]
  • FIVE Documentation Sorenson Workstation
    The Sorenson Workstation FIVE Data by Olav Sorenson Jeffrey S. Skoll Chair in Technical Innovation and Entrepreneurship Professor of Strategic Management Joseph L. Rotman School of Management University of Toronto ©2008 Sorenson Workstation FIVE Data 2 Contents 1. Conditions of Use................................................................................................3 2. Data Set Author ...................................................................................................4 3. Data Set Summary...............................................................................................4 4. Author’s Research Using This Data Set..............................................................4 5. Additional References .........................................................................................5 6. Data Set Sources..................................................................................................5 7. Data Description..................................................................................................5 7.1. Product/Industry Definition...........................................................................6 7.2. Excluded Fields .............................................................................................7 8. Tables ..................................................................................................................8 8.1. Descriptive Statistics, File 1: SorensonworkprodFIVEdata.........................8 8.2. Descriptive Statistics, File 2: SorensonworkfirmFIVEdata
    [Show full text]
  • Benchmarks Are They Really Useful?
    Session 1520 Benchmarks - Are they Really Useful? A Boyanich, S P Maj Department of Computer Science Edith Cowan University Western Australia [email protected] Abstract Benchmarking is an important commercial tool, which can be used for quantifying the performance of computer and network equipment. Furthermore, benchmarks are potentially valuable as part of curriculum studies in computer and network technology. Benchmarks may be of value to support the understanding of different architectural features and their effect on equipment performance. In effect the benchmarking results may provide a tangible metric that can be related directly not only to various architectural features but also the interactions between different levels in the memory hierarchy, hence providing a method of quantifying different performances of differing computer architectures and configurations. In this context a wide range of benchmarks were tested using the criteria of: repeatability, comparability, consistency, use of meaningful units etc. The criteria selected are based on the fundamental principles of measurement science. Our results clearly indicated that different benchmarking suites gave significantly different results for the same equipment. Also each benchmark failed to give consistent results, when compared to other benchmarks, even on identical equipment. Furthermore many of the benchmarks provided performance data in arbitrary units that were difficult to relate to expected changes in performance. In effect every benchmark tested failed to meet the evaluation criteria. The authors offer an alternative benchmarking method that is designed to meet such criteria and experimental work to date indicates some success using this new metric. This paper presents results of this work and gives recommendations regarding the use of benchmarks in computer education courses.
    [Show full text]