Sijin Joseph – Blog

1.1.1. CoreWorld

Arti?cial evolution for self-replicating computer codes has been introduced for the ?rst time in 1990, when Steen Rasmussen created CoreWorld.[1] CoreWorld is a virtual machine which can be controlled by a language called RedCode. This assembler-like language has a pool of ten di?erent instructions that take two addresses as arguments. Rasmussen’s idea was to introduce a random ?aw of the MOV command, resulting of random mutations of the self-replicating codes within the environment. The big disadvantage of RedCode was, that nearly all ?aws led to a lethal mutation, hence evolution did not occure as wished.

1.1.2. Tierra

In 1992, Tom Ray found out that the problem with RedCode was due to argumented instruction set: Independent mutations in the instruction and its arguments are unlikely to lead to a meaningful combination.[2] Instead of direct connection between the instruction and its argument, Ray developed a pattern-based addressing mechanism: He introduced two NOP-instructions (NOP0 and NOP1). These instructions do not operate themselve, but can be used as marker within the code. A pattern-matching algorithmus would ?nd the ?rst appearence of a complementary marker string given (after the search-command), and returns its addresse.

PUSH        AX        ; push ax JMP NOP0 NOP1 NOP0                ; jmp marker101 INC        A        ; inc ax NOP1 NOP0 NOP1                ; marker101: POP        CX        ; pop cx  

There are 32 instructions available in the virtual Tierra world, roughly based on assembler (JMP, PUSH AX, INC B and so on). With these inventions, Ray was able to gain great results for arti?cial evolution (like parasitism, multi-cellularity[3][4], …).

1.1.3. Avida

In 1994, Christoph Adami has developed another arti?cial evolution simulation, called Avida. Beside of some di?erent structures of the simulation, an important change has been made in the arti?cial chemistry: Instead of hardcoded arguments within the instructions (as in Tierra for example PUSH AX), instructions and arguments are completely separated. The arguments are de?ned by NOPs (in avida there are three NOPs: nop-A, nop-B, nop-C) following the operation (for example, a nop-A following a PUSH pushes the AX-register to the stack). There are 24 instructions available in avida, again roughtly based on assembler (call, return, add, sub, allocate and so on).

push nop-A                ; push ax jump-f nop-A nop-B nop-B                ; jmp markerBCC inc nop-A                ; inc ax nop-B nop-C nop-C                ; markerBCC: pop nop-B                ; pop bx  

With that improvements of the virtual simulation, the researchers using avida found out amazing results, among other things about the origin of complex features in organism [5].

Very interesting paper on creating a evolutionary system for native x86 systems. This is an area that has fascinated me since I first studied genetic algorithms. However I didn’t realize that this was being done for native x86 instruction sets as well, I always assumed that the environment was a virtual one.

Berkeley Sockets (BSD) are the de facto API for all network communication. With roots from the early 1980′s, it is the original implementation of the TCP/IP suite, and arguably one of the most widely supported and critical components of any operating system today. BSD sockets that most of us are familiar with are peer-to-peer connections, which require explicit setup, teardown, choice of transport (TCP, UDP), error handling, and so on. And once you solve all of the above, then you are into the world of application protocols (ex: HTTP), which require additional framing, buffering and processing logic. In other words, it is no wonder that a high-performance network application is anything but trivial to write.

Wouldn’t it be nice if we could abstract some of the low-level details of different socket types, connection handling, framing, or even routing? This is exactly where the ZeroMQ (ØMQ/ZMQ) networking library comes in: “it gives you sockets that carry whole messages across various transports like inproc, IPC, TCP, and multicast; you can connect sockets N-to-N with patterns like fanout, pubsub, task distribution, and request-reply”. That’s a lot buzzwords, so lets dissect some of these concepts in more detail.

Well written post about ZeroMQ. Lead to some interesting links about RabbitMQ, ActiveMQ the AMQ protocol, ICE (Internet Communications Engine) from ZeroC.

Pomegranate is a novel distributed file system built over distributed tabular storage that acts an awful lot like a NoSQL system. It’s targeted at increasing the performance of tiny object access in order to support applications like online photo and micro-blog services, which require high concurrency, high throughput, and low latency. Their tests seem to indicate it works:

We have demonstrate that file system over tabular storage performs well for highly concurrent access. In our test cluster, we observed linearly increased more than 100,000 aggregate read and write requests served per second (RPS). 

Rather than sitting atop the file system like almost every other K-V store, Pomegranate is baked into file system. The idea is that the file system API is common to every platform so it wouldn’t require a separate API to use. Every application could use it out of the box.

The features of Pomegranate are:

• It handles billions of small files efficiently, even in one directory;
• It provide separate and scalable caching layer, which can be snapshot-able;
• The storage layer uses log structured store to absorb small file writes to utilize the disk bandwidth;
• Build a global namespace for both small files and large files;
• Columnar storage to exploit temporal and spatial locality;
• Distributed extendible hash to index metadata;
• Snapshot-able and reconfigurable caching to increase parallelism and tolerant failures;
• Pomegranate should be the first file system that is built over tabular storage, and the building experience should be worthy for file system community. 

Very cool technology. This reminded me of a distributed filesystem Google Tech Talk (http://www.youtube.com/watch?v=3xKZ4KGkQY8) on Wuala (http://www.wuala.com/) that I found fascinating for all the little problems they had to overcome to make this work.

While searching yet again for the SQL to find a particular piece of text inside SQL server proc definitions I came across this cool Addin project that does exactly that and also has other cool features like generating the data insert scripts for a table.