...
This blog has no purpose
...
David Scott
dave@recoil.org
| May 2005 | ||||||
|---|---|---|---|---|---|---|
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | ||||
RSS Feed
Subscribe to an RSS feed.
Affiliations
Other blogs
Except where otherwise noted, this blog is licensed under a Creative Commons License.
Sat, 28 May 2005
Visit to Pittsburgh
I'm just back from Pittsburgh where the
100x100 project
had a combined "retreat" and NSF review. It was pretty interesting,
especially for me. The talks were all of very high quality (the average was
much better than at all of the conferences I've been to) and it was
useful to meet people who are also working on the project.
Before the main review started we had a practice session. Here are some pictures of the gradstudent poster session at which I presented the switch simulation (the demo is on the right, next to Sandy):
|
|
The demo itself seemed to go down well (probably because of all the flashy 3D graphics):
|
I didn't see too much of Pittsburgh while I was there but here are a few shots taken on the way from the university to the hotel. The leftmost shows the CS facility and the other two attempt to show how hilly the place was (the entrace to the building is on floor 4 and there is a ground-exit on every floor apparently). Notice the gothic looking building on the rightmost photo.
|
|
|
The leftmost picture shows a church near the campus and the rightmost one is of the Pittsburgh Software Engineering Institute:
|
|
Here's the impressive gothic building again -- certainly puts Cambridge's UL to shame:
|
Silly Javascript microbenchmark
Insprired partly by the growing fad for
client-side Javascript programming
and a previous discussion about javascript interpreter
performance in the lab I thought I'd run a simple microbenchmark. The
program creates an array (of integers) and loops once over,
incrementing each element. The program repeats the test 1000 times and outputs the average time. Four programs were tested; two in javascript and two in ocaml for comparison. The following graph have four lines, one for each of:
- Safari's (in OS X 10.4.1) built-in javascript VM
- Firefox 1.0.4's built-in javascript VM
- Ocaml bytecode (on a 1.5GHz Apple PB)
- Native ocaml code (on a 1.5GHz Apple PB)
As you can see, Firefox's javascript VM seems to run faster than Safari's. The final kink in the Firefox curve is probably when the program is suspended while the user is consulted with a dialog ("A script on this page is causing mozilla to run slowly.... Do you want to abort..."). Encouragingly, the javascript interpreters weren't that much slower then ocaml bytecode -- I didn't have to log any axes! So all we need is something to compile a nice language to javascript and perhaps we can do some proper client-side programming...
Sun, 22 May 2005
Experimental tools for bibtex -> rss
I've been playing with
bibtex2html
(excellent bibtex parsing and prettyprinting) and
ocamlrss
(ocaml support for RSS, yay!)
and have put together a primitive script for turning bibtex entries (which I try to create when I read a paper) into blog entries via
blosxom
.
Hopefully I can integrate with Anil's forthcoming blogging tools to make a mega-super-research-blogging-kit.
Submitted final bound copy of thesis!
I dropped into the
Board of Graduate Studies (BoGS)
with two hardbound copies of my thesis -- each a single-sided monster -- and a note from Peter, my internal examiner, acknowledging that I've finished my corrections. BoGS told me to hand it directly to the Degree Committee round in Engineering which was fine by me; at least they're more likely to add it to the agenda for the next committee meeting. So hopefully the Degree Committee will meet end of Jan, BoGS will meet middle of Feb and I can officially graduate end of Feb.
Woohoo!
Mon, 10 Jan 2005
Linux page tables
Quite an interesting article on
Linux's page table system
in LWN. The most interesting thing about it for me was how complex they make a simple tree look. (Perhaps this is Intel's fault rather than the fault of the Linux developers). For example why name the data items in each level of the tree? Why use names like PGD, PMD and PTE when they could instead talk about levels 0, 1 and 2?
The LWN article gives the pseudocode required to manually map a virtual address into a physical address:
pmd = pmd_offset(pgd, address);
pte = *pte_offset_map(pmd, address);
page = pte_page(pte);
Nice. The article does say that most tree traversals have been abstracted behind functions (yay) but nevertheless quite a lot of pieces of code are written which make explicit reference to the three-level assumption.
I wonder (idly, of course) whether a more generic design could be used instead. Would it be possible to implement it in C or would we require help from high-level languages like O'Caml? Perhaps I should investigate the BSDs to see how they handle page tables.
Tue, 14 Dec 2004
The PhD Viva
The dreadful day finally arrived (or rather it did on Nov 23rd) when I would
be grilled over my attempts to write a coherent thesis. I was feeling a bit
depressed beforehand...
|
|
Happily, after a bit of a grilling (which I deserved) I passed with minor corrections. Kieran provided the celebration champagne (bit of a wedding oversupply I think)
|
Process Calculi
Nice summary article on process calculi:
http://gridswarms.essex.ac.uk/mobcompsys.html
Nomadic Pi(ct):
Location-Independent Communication for Mobile Agents: a Two-Level Architecture; Peter Sewell, Pawel T. Wojciechowski, Benjamin C. Pierce
http://citeseer.ist.psu.edu/150304.html
Nomadic Pict: Language and Infrastructure Design for Mobile Computation; Pawel T. Wojciechowski
http://citeseer.ist.psu.edu/309143.html
Nomadic Pi-calculi: Expressing and verifying communication infrastructure for mobile computation; Asis Unyapoth
http://www.cl.cam.ac.uk/TechReports/UCAM-CL-TR-514.html
Facile:
Facile: a symmetric integration of concurrent and functional programming; Alessandro Giacalone, Prateek Mishra, Sanjiva Prasad http://portal.acm.org/citation.cfm?id=78098
Localities and failures; RM Amadio, S Prasad
http://scholar.google.com/url?q=http://www.cmi.univ-mrs.fr/~amadio/india94.ps
Asynchronous Pi:
An Object Calculus for Asynchronous Communication; Kohei Honda, Mario Tokoro
http://citeseer.ist.psu.edu/honda91object.html
http://www.ifs.uni-linz.ac.at/~ecoop/cd/papers/0512/05120133.pdf
Seal: A Framework for Secure Mobile Computations; G. Castagna, J. Vitek
http://www.springerlink.com/link.asp?id=dbr2a1861fx9
A typed language for distributed mobile processes (extended abstract); James Riely and Matthew Hennessy
http://doi.acm.org/10.1145/268946.268978
Annoying descriptor-related bug
Seal:
Distributed Pi:
I do find
Symbian
programming rather irritating at times.
On this occasion I was implementing a simple packet protocol over a bluetooth RFCOMM connection and had a rather hard to find bug. At the lowest-level, each packet had a single header field which contained the length of the packet (packets could vary in size). So I had to first read in the length field using something like:
RSocket bluetoothSocket = ...;
TBuf8<2> lengthBuffer;
bluetoothSocket.Read(lengthBuffer);
The call to
Read()
completes (and an active object is scheduled) when the
descriptor is full. So the next step is to read the rest of the packet,
having read the length. I figured the best descriptor type to use would be
an
HBufC
-- a heap-allocated descriptor -- since I can dynamically allocate
one with exactly the right size. Moreover HBufCs support a
ReAlloc()
method
which sounds similar to the C library realloc() function.
Naturally it doesn't work.
A lot of tedious debugging later and I finally think to check the MaxLength() of the descriptor I just allocated. I was pretty sure the ReAlloc() function would try to be clever, allocating more than I asked for in order to avoid heap fragmentation. I also assumed that it would hide this from me like the C function realloc() does --- after all, it would only require one more private field in the implementation of the HBuf class. This assumption was unfounded. I asked for a descriptor with n bytes, suitable for reading a packet of length n. It gave me a much bigger descriptor causing the Read() call never to complete.
I'd have been happy if one of the following wasn't true:
- the ReAlloc() call exposes the internal size of the heap buffer rather than hiding it
- the Read() call never completes until the whole descriptor is full (ie no partial reads)
The solution I adopted in the end was to maintain my own char[] array and create TPtr references into it; at least that way I could control the MaxLength(). A bit of a cop-out -- I might as well make a massive char[] array and perform my own memory management inside it.