I don't know about you, but the whole mess around the emerging lexicon associated with modern processors is very frustrating. Terms are frequently redefined and twisted based on each vendor's whim and fancy. But words (should) mean something and obviously it's important that we all talk the same language.

A perfect example... you might have been approached by a Jehovah's Witness in the past. Or have a friend who is a Mormon. I do. They are wonderful people in general. When they talk about their faith their words and themes sound very similar to Biblical Christianity. But dive a little deeper and you'll find the belief systems are radically different. I'm not making a statement on value or correctness or anything like that (so don't bother starting a religious debate). My point is that two people can talk and maybe even (think they) agree, when in fact they are as far from each other as heaven and hell (so-to-speak).

When it comes to the engines that power computers, people talk about CPUs, and Processors, and Cores, and Threads, and Sockets, and Chips, and n-Way, and TEUs, and CMT, and Hyper-Threading, and and and... Whew!

I like to use three terms... Chips, Cores, and Threads. Note that this is pretty much what SPEC.ORG uses: http://www.spec.org/cpu2000/results/rint2000.html

I stay away from Sockets and Processors and CPUs and n-Way, as these are confusing or ambiguous or redundant.

Here are some examples [Chips/Cores/Threads]:
V880:          8/8/8
V490:          4/8/8
p570:          8/16/32
V40z:          4/4/4
Niagara:      1/8/32  (for a system with just one of these chips)

Here are my definitions:

Chips
This refers to the laser scribed rectangle cut from a semiconductor wafer, which is then packaged in a plastic or ceramic casing with pins or contacts. A "chip" may have multiple processing "cores" in it (see: Cores). The US-IV and Niagara and Power5 and Itanium and Opteron are all single "chips".

Cores
This term refers to the number of discrete "processors" in a system or on a chip. Some chips, such as Power5, US-IV,  Niagara, etc, have more than one core per chip. A core is also know as a TEU (thread execution unit). Each "core" may also be multi-threaded (see Threads), which can support concurrent or switched execution. Some cores have more than one integer, floating point or other type of "execution unit" that supports instruction level parallelism and/or more than one concurrent thread.

Threads
Threads are really a S/W construct. These are the streams of execution scheduled by the OS to do work driven by the computer's processor(s). Some cores can handle more than one thread of execution. Some cores can execute more than one thread at the same time. Other cores can be loaded with multiple threads, but perform H/W context switching at nanosecond speeds. The Thread Count of a processors equals the number of cores multiplied by the number of threads handled by each core. The US-IV has a Thread Count of 2*1=2. The Power5 has a Thread Count of 2*2=4. Niagara has a TC of 8*4=32.

Sockets (avoid)
This term is designed to communicate the number of processor "chips" in a system. However, in reality it is an ambiguous term, because IBM's MCMs (multi-chip modules) have four "chips" per motherboard "socket". And, a long time ago, some sockets were stacked with more than one chip. Regardless, this term is supposed to equate to the number of "chips", so why confuse the issue. Just use "chips".

Processors (avoid)
This is technically equal to the number of cores. However, marketing has corrupted this term and some vendors (like Sun) equate this to the number of chips (or sockets), while others equate this to the number of cores. Vendors also use the term "n-Way". But since the number "n" equals the number of processors, this means different things depending on the vendor. For example, a 4-way V490 from Sun has 8 cores, and Oracle will charge you $320,000.00 (list price) to run Oracle on it.

CPUs (avoid)
This suffers from the same marketing overload problem as Processors.

January 30, 2005 03:47 PM EST Permalink

A friend recently asked me what I'm hearing about SOA adoption and the buzz around JSR 208.

"JSR 208" might be a new term for some. Here is a brief overview: http://www.bijonline.com/PDF/Chappell%20oct.pdf

SOA is so over hyped these days that everyone probably has something different in mind when they hear that TLA (three letter acronym). Kinda like "Grid" - the concepts are real and useful, but the hype around SOA and Grid is running years ahead of reality.

Remember when N1 was first discussed... the vision of heterogeneous datacenters managed by a meta-OS that auto-provisions virtual slices into which services are deployed and managed to sustain business-driven SLOs based on priorities and charge-back constraints. Just roll in new equip and N1 will "DR" (read: dynamically reallocate) services into the increased capacity. If something fails... no problem... N1 will detect and adapt. We'll get there... eventually. And we've made important steps along the way. Investing almost $2B/yr in R&D will help. But it'll take (a long) time.

In some circles I'm hearing similar visions of grandeur around SOA. They talk of business apps described at a high level of abstraction (eg: business process models) loaded into an "application orchestrator" that broadcasts descriptions of the various components/services it needs, and then auto-builds the business app based on services from those providers (both internal and external) that offer the best cost point and service level guarantees. As new "service" providers come on-line with better value (or, if existing providers go off-line), business apps will rebind (on-the-fly) to these new service components.

Now, combine N1 and SOA and ITIL, and we could paint a beautiful picture of Service Delivery based on self-orchestrating business apps made up of discrete reusable and shared (possibly outsourced) components that each exist in their own virtual containers that are auto-provisioned and auto-optimized (based on SLAs and Cost and Demand) to maximize asset utilization and minimize cost, all while meeting service level objectives (even in the event of various fault scenarios).

Okay - back to reality :-) I'm finding there is a common theme from many of my customers/prospects. Many are seeking to increase efficiency and agility thru "horizontal integration" of reusable building blocks (eg: identity, etc), a shared services platform (grids, virtualization, etc), and higher-level provisioning (automation, SPS).

That isn't SOA, per-se, but is a good first step. The "building blocks" most are looking to share today are infrastructure services, rather than higher-level business app components. There is a maturity gradient that simply takes a lot of hard technical and political work to negotiate. Every customer is at a different place along that gradient, but most are embarrassingly immature (relative to the grand vision). It takes strong leadership and commitment at all levels, and a synchronization of people, processes, technology, and information, to even embark on the journey. It takes a tight coupling of S/W engineering, IT Architecture, and Business Architecture.

So, yes, I'm passionate about SOA, and JSR 208 will help integrate discrete business services. There are some firms that are pushing the envelope and building interesting business/mission apps from shared "service providers". But, in general, SOA is an abused term and the hype can derail legitimate efforts.

I'd be curious if others are sensing "irrational exuberance" around SOA, which can lead to a "Trough of Disillusionment" and a rejection of the legitimate gains that an evolutionary progression can provide. As Architects, we can establish credibility and win confidence (and contracts) by setting realistic expectations (hype-busting) and presenting not only a desired state "blueprint" (something that gets them existed about the possibilities for their environment), but a detailed roadmap that demonstrates the process and the benefits at each check point along the way.

January 30, 2005 02:22 PM EST Permalink