{'fraction_non_alphanumeric': 0.02803328953131844, 'fraction_numerical': 0.003504161191414805, 'mean_word_length': 4.87146529562982, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
A simple parallel system

In this and subsequent columns, we will consider a completely message driven system, which we call AMDC, for “Active-Message-Driven Computing.” Parallel computing really ought to be different from serial computing. In serial computing, the process provides both data and control. In a parallel computer, even if it is a network of conventional computers, data and control are provided more by messages. Messages contain data, and the arrival of a message triggers computation, so it might make more sense to base the entire computation on message passing. So where does this insight lead? Can we design and implement such a system? Can we program in it? One possibility is some sort of communicating reactive object system such as Actors (Agha 1986) or Cantor (Athas 1987): objects send each other messages and only perform computations as a result of messages arriving. (We discussed reactive object systems in an earlier column: “Communicating Reactive Objects.”) One particularly clean design is Actors. Here is the basic design: The system contains a varying collection of actors. Each actor is a mailbox with an associated “behavior” script and “acquaintance list” containing local data. When a message arrives at a mailbox, the behavior is executed, being passed the message and the acquaintance list. Beyond the usual arithmetic and such, the behavior can do three things: it can send messages to its own or other actors’ mailboxes, it can create new actors providing the initial behavior and acquaintance list, and it can “become” a different actor by changing its script and/or acquaintance list. One nice thing about actors is how easy they are to implement. Mailboxes and messages form simple linked data structures. The behavior can be a function pointer. The acquaintance list can be an array or a struct. With object-oriented programming, of course, the behavior would be a method in an object whose fields comprise the acquaintance list. A scheduler can run through a list of mailboxes with waiting messages calling the behaviors. Simple locking allows multiple processors to run behaviors. An Actors system can be created with apparently only a tiny amount of programming. Other reactive object systems are similar to this version of actors.