Category Archives: random

Quick Sheeple update…

Okay, so I haven’t actually posted anything about Sheeple in a while.

Sheeple took a break for a few weeks, but development is up to full steam again. There’s some shiny new special sauce going on under the hood now, with some -very- promising early results.

See this paste for some picobenchmarks on various implementation. Notice: direct-property access is now as fast as slot-value on CCL. :)

Unfortunately, the rest of Sheeple doesn’t perform that well quite yet. The new fancy secret sauce allows for a lot of optimizations that weren’t done before. Once this code is stabilized and tagged as 3.0(!), I’m bringing back a bunch of different caching schemes Sheeple was using for dispatch. Tonight’s benchmarks were promising — I think Sheeple may actually be able to perform better and faster than optimized CLOS implementations such as CCL’s and SBCL’s.

We’ll see. We’ll see…

Posted in random | Tagged , | Leave a comment

Introducing: ChanL

For the longest time, I wanted to start learning about issues related to concurrency, and how to handle them in Lisp. I kept reading around to learn about different approaches to writing concurrent code, and studied up on things like Software Transactional Memory, futures/promises, and Erlang-style actors. After boggling to understand all these different approaches, I was left with a bit of disappointment: None of them seemed to be the right combination of generalized+clean+easy.

STM caught my eye for a while, but it still has its issues, and I’m still not sure how I feel about the whole “thrash until you can agree on something” issue — it seems to me like it’s just the same as wrapping code in (with-lock-held …). Futures/promises looked easy enough for simple one-shot tasks, but that’s not necessarily what you want to do when you write heavily-parallel code: Sometimes you want threads constantly yielding values. Erlang-style actors are, of course, one of the big success stories when it comes to people trying to write heavily-parallel code. It just seems so damn ugly — and it -is- nice to be able to share data sometimes.

Then, magic happened: I came across something called Communicating Sequential Processes, through Rob Pike’s Google Tech Talk on Newsqueak. It was really amazing, it seemed to be just what I needed: a relatively low-level synchronisation mechanism that works naturally with the concept of multiple parallel threads/processes. I’m totally sold on Rob’s point of view here: don’t try to pretend you’re not parallelizing code (hear that, STM? That’s right). Instead, make the parallelization part of your interface. Deadlocks are a bug — find them.
Continue reading »

Posted in random | Tagged , , , , | Leave a comment

Sheeple goes on a diet

I’ve been working on rewriting Sheeple these past couple of days. The new version will be a major bottom-up redesign, mainly to the lowlevel stuff. The early results without too-crazy optimization are already showing up, and it’s quite nice.

These numbers are on Clozure CL x86  Linux:

SHEEPLE> (time (loop repeat 100000 do (allocate-std-sheep)))
(LOOP REPEAT 100000 DO (ALLOCATE-STD-SHEEP)) took 119 milliseconds (0.119 seconds) to run
                    with 2 available CPU cores.
During that period, 106 milliseconds (0.106 seconds) were spent in user mode
                    3 milliseconds (0.003 seconds) were spent in system mode
50 milliseconds (0.050 seconds) was spent in GC.
 4,000,000 bytes of memory allocated.
 19 minor page faults, 0 major page faults, 0 swaps.

And a single sheep object:

SHEEPLE> (time (allocate-std-sheep))
(ALLOCATE-STD-SHEEP) took 0 milliseconds (0.000 seconds) to run
                    with 2 available CPU cores.
During that period, 0 milliseconds (0.000 seconds) were spent in user mode
                    0 milliseconds (0.000 seconds) were spent in system mode
 40 bytes of memory allocated.

Now, that’s still a bit heavy compared to CLOS (which only allocates 24 bytes for a raw instance), and to be honest, I’m not aiming at beating CLOS. It’s like a class-based system trying to beat out structs. On the other hand, it’s actually pretty nice to shrink everything down to more usable levels.
The current Sheeple release, for example, the one built on top of CLOS, is quite a monster:

SHEEPLE> (time (loop repeat 100000 do (allocate-sheep)))
(LOOP REPEAT 100000 DO (ALLOCATE-SHEEP)) took 11,273 milliseconds (11.273 seconds) to run
                    with 2 available CPU cores.
During that period, 10,716 milliseconds (10.716 seconds) were spent in user mode
                    204 milliseconds (0.204 seconds) were spent in system mode
3,249 milliseconds (3.249 seconds) was spent in GC.
 244,000,000 bytes of memory allocated.
 9,419 minor page faults, 0 major page faults, 0 swaps.

So yeah, this is a huge improvement.

Keep in mind that all of these numbers don’t yet take into account what the full cost of a raw (clone) will be, although it won’t be much higher than what it is right now (I believe it will only be two extra words, because an item will be added to the parents list).

It’s a bit fun to mess around with stuff so carefully at a lower level…

Posted in random | Leave a comment

Sheeple MOP

There’s been some work done on Sheeple’s MOP, and I figured I’d write a bit about what got done today…

The original reason for writing Sheeple, like I said before, was to use it with Sykosomatic (which I still haven’t written an entry for, meh). That said, Sykosomatic’s object system needs to be fully persistent. Sheeple itself is not persistent — it works like a standard run-time object system.

Because I’m a masochist and a nerd, I figured I’d simply write Sheeple as the regular object system that it is, then “just” add a Metaobject Protocol like CLOS’ once the base language was set. Ho boy, did I ask for trouble. MOPs are a royal pain in the ass to do properly, and they’re a bit mind-bending. Regardless, Sheeple has been slowly getting MOP features over time. The neat part? The MOP itself is written in CLOS (as are a lot of Sheeple’s internals).

What I managed to get done today is the protocol for manipulating properties and property behavior through property metaobjects.
Continue reading »

Posted in random | Tagged , , | Leave a comment

Games and storytelling

So i went missing for a few days.  One reason is that I got distracted from code by a recently-purchased copy of the World of Darkness Storytelling system rulebook.

I really love  White Wolf’s approach to these games. I’ve played MMOs for many years now, and tabletop roleplaying games for a little less, and I found that I almost universally went with roleplaying/story-heavy sides of whatever I played, so the Storytelling system’s strong emphasis on telling a story, rather than leveling up a character by grinding through rats, really resonated with me.

It also helped me think a lot more about what kind of system Sykosomatic should employ — what can be done in an online world that encourages cooperative storytelling between players, while still having systems for fairly resolving conflicts?

Anyway, I should have an actual full post about what Sykosomatic is and what I’m aiming for with it before I go too far into more specific aspects of its design.

As far as the WoD goes — I’m really liking this system, and I’m going to try and run a couple of short games over the coming months to get familiar with it. Right now, I have a feeling a modified version of the system is what Sykosomatic will end up using in the background…

Posted in random | Leave a comment

Buzzwords, Che Stallman.

I have a thing with buzzwords. They bug me a lot. I get annoyed whenever someone spews a bunch of meaningless crap at me to try and impress me, and it usually makes me turn around before even listening to the actual meat part.

It’s not fancy words that bother me, here, by the way, it’s -empty- words. Sheeple’s description (and Sheeple’s old API) is meant as a nice big jab at those buzzword-crazed software jerks out  there that dump their garbage text into the interbutts as if it were some kind of toilet — and I’m expected to like their shit.

Here’s an example of what I mean. This one is from IBM’s Jazz:

Vision:

Jazz is an IBM Rational initiative to help make software delivery teams more effective.

Inspired by the artists who transformed musical expression, Jazz is an initiative to transform software delivery by making it more collaborative, productive and transparent, through integration of information and tasks across the phases of the software lifecycle.

Wow! Inspired by a revolution in one of the arts! This must be good!

[As a side note, the whole "Vision" thing inspired me to do the same for Sheeple, and I learned some new empty phrases to shove into its description from this site :)]
Continue reading »

Posted in random | Tagged , , , | Leave a comment

Sheeple continued: Dispatch

In the last entry, I wrote a bit about the basics of how object instantiation and property/slot access works in Sheeple. In this entry, I’ll introduce a whole different realm of Sheeple: the method dispatch system. If you’re familiar with Javascript, it might already be obvious to you how polymorphic method dispatch can be implemented with the small bit of Sheeple we know so far:

SHEEPLE-USER> (add-property *sheep* 'foo
                            (lambda ()
                              (print "Method called!")))
#<Sheep #x15031356>
SHEEPLE-USER> (foo *sheep*)
#<Anonymous Function #x1506C446>

For those confused: the above equivalent in javascript would be:

sheep.foo = function () { alert("Method called!"); }
sheep.foo -> function object

And there you have it. Actually calling the function is just a matter of using Lisp’s version of adding () at the end of a variable:

SHEEPLE-USER> (funcall (foo *sheep*))
"Method called!"

In JS:

sheep.foo(); => an alert pops up. The method was called.

Continue reading »

Posted in random | Tagged , , , , , | Leave a comment