« earlier | later » Page 5 of 44
Richard Hamming: You and Your Research edit / delete
Interesting reading. The bits I wouldn't agree with philosophically are probably right anyway.
to research ... on 13 October 2012
~Archive: a Knowledge Tool by the Brooklyn Institute by Brooklyn Institute for Social Research — Kickstarter edit / delete
I'm unconvinced by the project, but the idea of using kickstarter to fund research projects is an interesting one. Wonder whether I'd get away with it here! (Those donating $100 get free B+B at a workshop at the end, or something...)
Laurence Tratt: Fast Enough VMs in Fast Enough Time edit / delete
An excellent explanation of PyPy's tracing JIT.
to compilation jit pypy research tracing ... on 08 April 2012
Programming and Computation edit / delete
The collaborative compiler, and various other neat ideas.
to compilation cs research ui ... on 08 April 2012
Swap Adjacent Gems to Make Sets of Three: A History of Matching Tile Games edit / delete
(Found by an 0700 student this year.) Very interesting. Lots of other good stuff here too.
to ag0700 games research retrocomputing ... on 30 March 2012
Some quite interesting (and some less interesting) articles on the theory of computer games.
» A Word on Akalabeth and Chronology The Digital Antiquarian edit / delete
An example of referencing problems in games history. One for AG0700 next year.
to ag0700 games history research retrocomputing ... on 04 December 2011
High-Performance Synchronization for Shared-Memory Parallel Programs | University of Rochester Computer Science edit / delete
Code for assorted synchronisation operations. TBB uses this as a reference.
to concurrency parallelism research software synchronisation ... on 12 September 2011
Swarm Chemistry Homepage edit / delete
The awesome swarming-with-multiple-populations thing that I first saw at ALife 2008. Looks like he's come up with some even neater behaviours now.
to alife boids complex-systems research swaming ... on 15 July 2011
The Trouble with Erlang Concurrency | Tim Fox's blog edit / delete
The specific point is that the actor model makes it difficult to distribute a service (which isn't a problem when you have explicit channels -- you just use an any-to-any channel). The general point is that providing one model isn't helpful when that model doesn't work for your problem.
to concurrency erlang language-design research ... on 26 June 2011
« earlier | later » Page 5 of 44
tasty by Adam Sampson.