August 22, 2008

NamedGZipStream, Covariance and Contravariance

Favorite MSDN article title of the month: NamedGZipStream, Covariance and Contravariance.

That's Microsoft, as always, blending the sublime and the ridiculous.

(Thanks also for the bogus etymology of "covariance": "In mathematics, covariance is a measure of the degree to which two variables move up or down together. The term was co-opted by the OO crowd to describe..." Way to overlook category theory, guys!)

April 14, 2008

Yhc : Haskell -> JavaScript

A note on compiling Haskell to JavaScript, and interfacing with the DOM, in Yhc.

March 21, 2007

Published slides from Amazon talk 16 Mar 07

Herewith I'm making available the slides from the lunchtime talk I gave at Amazon's Edinburgh office last week (16 March 2007). Thanks again to Andrew Birkett for inviting me.

It might be hard to gather much information from these slides without the accompanying performance, but you might enjoy looking at the drawings or trying to run the code samples.

February 9, 2007

Whistle While You Work

A recent tech report from Berkeley surveys the state of parallel computing [via Tim Bray]—particularly with an eye to the importance and difficulty of coding for multicore processors (one of which is helping me author this article). The bulk of the article deals with hardware design but also discusses programming systems (that's my bailliwick) and application design issues.

I've not read the whole thing yet, but I've already found some surprises:

  • For measuring success, the authors promote "dwarfs"—something like patterns of algorithms—as opposed to conventional benchmarks on particular tasks. It's not clear why this is better for measuring purposes, but the dwarfs do convey nicely some areas of challenge (e.g. "linear algebra," "spectral methods," "Monte Carlo methods").
  • They list twelve recent changes to the conventional wisdom (from no-brainers like "power is free, transistors are expensive"—which has now inverted—to more surprising ones such as "Researchers [can no longer] demonstrate new ideas by building chips.")
  • Transactional memory, a hot topic in PL research, is given some significant airtime. The authors don't mince words over the conventional alternative, locking:
    These locking schemes are notoriously difficult to program, as the programmer has to remember to associate a lock with every critical data structure and to access only these locks using a deadlock-proof locking scheme. Locking schemes are inherently noncomposable and thus cannot form the basis of a general parallel programming model. Worse, these locking schemes are implemented using spin waits, which cause excessive coherence traffic and waste processor power.
    Transactional memory seems like a clear win, though it's not widely implemented and needs to get some experience behind it.
  • With regard to programming paradigms, they put a great emphasis on the role of human programmers in the process of making software:
    We believe that future successful programming models must be more human-centric. They will be tailored to the human process of productively architecting and efficiently implementing, debugging, and maintaining complex parallel applications on equally complex manycore hardware.
    This seems to me quite wise, although it's still unclear whether we can understand the cognitive (or psychological) processes in programming well enough to design for them.

Section 5.4 seems a haunting parable for language designers:

Programming languages, compilers, and architectures have often placed their bets on one style of parallel programming, usually forcing programmers to express all parallelism in that style. Now that we have a few decades of such experiments, we think that the conclusion is clear: some styles of parallelism have proven successful for some applications, and no style has proven best for all.

There seems to be a lot of wisdom collected here, which cuts across subfields of CS—as in a list of which "dwarfs" are commonplace in which application domains. This appears to be a quite useful reference for those of us who don't work in any particular application domain but make systems for programmers to use. I nudge you gently in the direction of this article.

October 19, 2006

Large Red Button

Sun has gone and crammed a load of computers into a shipping container and is selling it. According to the New York Times: "The system includes sensors to detect tampering or movement and features a large red button to shut it down in an emergency."


September 19, 2006

Things I learned about TeX today

  • Unlike every other program that goes looking for files, TeX does not accept a -I argument to tell it where to look.
  • The TEXINPUTS environment variable can be used to control where it looks, but if you don't know the secret, you'll think you have to include every standard TeX directory as soon as you use this variable.
  • The secret (see #2) is that beginning or ending TEXINPUTS with a colon means "include all the standard directories."
  • By default, one of the standard places it looks for include files is under $HOME/texmf. It is wise to put your downloaded packages in there, if you know the second secret.
  • The second secret is that there is a secret way of laying out your files underneath $HOME/texmf. And even though TeX keeps an ls-R file to index all those files (use texhash to update the index), it ignores the ones that aren't exactly where it's expecting them.
    TFM files: texmf/fonts/tfm/fontXX.tfm
    Bitmap (PK) fonts: texmf/fonts/pk/print-driver/fontXX.YYYpk
    Style files: texmf/tex/generic/*
    Font alias mapping: texmf/fontname/
  • The package I care about, chess package, automatically installs its files under the directory of my choice, using a certain hierarchy within that directory, but it is not the hierarchy TeX is expecting.
  • The chess package is over ten years old, and when you run it, you get a warning about "using babel with an old interface," also warning you not complain if you get further errors. You get further errors, but you can ignore them.
  • You can control the resolution of the fonts that xdvi uses by telling it xdvi -mfmode :600 (your resolution in place of 600). You cannot, in any easy way that I've been able to dvine, tell METAFONT to generate fonts in the same resolution that xdvi expects by default.
This is post #128 on this blog.