CSC/ECE 517 Fall 2010/ch1 S10 PH

Overview

When starting to build a new desktop application, we all have to make a very important decision regarding which GUI toolkit to use from a pool of so many available. In very simple words, a Graphical User Interface (GUI) toolkit is the set of API's (Application Programming Interface) that produces the graphical user interface your users will interact with. There are a number of factors to consider when choosing the toolkit. Different toolkits support different platforms (Linux, Windows, OSX) and have different features such as accessibility, layout engines, and looks. We will see all these considerations with respect to Ruby in the sections below.

GUI Toolkits for Ruby

Ruby is an Object-Oriented Programming language. Till very recently, what could have been considered its most usable implementation was the open source interpreter. The way Ruby was designed,Ruby did not have very interactive capability other than just accepting text inputs on a console. Basically any editor could be used to develop programs in Ruby. A thing to be noted is that the freshly installed Ruby interpreter is not integrated with any one development environment.

At the onset of year 2009, Ruby was not well known for being used for developing regular or commercial desktop applications. A possible reason was identified as a lack of good GUI-related libraries. Although, Tk, which is packaged in Ruby's standard library, can be used to develop desktop applications, it is considered disorganized and the API is considered to be from yesteryears.Things evolved and today we have the developments of number of third party libraries like FxRuby,WxRuby,QtRuby,GTK-Ruby,Shoes and Swing which give Ruby graphical user interaction (GUI).These libraries give Ruby the user interface elements like text boxes to key in data, buttons to perform certain operation and window displays. More recent alternate implementations of Ruby have their own GUI facilities, such as Cocoa for MacRuby and Swing for JRuby. These toolkits are not really brand new but some like FxRuby, wxRuby, ruby-GNOME2 and RubyQt are simply wrappers for toolkits written in C or C++ .Shoes is a graphical library is implemented for Ruby alone.

All the toolkits have some common features but they also differ in many aspects. There is no “best” toolkit in abstract terms.The usefulness of a library is only really tested by trying to use it to perform a specific task. Similarly, the toolkit shortcomings may only become apparent after a using it in substantial and a purposeful way.

Developing a GUI library for Ruby is actually time-consuming. There are many reasons for this like, the large number of classes and methods often involved in the implementation; the need to employ lower-level compiled languages;cross-platform support;automated testing; highly variable paths through code; and the complexity of reconciling Ruby's GC-based memory management with that of the base language (often C or C++) in long-running applications.

Ruby's popularity has double folded in recent years.It remains a small language when compared to C, C++ and Java and hence tt is an open question whether having a large number of libraries that more or less provide similar features is an optimal outcome.

Tk

Introduction

The standard graphical user interface (GUI) for Ruby is Tk. It was initially developed for the Tcl scripting language by John Ousterhout. To install Ruby from source code, you also need to have the Tk dependencies and and also have the compilation settings include Tk. If you install Ruby on Windows using the "one-click" installer package, you will be required to take extra steps to have Tk working, because it no longer supports automatic installation. Even with Tk set up for Ruby it is not that easy to use. Tk applications really do not have a good look-and-feel and trying to create complex interfaces can get troublesome. Tk is best used for smaller GUI needs.

Pros

• Cross platform

Cons

• Badly documented
• Not elegant
• Widgets are non-native

FxRuby

Introduction

FxRuby is a based on Fox which is a GUI toolkit written in C++. It can be installed using RubyGems. A binary gem is available for Windows. The gem for other platforms requires you to compile native code.

Pros

• Book available for reference

Cons

• Binary gems are available for Windows, OS X, and Ubuntu Linux but for other platforms,for installing the gem you need to compile native code.

WxRuby

Introduction

WxRuby is a binding for the cross-platform wxWidgets C++ GUI toolkits. This lets you create native-looking desktop applications. It is available for installation as a gem.

Pros

• Cross platform
• Larger support community
• Windows support

Comparison of various GUI toolkits for Ruby

Best GUI Toolkit for Ruby Survey 2008

Towards the end of year 2008, a survey of Ruby programmers was conducted.This set of respondents had those who had never done GUI programming in Ruby, those who had done some Ruby GUI programming in the past but now were not doing so and those who are doing so presently. This survey aimed to find the use and their attitudes towards graphical user interaction (GUI) libraries used for creating Ruby desktop applications.Here are the summarized results to get an insight into what were the most important features programmers looked for:

• The Ruby GUI "scene" remains fragmented: the survey found at least a dozen separate GUI libraries in current use. The most used toolkits were Shoes (21%), Ruby-GNOME2 (19%) and wxRuby (16%).

• Of users naming a single preferred toolkit, Ruby-GNOME2 and Shoes were chosen by 26%, wxRuby by 17% and RubyCocoa 11%; no other toolkit received more than 10%.

• There are striking differences between Japanese and Euro-American Ruby users. Among Japanese Ruby developers, Ruby-GNOME2 is the preferred toolkit of a majority (56%), whereas among Euro-Americans, it lies third behind Shoes and wxRuby in popularity

• Preference for one or other of the two leading comprehensive toolkits (GNOME2 and Wx) is not strongly predicted by the general importance attached to features of GUI libraries. This suggests their capabilities and range of potential applications largely overlap

• The emergence of new Ruby implementations and their associated GUI options has already had an effect on usage. MacRuby/Cocoa and, to a lesser degree, JRuby/Swing are well used and well regarded. MacRuby/Cocoa was the highest rated among all options for how well it met users' GUI development requirements.

• Ruby-Tk received the worst rating for how well it meets users' GUI requirements, with a modal rating of 'poor'. It was the only library for which fewer respondents said they planned to use it in the future than are currently using it. It seems its continued inclusion in the standard library is unjustified.

• Among those with an opinion, there's a 60/40 split against including any GUI library in the Ruby standard distribution.

• The high degree of fragmentation has not served potential GUI developers well. Almost all see Ruby as a viable GUI programming language, but the immaturity of the toolkits is the commonest reason for not using Ruby for GUI work. The means of redistributing ruby GUI apps to end users is another obstacle.

The numbers above clearly demonstrate that GUI library usage in Ruby remains highly fragmented. The most widely used library, Shoes, is currently being used by less than one in four GUI developers. They also suggest that this fragmentation is likely to persist. However, the the relatively new options, such as JRuby + Swing, MacRuby and Shoes, and the relatively low usage of long-established libraries such as FxRuby and Qt, are an indication that the situation is labile. It's a poor showing for the “standard” Ruby library, Tk, it being the only one where fewer users expect to use it in the future than are using it now.

Patterns of preference broadly follow patterns of usage, and most of the same comments apply. There was a very strong relationship between mother tongue and preferred toolkit. Among Japanese Ruby developers, Ruby-GNOME2 was the preferred toolkit of an absolute majority; among speakers of European languages, the same toolkit was less popular than Shoes and wxRuby. This is almost certainly a reflection of the language of the lead developers of each of those toolkits: Japanese for GNOME2, English for Shoes and wxRuby. If the lead developers speak the developer's language, this is likely to furnish more documentation and timely community support in that language. This is a nice example of the significance of non-technical factors in toolkit selection.

When to use what

If all you want is to toss up the occasional message box, or ask a user for some simple input, almost any of the toolkits I've listed will do. For simple requirements, you are likely better off focusing on platform availability, a suitable range of widgets, and appropriate cost. If you plan to distribute your application, you'll want to check the toolkit licensing. You also must be sure either that the user already has the required environment or that you can easily bundle all the needed libraries and widgets in either a stand-alone application or an installation package. • Once you move to complex applications, though, the requirements get tougher. For any application that goes beyond a few simple forms, you almost certainly want to have a form-designer tool. You also want a rich set of available widgets; you're usually better off reusing an existing date picker or file browser component, for example, than writing your own. • Each of the various C-based Ruby GUI toolkits has its share of good qualities, but none of them has emerged as a clear winner. They offer no obvious choice for general Ruby cross-platform desktop development. To varying degrees, they all have issues with installation, documentation, design tools, packaging, and deployment. Notably, none of them can beat, feature-for-feature, the one non-C option.

Selection Criteria of GUI toolkit

• Ease of distributing applications
• Web-based documentation
• Availability on multiple platforms
• Maturity / stability
• Appearance / aesthetics
• Nonrestrictive license
• API programming style
• Ease of installation
• Rich set of widgets or components
• Community support/Whether or not it is actively maintained
• Speed / performance
• Internationalization support
• Licence compatible with commercial use
• Accessibility features
• Availability of extra tools
• Familiarity of toolkit other languages
• Paper-based documentation
• Solid implementation
• Ease of creating custom widgets
• Affordable cost
• Existing frameworks and libraries to speed development
• Mature IDEs and form layout tools
• Testing tools and frameworks
• Ease of packaging and deployment

The first widely adopted approach to cache coherence is snooping on a bus. We will now discuss how some real time machines by Intel , AMD and other processors maintain cache coherence using snooping based coherence protocols. For more information on snooping based protocols refer to Solihin text book Chapter 8.

Cache Coherence in real machines

SGI - Silicon Graphics, Inc

MSI & SGI IRIS 4D Processors

MSI is a three-state write-back invalidation protocol which is one of the earliest snooping-based cache coherence-protocols. It marks the cache line in Modified(M) ,Shared(S) and Invalid(I) state. Invalid means the cache line is either not present or is invalid state. If the cache line is clean and is shared by more than one processor , it is marked shared. If cache line is dirty and the processor has exclusive ownership of the cache line, it is present in Modified state. BusRdx causes others to invalidate (demote) to I state. If it is present in M state in another cache, it will flush. BusRdx even if hit in S state, it is promoted to M (upgrade) state.

The following state transition diagram for MSI protocol explains the working of the protocol:

MSI protocol was first used in SGI IRIS 4D series. SGI produced a broad range of MIPS-based(Microprocessor without Interlocked Pipeline Stages) workstations and servers during the 1990s, running SGI's version of UNIX System V, now called IRIX. The 4D-MP graphics superworkstation brought 40 mips(million instructions per second) of computing performance to a graphics superworkstation. The unprecedented level of computing and graphics processing in an office-environment workstation was made possible by the fastest available Risc microprocessors in a single shared memory multiprocessor design driving a tightly coupled, highly parallel graphics system. Aggregate sustained data rates of over one gigabyte per second were achieved by a hierarchy of buses in a balanced system designed to avoid bottlenecks.

The Multiprocessor bus used in 4D-MP graphics superworkstation is a pipelined, block transfer bus that supports the cache coherence protocol as well as providing 64 megabytes of sustained data bandwidth between the processors, the memory and I/O system, and the graphics subsystem. Because the sync bus provides for efficient synchronization between processors, the cache coherence protocol was designed to support efficient data sharing between processors. If a cache coherence protocol has to support synchronization as well as sharing, a compromise in the efficiency of the data sharing protocol may be necessary to improve the efficiency of the synchronization operations. Hence it uses the simple cache coherence protocol which is the MSI protocol.

With the simple rules of MSI enforced by the hardware protocols of the sync bus and the Multiprocessor bus, efficient synchronization and efficient data sharing are achieved in a simple shared memory model of parallel processing in the 4D-MP graphics superworkstation.

SYNAPSE Multiprocessor

Synapse protocol and Synapse multiprocessor

From the state transition diagram of MSI, we observe that for MSI there is transition to state S from state M when a BusRd is observed for that block. The contents of the block is flushed to the bus before going to S state. It would look more appropriate to move to I state thus giving up the block entirely in certain cases. This choice of moving to S or I reflects the designer's assertion that the original processor is more likely to continue reading the block than the new processor to write to the block. In synapse protocol, used in the early Synapse multiprocessor, made this alternate choice of going directly from M state to I state on a BusRd, assuming the migratory pattern would be more frequent. More details about this protocol can be found in these papers published in late 1980's Coherence protocols: evaluation using a multiprocessor simulation model and Synapse tightly coupled multiprocessors: a new approach to solve old problems

In Synapse protocol M state is called D (Dirty) state. The following is the state transition diagram for Synapse protocol which clearly shows its working.

Intel

MESI & Intel Processors

MSIhas a major drawback in that each read-write sequence incurs 2 bus transactions irrespective of whether the cache line is stored in only one cache or not. This is a huge setback for highly parallel programs that have little data sharing. MESI protocol solves this problem by introducing the Exclusive state to distinguish between a cache line stored in multiple caches and a line stored in a single cache. Let us briefly see how the MESI protocol works. For a more detailed version refer Solihin textbook pg. 215.

MESI coherence protocol marks each cache line in of the Modified, Exclusive, Shared, or Invalid state.

• Invalid : The cache line is either not present or is invalid
• Exclusive : The cache line is clean and is owned by this core/processor only
• Modified : This implies that the cache line is dirty and the core/processor has exclusive ownership of the cache line,exclusive of the memory also.
• Shared : The cache line is clean and is shared by more than one core/processor

In a nutshell, the MESI protocol works as follows: A line that is fetched, receives E, or S state depending on whether it exists in other processors in the system. A cache line gets the M state when a processor writes to it; if the line is not in E or M-state prior to writing it, the cache sends a Bus Upgrade(BusUpgr) signal or as the Intel manuals term it, “Read-For-Ownership (RFO) request” that ensures that the line exists in the cache and is in the I state in all other processors on the bus (if any). A table is shown below to summarize MESI protocol.

Cache Line State:	Modified	Exclusive	Shared	Invalid
This cache line is valid?	Yes	Yes	Yes	No
The memory copy is…	out of date	valid	valid	-
No	No	Maybe	Maybe
does not go to bus	does not go to bus	goes to bus and updates cache	goes directly to bus

The transition diagram from the lecture slides is given below for reference.

The Pentium Pro microprocessor, introduced in 1992 was the first Intel architecture microprocessor to support symmetric multiprocessing(SMP) in various multiprocessor configurations. SMP and MESI protocol was the architecture used consistently until the introduction of the 45-nm Hi-k Core micro-architecture in Intel's (Nehalem-EP) quad-core x86-64. The 45-nm Hi-k Intel Core microarchitecture utilizes a new system of framework called the QuickPath Interconnect which uses point-to-point interconnection technology based on distributed shared memory architecture. It uses a modified version of MESI protocol called MESIF, by introducing an additional state, F, the forward state.

The Intel architecture uses the MESI protocol as the basis to ensure cache coherence, which is true whether you're on one of the older processors that use a common bus to communicate or using the new Intel QuickPath point-to-point interconnection technology.

Let us now walk through a briefing on the MESIF protocl:

The MESIF protocol, used in the latest Intel multi-core processors was introduced to accommodate the point-to-point links used in the QuickPath Interconnect. Using the MESI protocol in this architecture would send many redundant messages between different processors, often with unnecessarily high latency. For example, when a processor requests a cache line that is stored in multiple locations, every location might respond with the data. As the the requesting processor only needs a single copy of the data, the system would be wasting the bandwidth. As a solution to this problem, an additional state, Forward state, was added by slightly changing the role of the Shared state. Whenever there is a read request, only the cache line in the F state will respond to the request, while all the S state caches remain dormant. Hence, by designating a single cache line to respond to requests, coherency traffic is substantially reduced when multiple copies of the data exist. Also, on a read request, the F state transitions from F to S state. That is, when a cache line in the F state is copied, the F state migrates to the newer copy, while the older one drops back to S. Moving the new copy to the F state exploits both temporal and spatial locality. Because the newest copy of the cache line is always in the F state, it is very unlikely that the line in the F state will be evicted from the caches. This takes advantage of the temporal locality of the request. The second advantage is that if a particular cache line is in high demand due to spatial locality, the bandwidth used to transmit that data will be spread across several nodes. All M to S state transition and E to S state transitions will now be from M to F and E to F. The F state is different from the Owned state of the MOESI protocol as it is not a unique copy because a valid copy is stored in memory. Thus, unlike the Owned state of the MOESI protocol, in which the data in the O state is the only valid copy of the data, the data in the F state can be evicted or converted to the S state, if desired.

More information on the QuickPath Interconnect and MESIF protocol can be found at Introduction to QuickPath Interconnect

CMP Implementation in Intel Architecture

Let us now see how Intel architecture using the MESI protocol progressed from a uniprocessor architecture to a Chip MultiProcessor(CMP) using the bus as the interconnect.

Uniprocessor Architecture

The diagram below shows the structure of the memory cluster in Intel Pentium M processor.

In this structure we have,

• A unified on-chip L1 cache with the processor/core,
• A Memory/L2 access control unit, through which all the accesses to the L2 cache, main memory and IO space are made,
• The second level L2 cache along with the prefetch unit and
• Front side bus (FSB), a single shared bi-directional bus through which all the traffic is sent across.These wide buses bring in multiple data bytes at a time.

As Intel explains it, using this structure, the processor requests were first sought in the L2 cache and only on a miss, were they forwarded to the main memory via the front side bus (FSB). The Memory/L2 access control unit served as a central point for maintaining coherence within the core and with the external world. It contains a snoop control unit that receives snoop requests from the bus and performs the required operations on each cache (and internal buffers) in parallel. It also handles RFO requests (BusUpgr) and ensures the operation continues only after it guarantees that no other version on the cache line exists in any other cache in the system.

CMP Architecture

For CMP implementation, Intel chose the bus-based architecture using snoopy protocols vs the directory protocol because though directory protocol reduces the active power due to reduced snoop activity, it increased the design complexity and the static power due to larger tag arrays. Since Intel has a large market for the processors in the mobility family, directory-based solution was less favorable since battery life mainly depends on static power consumption and less on dynamic power. Let us examine how CMP was implemented in Intel Core Duo, which was one of the first dual-core processor for the budget/entry-level market. The general CMP implementation structure of the Intel Core Duo is shown below

This structure has the following changes when compared to the uniprocessor memory cluster structure.

• L1 cache and the processor/core structure is duplicated to give 2 cores.
• The Memory/L2 access control unit is split into 2 logical units: L2 controller and bus controller. The L2 controller handles all requests to the L2 cache from the core and the snoop requests from the FSB. The bus controller handles data and I/O requests to and from the FSB.
• The prefetching unit is extended to handle the hardware prefetches for each core separately.
• A new logical unit (represented by the hexagon) was added to maintain fairness between the requests coming from the different cores and hence balance the requests to L2 and memory.

This new partitioned structure for the memory/L2 access control unit enhanced the performance while reducing power consumption. For more information on uniprocessor and multiprocessor implementation under the Intel architecture, refer to CMP Implementation in Intel Core Duo Processors

The Intel bus architecture has been evolving in order to accommodate the demands of scalability while using the same MESI protocol; From using a single shared bus to dual independent buses (DIB) doubling the available bandwidth and to the logical conclusion of DIB with the introduction of dedicated high-speed interconnects (DHSI). The DHSI-based platforms use four FSBs, one for each processor in the platform. In both DIB and DHSI, the snoop filter was used in the chipset to cache snoop information, thereby significantly reducing the broadcasting needed for the snoop traffic on the buses. With the production of processors based on next generation 45-nm Hi-k Intel Core microarchitecture, the Intel Xeon processor fabric will transition from a DHSI, with the memory controller in the chipset, to a distributed shared memory architecture using Intel QuickPath Interconnects using MESIF protocol.

AMD - Advanced Micro Devices Processors

MOESI & AMD Processors

AMD Opteron was the AMD’s first-generation dual core which had 2 distinct K8 cores together on a single die. Cache coherence produces bigger problems on such multiprocessors. It was necessary to use an appropriate coherence protocol to address this problem. The Intel Xeon, which was the competitive counterpart from Intel to AMD dual core Opteron , used the MESI protocol to handle cache coherence. MESI came with the drawback of using much time and bandwidth in certain situations.

MOESI was the AMD’s answer to this problem . MOESI added a fifth state to MESI protocol called “Owned” . MOESI addresses the bandwidth problem faced in MESI protocol when processor having invalid data in its cache wants to modify the data. The processor seeking the data access will have to wait for the processor which modified this data to write back to the main memory, which takes time and bandwidth. This drawback is removed in MOESI by allowing dirty sharing. When the data is held by a processor in the new state “Owned”, it can provide other processors the modified data without or even before writing it to the main memory. This is called dirty sharing. The processor with the data in "Owned" stays responsible to update the main memory later when the cache line is evicted.

MOESI' has become one of the most popular snoop-based protocols supported in the AMD64 architecture. The AMD dual-core Opteron can maintain cache coherence in systems up to 8 processors using this protocol.

The five different states of MOESI protocol are:

• Modified (M) : The most recent copy of the data is present in the cache line. But it is not present in any other processor cache.
• Owned (O)  : The cache line has the most recent correct copy of the data . This can be shared by other processors. The processor in this state for this cache line is responsible to update the correct value in the main memory before it gets evicted.
• Exclusive (E) : A cache line holds the most recent, correct copy of the data, which is exclusively present on this processor and a copy is present in the main memory.
• Shared (S) : A cache line in the shared state holds the most recent, correct copy of the data, which may be shared by other processors.
• Invalid (I) : A cache line does not hold a valid copy of the data.

A detailed explanation of this protocol implementation on AMD processor can be found in the manual Architecture of the AMD 64-bit core

The following table summarizes the MOESI protocol:

Cache Line State:	Modified	Owner	Exclusive	Shared	Invalid
This cache line is valid?	Yes	Yes	Yes	Yes	No
The memory copy is…	out of date	out of date	valid	valid	-
Copies exist in caches of other processors?	No	No	Yes(out of date values)	Maybe	Maybe
A write to this line	does not go to bus	does not go to bus	does not go to bus	goes to bus and updates cache	goes directly to bus

State transition for MOESIis as shown below :

MOESIState transition Diagram

AMD Opteron memory Architecture

The AMD processor’s high-performance cache architecture includes an integrated, 64-bit, dual-ported 128-Kbyte split-L1 cache with separate snoop port, multi-level translation lookaside buffers (TLBs), a scalable L2 cache controller with a 72-bit (64-bit data + 8-bit ECC) interface to as much as 8-Mbyte of industry-standard SDR or DDR SRAMs, and an integrated tag for the most cost-effective 512-Kbyte L2 configurations. The AMD Athlon processor’s integrated L1 cache comprises two separate 64-Kbyte, two-way set-associative data and instruction caches.

More information about this can be found in AMD 64 bit Architecture Programmers's Manual

Special Coherence Considerations in AMD64 architectures

Instruction prefetching is a technique used to speedup the execution of the program. But in multiprocessors, prefetching comes at the cost of performance. Due to prefetching, the data can be modified in such a way that the memory coherence protocol will not be able to handle the effects. In such situations software must use serializing instructions or cache-invalidation instructions to guarantee subsequent data accesses are coherent.
An example of this type of a situation is a page-table update followed by accesses to the physical pages referenced by the updated page tables. The physical-memory references for the page tables are different than the physical-memory references for the data. Because of prefetching there maybe problem with correctness. The following sequence of events shows such a situation when software changes the translation of virtual-page A from physical-page M to physical-page N:

1. The tables that translate virtual-page A to physical-page M are now held only in main memory. The copies in the cache ae invalidated.
2. Page-table entry is changed by the software for virtual-page A in main memory to point to physical page N rather than physical-page M.
3. Data in virtual-page A is accessed.

Software expects the processor to access the data from physical-page N after the update. However, it is possible for the processor to prefetch the data from physical-page M before the page table for virtual page A is updated. Because the physical-memory references are different, the processor does not recognize them as requiring coherence checking and believes it is safe to prefetch the data from virtual-page A, which is translated into a read from physical page M. Similar behavior can occur when instructions are prefetched from beyond the page table update instruction.

In order to prevent errors from occuring, there are special instructions provided by software like INVLPG or MOV CR3 instruction which is executed immediately after the page-table update to ensure that subsequent instruction fetches and data accesses use the correct virtual-page-to-physical-page translation. It is not necessary to perform a TLB invalidation operation preceding the table update.

More information can be found about this in AMD64 Architecture Programmer's manual

Optimization techniques on MOESI when implemented on AMD Phenom processors

In real machines, using some optimization techniques on the standard cache coherence protocol used , improves the performance of the machine. For example AMD Phenom family of microprocessors (Family 0×10) which is AMD’s first generation to incorporate 4 distinct cores on a single die, and the first to have a cache that all the cores share, uses the MOESI protocol with some optimization techniques incorporated.

It focuses on a small subset of compute problems which behave like Producer and Consumer programs. In such a computing problem, a thread of a program running on a single core produces data, which is consumed by a thread that is running on a separate core. With such programs, it is desirable to get the two distinct cores to communicate through the shared cache, to avoid round trips to/from main memory. The MOESI protocol that the AMD Phenom cache uses for cache coherence can also limit bandwidth. Hence by keeping the cache line in the ‘M’ state for such computing problems, we can achieve better performance.

When the producer thread , writes a new entry, it allocates cache-lines in the modified (M) state. Eventually, these M-marked cache lines will start to fill the L3 cache. When the consumer reads the cache line, the MOESI protocol changes the state of the cache line to owned (O) in the L3 cache and pulls down a shared (S) copy for its own use. Now, the producer thread circles the ring buffer to arrive back to the same cache line it had previously written. However, when the producer attempts to write new data to the owned (marked ‘O’) cache line, it finds that it cannot, since a cache line marked ‘O’ by the previous consumer read does not have sufficient permission for a write request (in the MOESI). To maintain coherence, the memory controller must initiate probes in the other caches (to handle any other S copies that may exist). This will slow down the process.

Thus, it is preferable to keep the cache line in the ‘M’ state in the L3 cache. In such a situation, when the producer comes back around the ring buffer, it finds the previously written cache line still marked ‘M’, to which it is safe to write without coherence concerns. Thus better performance can be achieved by such optimization techniques to standard protocols when implemented in real machines.

You can find more information on how this is implemented and various other ways of optimizations in this manual Software Optimization guide for AMD 10h Processors

Xerox Corporation

Dragon Protocol & Xerox Dragon Processors

The Dragon Protocol is an update based coherence protocol which does not invalidate other cached copies like what we have seen in the coherence protocols so far. Write propagation is achieved by updating the cached copies instead of invalidating them. But the Dragon Protocol does not update memory on a cache to cache transfer and delays the memory and cache consistency until the data is evicted and written back, which saves time and lowers the memory access requirements. Moreover only the written byte or the word is communicated to the other caches instead of the whole block which further reduces the bandwidth usage. It has the ability to detect dynamically, the sharing status of a block and use a write through policy for shared blocks and write back for currently non-shared blocks. The Dragon Protocol employs the following four states for the cache blocks: Shared Clean, Shared Modified, Exclusive and Modified.

• Modified(M) and Exclusive(E) - these states have the same meaning as explained in the protocols above.
• Shared Modified (Sm) - Only one cache line in the system can be in the Shared Modified state. Potentially two or more caches have this block and memory may or may not be up to date and this processor's cache had modified the block.
• Shared Clean (Sc) - Potentially two or more caches have this block and memory may or may not be up to date(if no other cache has it in Sm state, memory will be up to date else it is not).

When a Shared Modified line is evicted from the cache on a cache miss only then is the block written back to the main memory in order to keep memory consistent. For more information on Dragon protocol, refer to Solihin textbook, page number 229. The state transition diagram has been given below for reference.

]]

The Dragon Protocol , was developed by Xerox Palo Alto Research Center(Xerox PARC), a subsidiary of Xerox Corporation. This protocol was used in the Xerox PARC Dragon multiprocessor workstation, a VLSI research computer that could support multiple processors on a central high bandwidth memory bus. The Dragon design implemented snoopy caches that provided the appearance of a uniform memory space to multiple processors. Here, each cache listens to 2 buses: the processor bus and the memory bus. The caches are also responsible for address translation, so the processor bus carries virtual addresses and the memory bus carries physical addresses. The Dragon system was designed to support 4 to 8 Dragon processors. The memory bus used in the Xeron Dragon evolved to become the XDBus , a low-cost, synchronous, packet-switched VLSI bus designed for use in high-performance multiprocessors. This was used as the interconnect in many multiprocessor server systems like Cray Superserver 6400, Sun Microsystems' SPARCcenter 2000 and SPARCserver 1000 and Sun4d systems.

References

1. Cache coherence
2. Introduction to QuickPath Interconnect
3. CMP Implementation in Intel Core Duo Processors
4. Common System Interface in Intel Processors
5. Cache consistency with MESI on Intel processor
6. AMD dual core Architecture
7. AMD64 Architecture Programmer's manual
8. Software Optimization guide for AMD 10h Processors
9. Architecture of AMD 64 bit core
10. Silicon Graphics Computer Systems
11. Parallel computer architecture: a hardware/software approach By David E. Culler, Jaswinder Pal Singh, Anoop Gupta
12. Three state invalidation protocols
13. Synapse tightly coupled multiprocessors: a new approach to solve old problems
14. Coherence protocols: evaluation using a multiprocessor simulation model
15. Dragon Protocol
16. Xerox Dragon
17. Coherence Protocols
18. XDBus