Pinot Noir Tasting: Old World 95 to 2004 versus New World 2006 to 2008

Some of you will know that I am a bit of a fanatic about Pinot Noir. Once you get hooked by the (often expensive) wine made from this grape everything else seems slightly second-best.
Once or twice a year a group of us get together for a wine-tasting evening. The last event was Cote-du-Rhone and other Grenach-Syrah-Mourvedre wines from around the world, but last Saturday was an event we had been talking about for a few years: the up-market Pinot Noir evening.

We selected 8 Pinot Noirs, 4 from France, 3 from New Zealand and 1 from America:

• 1995 Volnay
• 1996 Chassagne Montrachet
• 2002 Pommard
• 2004 Echezeaux
• 2006 Bald Hills
• 2007 Au Bon Climat Isabelle
• 2008 Schubert Block B
• 2008 Cornish Point

The oldest 4 wines are French, and these wines are made for lengthy cellaring with the aim of developing the complexity that only time (usually 10 years+) can bring. I included the 2004 Echezeaux even though it has not yet reached its recommended drinking window just to make the age comparison more interesting.
The youngest 4 wines are all New World, and are made with a more fruit-driven approach for earlier drinking (but these up-market New World Pinots will also continue to improve for a long time). The Bald Hills and Cornish Point both come from the Bannockburn district of New Zealand’s Central Otago in South Island, whereas the Schubert comes from Martinborough in North Island. The Au Bon Climat comes from California.

We usually taste the wines 4 at a time in 4 separate wine-glasses to make it easier to compare side-by-side, and this time we decided to go in strict chronological order.
The bottles were opened at about 6PM and the tasting started at 8.30.

We use a simple scoring system:

Tick one word,       score points for pleasure      Circle Descriptions

Name of wine:

SIGHT                  Score (max 4) CLARITY:                            cloudy, bitty, dull, clear, brilliant DEPTH of COLOUR:       watery, pale, medium, deep, dark COLOUR:                        purple, purple/red, red, red/brown VISCOSITY:        slight sparkle, watery, normal, heavy, oily	Starbright, tuile,straw, amber,tawny ruby, garnet, oeil de perdrix, hazy, opaque
SMELL                 Score (max 4) GENERAL APPEAL: neutral, clean,attractive,outstanding Off (yeasty, acetic, oxidized, woody, …) FRUIT AROMA:                none, slight, positive, identifiable BOUQUET :                    none, pleasant, complex, powerful	Cedarwood, corky, woody, dumb, flowery, smoky, honeyed, lemony, spicy, mouldy, peardrops, sulphury
TASTE                  Score (max 9) TANNIN:                                       astringent, hard, dry, soft ACIDITY:                                  flat, refreshing, marked, tart BODY:    very light & thin, light, medium, full bodied, heavy LENGTH:                  short, acceptable, extended, lingering BALANCE:      unbalanced, good, v well balanced, perfect	Appley, bitter, burning, blackcurrants, caramel, dumb, earthy, fat, flinty, green, heady, inky, flabby, mellow, metallic, mouldy, nutty, salty, sappy, silky, spicy, fleshy, woody, watery
OVERALL QUALITY   Score (max 3) Coarse, poor, acceptable, fine, outstanding	Supple, finesse, breed, elegance, harmonious, rich, delicate
Total Score     (total out of 20)

In the first flight of 4 we all found the 1995 Volnay disappointing, although its colour was still a healthy red. The 1996 Chassagne Montrachet was well liked by everyone and was the winner of this group. The 2004 Echezeaux showed more fruit than the others and was excellent, but undoubtedly will be better drunk in a few years time.

The second flight of 4 were all well-liked. The 2008 Cornish Point was the winner in this group.

The 8 of us in the wine-tasting group have slightly different tastes: just over half tend to prefer the Old World style and the rest tend to prefer New World. But the scoring was reasonably consistent (well OK it did get slightly ragged towards the end of the evening …).

The overal winner by a narrow margin (declared sometime around midnight) was Felton Road’s Cornish Point.
The first time I drank this wine (maybe 6 years ago?) I was amazed at it’s depth of flavour and length of taste, and its still one of my all-time favourites.

Multi-threaded UDFs – Technology, Locking, Race conditions and Deadlocks

One of the major disadvantages of VBA (and VB6) UDFs is that they cannot be multi-threaded. And since everyone now has PCs with multiple cores and Excel 2007 or Excel 2010 (well except for my better half Jane who is currently struggling with a rather ancient laptop) this is starting to be a problem for us Excel speed freaks/geeks.

Thats one of the reasons why I decided to rewrite my next generation of fast UDFs as C++ XLLs.
I am using XLL+ Version 7 and VS 2010: using these tools to make a UDF multithreaded is easy: just tick the multi-threaded option and away you go.

I am now about 6 months into learning how to write these C++ UDFs things and its mostly going OK. Of course there are minor hiccups along the way: like when it took me half a day to figure out why this numeric parameter always arrived in the UDF as 1 regardless of whatever value was passed in! (If you really want to know its because Excel and the Oper data structure don’t really know about integers: they insist on thinking they are primitive booleans. I knew that happened on output – always use doubles – but stupidly had not considered that it would also happen on input …).

Anyway I have now written most of my simple functions: they all work OK and calculate fast, so obviously its now time to get overconfident and go for a real challenge.

Multi-threaded UDFs sharing a global resource.

One of the tricks involved in writing faster Lookup and Matches is to be able to store the row number in the input range where the answer was found and use it the next time the Lookup or Match is executed. This technique is fast with unsorted data.

For unthreaded UDFs this is conceptually straightforward: just store the row number in a global container of some kind. But for multithreaded UDFs its not so simple because you can have multiple instances of the UDF being executed on different threads and all trying to update or read the container at the same time – a definite no-no for multi-threading. The answer is to be able to set a lock on the global container.

After a lot of Googling I decided to use a shared lock from the Boost library and either a Map container from the Standard Template Library (STL), or an unordered Map from Boost. (Both of these libraries contain an enormous framework of containers and algorithms and other excellent stuff). The shared lock allows only 1 thread to update but multiple threads to read.

There were a few glitches getting VS2010 to acknowledge the Boost libraries, but once I had figured that out it all works and seems quite efficient (half a million updates and half a million reads in about 1 second using 8 cores). The unordered Map using integer keys is fastest.

The next thing to get my head around is how to handle multiple global containers at the same time. Simples! I thought, you just have a separate Lock for each container. But I suspect this could lead to the dreaded “race condition”  “deadlock” where one thread holds one lock and is waiting for another lock, and another thread holds that lock and is waiting for the first thread: the corresponding image is 2 meerkats chasing each other’s tails.
(Mike Woodhouse points out that a “race condition” is having 2 threads trying to update the same thing at the same time.)

Time for a cold towel wrapped round my head, swiftly followed by a large glass of Central Otago Pinot Noir (fantastic stuff).

Afterthought:

Having slept on it I think I need a timeout on the locks as well (I wondered why there was a timeout parameter on the shared lock). The problem is that even if all MY udfs depend on a single lock the user could be using someone elses UDFs at the same time that could have their own lock:

If

• MyXLL creates MyLockUDF and OtherXLL creates OtherLockUDF
• Formula1 =MyLockUDF()+OtherLockUDF()
• Formula2 =OtherLockUDF()+MyLockUDF()
• Formula1 and Formula2 are on separate threads being calculated at the same time

then there could be a deadlock.