Skip to main content

Posts

On processor performance in the age of multi-core, part 1.

Processor performance in the age of multi-core: RISC vs. CISC, part 1. Reading Apple’s announcement in the news media and trade press about a plan to transition its next generation Mac computers from Intel-manufactured x64 processors to custom ARM chips prompted me to write a blog entry discussingApple’s strategy in greater depth and, hopefully, with more insight than the coverage of the move that published reports provided. An issue raised by one of the computer industry experts that analyzed the Apple announcement was that it might re-ignite an old debate among CPU hardware engineers with regard to the relative virtues of the CISC vs. RISC approaches to processor design. This seems very unlikely to me, and I will attempt to explain why in this post. Basically, RISC has won the engineering battle, but meanwhile Intel has good reasons to continue to resist any breaking changes in its hardware platform that would cause existing x86 and x64 software to fail. What is actually the most i
Recent posts

Analyzing Apple’s decision to migrate Macs from Intel processors to ARM

In late June, Apple announced plans to transition its next generation Mac computers from Intel-manufactured x64 processors to custom ARM chips, something which Apple has branded as “Apple Silicon,” highlighting the provenance of the new hardware. Later this year when the first Apple Silicon-based Macs begin to roll out, the company’s line of Mac portable and desktop computers will be using the same ARM processors that Apple is currently using in its iPhone and iPad  products. While there has been ample coverage of this news in the trade press, much of the commentary I have seen online from various technology pundits ( here is a representative sample analysis from one of these self-anointed experts) misses many key aspects of Apple’s recent decision. Apples’s move warrants a better and more complete analysis. In brief, moving off of Intel processors and on to ARM CPUs is not a huge deal, but it is a very smart move. What is fundamentally significant about the decision to switch to t

Caching Strategies for High Performance -- Introduction

Caching Strategies for High Performance In the fall of 2018 I had the opportunity for the first time to teach a seminar in Performance Engineering to graduate students at the University of Washington's Allen School for Computer Science and Engineering (CSE) in Seattle, near where I live. Conceptually, I built the class around the investigation of web application performance that I originally published on this blog beginning here . In structuring the content of the class, I was also fortunate in being able to take advantage of Andre Bondi's very readable textbook, Foundations of Software Performance Engineering . Dr. Bondi's excellent book is informed by his academic background in analytic queuing modeling, along with extensive professional experience with performance stress testing, both areas of expertise that complement my background and experience with its emphasis on instrumentation, measurement tools, and empirical studies of hardware and application performance. If

Interpreting Windows performance gathered from VMware and Hyper-V Guest Machines

In this blog entry, I want to step back and revisit a topic I have blogged about much earlier ( see  https://performancebydesign.blogspot.com/search/label/VMware . ) and discuss how guest machine performance counters are impacted by virtualization in general. Based on those impacts, we can assess which performance measurements guest machines produce remain viable for diagnosing performance problems and understanding capacity issues. Depending on the type of performance counter, the impact of the virtualization environment varies considerably. To begin, it is necessary to understand how both Hyper-V and the VMware ESX hypervisor affect the clocks and timers that are available on their guest machines. Essentially, Hyper-V intercepts all calls made from the guest OS to access hardware-based clock and timer services on the Host machine and substitutes a virtualized Time of Day clock value. The hypervisor takes pains to ensure that this virtual clock value sent to the guest is minimally