Performance Within Reach » Processor http://unmanageability.com Performance Within Reach Sat, 17 Jul 2010 19:19:53 +0000 en hourly 1 http://wordpress.org/?v=3.0 [Video] Pat Gelsinger, SVP Intel, on the motivations that drove the development of the Intel Core Microarchitecture http://unmanageability.com/index.php/2006/06/11/video-pat-gelsinger-on-the-motivations-that-drove-the-development-of-the-intel%c2%ae-core%e2%84%a2-microarchitecture/ http://unmanageability.com/index.php/2006/06/11/video-pat-gelsinger-on-the-motivations-that-drove-the-development-of-the-intel%c2%ae-core%e2%84%a2-microarchitecture/#comments Sat, 10 Jun 2006 19:32:33 +0000 Coder http://codeperformance.com/index.php/2006/06/09/video-pat-gelsinger-on-the-motivations-that-drove-the-development-of-the-intel%c2%ae-core%e2%84%a2-microarchitecture/ Stanford talk

Pat Gelsinger discusses motivations that drove the development of the Intel® Core™ Microarchitecture, some of its most important features and the challenges that face microprocessor designers in the future.

[See video]

]]> http://unmanageability.com/index.php/2006/06/11/video-pat-gelsinger-on-the-motivations-that-drove-the-development-of-the-intel%c2%ae-core%e2%84%a2-microarchitecture/feed/ 0 Serial performance matters, especially on multiprocessor systems! http://unmanageability.com/index.php/2006/05/04/serial-performance-matters-especially-on-multiprocessor-systems/ http://unmanageability.com/index.php/2006/05/04/serial-performance-matters-especially-on-multiprocessor-systems/#comments Thu, 04 May 2006 10:58:38 +0000 Coder http://codeperformance.com/index.php/2006/05/04/serial-performance-matters-especially-on-multiprocessor-systems/ rchrd@Sun

If you can’t get your code over 90% parallelized, then you’d better pay attention to the part that is running in only one processor, and make sure that (serial) part is optimized. Because it will dominate performance.

]]> http://unmanageability.com/index.php/2006/05/04/serial-performance-matters-especially-on-multiprocessor-systems/feed/ 0 Xerox Parc hosts the “Multicore Computer Forum Series” (audio & video archives available) http://unmanageability.com/index.php/2006/03/28/xerox-parc-hosts-the-multicore-computer-forum-series-audio-video-archive-available/ http://unmanageability.com/index.php/2006/03/28/xerox-parc-hosts-the-multicore-computer-forum-series-audio-video-archive-available/#comments Tue, 28 Mar 2006 08:25:54 +0000 Coder http://codeperformance.com/index.php/2006/03/28/xerox-parc-hosts-the-multicore-computer-forum-series-audio-video-archive-available/ The Multicore Computer Forum Series “ explor[es] the benefits and challenges of Multicore computing.”

  1. High Performance Throughput Computing, Dr. Marc Tremblay, Sun Fellow, Vice President, and Chief Architect, Sun’s Scalable Systems Group
  2. Software and the Concurrency Revolution, Herb Sutter, Microsoft
  3. Architecture Support for Parallel Programming, Dr. Kunle Olukotun, Associate Professor, Stanford University
]]> http://unmanageability.com/index.php/2006/03/28/xerox-parc-hosts-the-multicore-computer-forum-series-audio-video-archive-available/feed/ 0 Top 10 things that you must monitor on any server to look for performance and/or scalability issues http://unmanageability.com/index.php/2006/02/10/top-10-things-that-you-must-monitor-on-any-server-to-look-for-performance-andor-scalability-issues/ http://unmanageability.com/index.php/2006/02/10/top-10-things-that-you-must-monitor-on-any-server-to-look-for-performance-andor-scalability-issues/#comments Thu, 09 Feb 2006 20:57:36 +0000 coder http://codeperformance.com/index.php/2006/02/10/top-10-things-that-you-must-monitor-on-any-server-to-look-for-performance-andor-scalability-issues/ Sun Dialogue Programs

(Q): If you have to pick top 10 things that you must monitor on any server to look for performance and/or scalability issues…what would they be?
Richard McDougall (A): Off the top of my head, in no particular order:

  1. CPU: Check idle time and run queue length.
  2. If there’s a CPU bottleneck, check if it’s an application or kernel CPU utilization issue with mpstat: high percentages of users indicate it’s an application issue. High sys may point to high network load or lock contention.
  3. Memory: Check MDBs memstat to ensure there is sufficient free memory
  4. Network: Check that networks are not overloaded by observing the bytes xfered against the availability bandwidth per link.
  5. CPU for network: check if any CPUs are 100% busy servicing network interrupts. CPUs at 100% in mpstat, or intrstat are possible candidates.
  6. File system latency: check the application visible latency with DTrace at the system call level (perhaps fsstat, iosnoop, or an aggregation around system calls).
  7. Storage latency: check disk latency with iostat
  8. Application level lock contention: check application level locks are now visible with plockstat
  9. Kernel level locks: Check for hot locks with lockstat.
  10. Check MMU activity on SPARC using trapstat. Sometimes an application may be reporting as running 100% in user mode, but may actually be spending a significant amount of time in kernel mode servicing TLB misses. Trapstat will show the % of time spent using TLB misses. If a significant amount of time (>10%) is evident, then large MMU pages may help.
]]> http://unmanageability.com/index.php/2006/02/10/top-10-things-that-you-must-monitor-on-any-server-to-look-for-performance-andor-scalability-issues/feed/ 1