Cores, cores, and more damn cores

Lets look at two articles that recently hit the fan:

The first is a regurgitation of a presentation made by Intel to developers. In short, they’re considering a move to processors with 10s, if not 100s, of discrete computational units on a single die. The second article is a cry for Intel to stop, or slow down, using the argument that we “have to get the architecture right first.”

OK, so the architecture can slow us down. But what slows us down even more is the fact that most programming languages have no support for concurrency, and therefore most programmers think “concurrency” means “threads and spinlocks”. The two most interesting explorations we’ve made in the last few months are the Multiterpreter and the Cell Transterpreter.

The Multiterpreter

If you check out the full Transterpreter project from our Subversion repository, you’ll see in the branches a multiterpreter branch. This exploration was a quick proof-of-concept that Christian and I poked at for a few days. While the threading is terribly inefficient, it demonstrated that we can spawn multiple OS threads on-demand from the Transterpreter runtime, and distribute computation across those threads without any modification in the source program. Put simply, if you write:


PAR
process1()
process2()
process3()
process4()

on a quad-processor machine, then all four processors will be utilized by Transterpreter instances. We haven’t publicized this branch because the approach was the least efficient implementation possible, but simplest to implement. Our explorations into native code generation are, in part, an exploration of what parts of the code-base would need to be refactored to allow efficient multithreading on big machines.

The Cell Transterpreter

The other branch that might be of interest is the Cell branch. The work being carried out here is described fully in the paper A Cell Transterpreter. Damian Dimmich has successfully run 9 Transterpreters on a single Cell Broadband Engine. Although we only have the Cell simulator, he has demonstrated that you can have multiple Transterpreters running, in parallel, all over the device, and preserve CSP channel semantics across the cores. Put another way, his proof-of-concept demonstrates that we can write occam-pi programs that work seamlessly across multiple, heterogeneous cores.

Bring on the cores

As we look to unify various compiler explorations within the group, we expect to target these kinds of platforms more directly. If your language makes it easy to express ideas in parallel, it should be easy for the compiler to automatically distribute work units to many different processors. In the case of occam-pi, this is absolutely the case… so if we have a processor with 8, 80, or 800 cores, we should be able to take advantage of that power without significant effort.

Certainly, we can take advantage of this kind of hardware far more easily than a programmer writing in a sequential language like C, C++, C#, or Java.

20060928 | | Tags: , , | Comments Closed

eBook readers for the gentle reader

Edit 20061027: The Sony Reader is based, in part, on the same freely available software as the iLiad. This means that some of what I say about the Sony Reader being a closed platform is completely false. My apologies. I have not updated the body of the article to reflect these inaccuracies, but you can read some of the linked pages in the comments to form your own perspectives.

You’re an avid reader. You’re digitally savvy—you have your digital camera, your iBook, and are comfortable with email, web forums, and the like. In short, you’re Connected.

And you love books.

Therefore, an electronic book reader makes sense. Electronic Ink technology has come a long way, and the promise of high-contrast, low-power screens for static text display is a reality. The prices are still high, and there are limitations to the devices on the market or coming to market. But what features should you really be looking for?

Extensibility

Your Mac is extensible. It has USB, Firewire, and you can download all kinds of software for it. You can’t actually imagine a computer where you’re not allowed to put more software on it of your own choosing. Likewise, your ebook reader should be extensible—you should be able to add new software to it without buying it from the manufacturer.

For example, there are many kinds of electronic content out there. Someone will certainly invent new ones over the next few years, and you want your ebook reader to be adaptable to these changing formats. Furthermore, you might want software on it that automatically retrieves newspaper, magazine, or weblog content for you… software that currently does not exist. When it does, though, you want to be able to download it (perhaps paying a small fee for the efforts of the individual who wrote it), and use it to make your reading experiences more enjoyable.

If your ebook reader is closed and proprietary, you cannot enjoy new software unless it is written by the ebook maker. Imagine if all of your software had to be purchased from Apple? This would mean you wouldn’t have Microsoft Word, Quickbooks Pro, Adobe Photoshop, Adobe Pagemaker, Quark Express… the list of software titles is practically endless.

The distinction here is that the Sony Reader is likely going to be a closed product; Sony has a horrible track record regarding their support for end-user modification. The iLiad, on the other hand, is based on the open-source operating system Linux. They are required by law to release much of the source code for the device, and they fully intend to. End-users will be able to write new software for the iLiad, and this is a Very Good Thing. The end result is that new and interesting software for the iLiad will be written for years to come, while the Sony Reader will only run software that Sony has written or deemed worthy to run on the device.

Connectivity

Imagine if your iBook only had one kind of connector, and it was designed by Apple and only used on Apple computers. Actually, this isn’t hard to imagine… only a few years ago, this was the way things were. Now, your iBook has USB and Firewire, which many companies use for mice, hard drives, and the like. In fact, there are no longer any “proprietary” connectors on your iBook—it is made up of commonly available, commodity components.

Your ebook reader should be the same way. The Sony Reader, for example, only has a Sony Memory Stick slot. The iRex iLiad has a Compact Flash slot, Secure Digital card slot, and a USB slot. This means you can have content on any of these types of card, slot them into the iLiad, and begin reading. Furthermore, the iLiad has an ethernet port (on the travel hub) and WiFi built in. This is the kind of connectivity you should expect from any device you buy today.

Open Formats

This is a biggie. We do not know, at this time, exactly what formats the Sony Reader will support. Certainly, it will support DRM-encumbered formats that guarantee the following:

  1. You will not own the electronic content on the device; you will lease it.
  2. You will not be allowed to resell electronic books you have purchased.
  3. You will not be able to share or otherwise give away electronic books you have purchased.

The iLiad will likely support these kinds of “closed” formats as well. However, the iLiad already supports three formats that capture billions of pages of text already:

  1. Plain text
  2. HTML
  3. PDF

Why is this significant? Everything in Project Gutenberg can be downloaded, right now, and viewed on the iLiad. Weblog content can be viewed on the iLiad, right now (see this post for some examples). In short, formats for which there is endless content already in existence can be viewed on the iRex iLiad today and forevermore.

If your ebook reader cannot read the most common digital formats in use today, and cannot easily be grown by you and the community to support them… then you need to justify why you are buying that reader in the first place. Does it have some killer feature? Or, does it have better marketing? Because really, in the end, you want the electronic book reader that is the most flexible and adaptable to changing market conditions, not the one with the tightest restrictions on it.

Conclusions

The iRex iLiad is the most open ebook reader on the market today. It can be purchased right now. However, it is not yet done. The iLiad team is in the process of bringing the iLiad’s software up to what we would call “Version 1.0″. Really critical things are missing at the time this was written; most importantly, the ability to scale and rotate PDFs. This means that (currently) a US Letter sized PDF is shrunk down to A5 paper size, and it immediately becomes unreadable. That said, WWW content and plain text work just great. So, given a little more time, and the iLiad will be a “no brainer”. If you have to choose between the iRex iLiad and the Sony Reader, there’s no good reason to buy the closed product.

Yes, they’re both expensive. But you have to decide whether the cost is worth the utility of the device in the long run.

| | Tags: , | 6 Comments »

Binding: For future reference

It’s that time of the season. My dissertation has only another hour or two until the corrections are done, and Carrie’s dissertation must be perfect bound for the external reviewer. Between those two, we get to bind our theses in a number of different, expensive ways. :)

| | Tags: | No Comments »

A live hash-table using XML-RPC

I received a question the other day about using our XML-RPC library, and thought I’d put the response here. It’s still a simple example, but it illustrates one or two things. You must be running PLT Scheme 352.5 or greater for this to work, as we’re using some nifty new features that make things more stable.

I’m going to implement a “live hash-table”. By this, I mean I’m going to have a PLT Scheme hash-table that I can access from anywhere via XML-RPC. I created a “testing” directory in in the “servlets” directory of my server. Inside of that “testing” directory, I created a servlet called “live-hash.ss”. It looks like this:

(module live-hash mzscheme

  (require
   ;; For the 'xmlrpc-server' and 'add-handler' functions
   (planet "xmlrpc-module-servlet.ss"
                   ("schematics" "xmlrpc.plt" 1 3))
   ;; For 'raise-exn:xmlrpc'
   (planet "base.ss"
           ("schematics" "xmlrpc.plt" 1 3))
           )

  (provide interface-version manager timeout start)

  ;; I'm using 'equal here so that strings can be
  ;; used as hashtable keys.
  (define table (make-hash-table 'equal))

  ;; CONTRACT
  ;; insert : (U string number) any -> bool
  ;; PURPOSE
  ;; The 'insert' method will insert a value into the
  ;; hashtable, and return #t. We return a boolean in all
  ;; casees because XML-RPC has no natural coercion for the
  ;; #<void> value.
  (define (insert key value)
    (if (or (string? key)
            (number? key))
        (begin (hash-table-put! table key value) #t)
        #f))

  ;; CONTRACT
  ;; get : (U string number) -> any
  ;; PURPOSE
  ;; The 'get' method returns a value from the hashtable, or
  ;; raises an XML-RPC fault.
  (define (get key)
    (hash-table-get
     table key
     (lambda ()
       (raise-exn:xmlrpc
        (format "No value in hash for key '~a'" key))
       )))

  ;; Make 'insert' and 'get' available to the
  ;; outside world.
  (add-handler 'insert insert)
  (add-handler 'get get)

  )

If you can execute this in the “module” language of DrScheme and not get any errors, there’s a good chance that it will run under the webserver. At least, that’s a first step.

On the client side, I have some code that declares that the PLT webserver running on my local machine (with the “live-hash.ss” servlet) is an XML-RPC endpoint. I then map two local functions, “ins” and “get” to the remote methods provided by the server. Lastly, I do a quick test: I insert some data, and then request it back.

The client-side looks like: 

(module live-hash-client mzscheme

  (require (planet "xmlrpc.ss"
                   ("schematics" "xmlrpc.plt" 1 3)))

  ;; Declare where the endpoint for this XML-RPC call is
  (define local (xmlrpc-server
                 "localhost"
                 8080
                 "servlets/testing/live-hash.ss"))

  ;; Define the mappings from local method calls to remove
  ;; method calls. In this case, the local name "ins" is bound
  ;; to the method "insert" running on the server.
  (define ins (local 'insert))
  (define get (local 'get))

  ;; Try inserting some data
  (for-each (lambda (key val)
              (ins key val))
            '(1 2 3 4 5)
            '(a b c d e))

  ;; Now, try retrieving it
  (for-each (lambda (key)
              (printf "K: ~a V: ~a~n" key (get key)))
            '(1 2 3 4 5))

  )

Again, I’m working under the “module” language here.

If all goes well, you can run the client-side, and see the data go round-trip to the server. Well, you can’t exactly “see” it, but you can guess that it goes round-trip to the server. 

Welcome to DrScheme, version 352.5-svn28aug2006.
Language: (module ...).
K: 1 V: a
K: 2 V: b
K: 3 V: c
K: 4 V: d
K: 5 V: e

That’s perhaps not a lot to be getting on with; there’s more documentation in the “doc.txt” file included in the distribution. And it’s not quite as cool as Tony’s explorations with Erlang, but… well, this library has been around for a while, and occasionally, someone finds a use for it.

(Pretty-printing of code to HTML made possible by Paste Scheme at scheme.dk. Woot.)

20060913 | | Tags: | Comments Closed

New user-contributed world!

John Pais wrote the greenfoot-discuss mailing list (sign up here) to announce some neat worlds that implement quizzes in Greenfoot.

screen-quiz

Now, I think this is just wacky. I mean, who knew you could do stuff like this with Greenfoot? I didn’t. Poul and I had a fun time seeing if we could answer questions designed for students at the Advanced Placement Computer Science level. It turns out, Poul doesn’t actually know anything about object oriented programming!

(OK, so I’m kidding. We got the right answers. But it is funnier to think that Poul doesn’t know anything about object-oriented programming. ;) )

You can download John’s world from the Greenfoot scenarios page.

| | Tags: , | Comments Closed

IOU

I’ve made IOU, a command line app of ill repute, available for download.

http://www.sububi.org/software/iou/

This is a specialized tool, and is likely not of interest to a broad class of users. I use it for reconciling receipts in our house. We share grocery (and other) costs in the house, and routinely have to split this up across different subgroups of the house’s residents. IOU lets me easily enter all of the receipts, who split that particular receipt, and then find out who owes whom, and how much.

It is only available for the Mac at the moment, but if there is interest, I could make it available for Windows. At least, I think I can.

| | Tags: , | No Comments »