My take on the Adapteva Parallella

If you don’t know what the Parallella is, go read their kickstarter page and come back.

The past

People have been talking about multicore for a long time. Every so often someone comes up with a novel architecture and they say that it’ll blow everything else out of the water Transputer, Connection Machine, SiCortex, XMOS, Tilera to name only a few.

They are really cool, really nice ideas, you should read about them. But they are expensive and end up being used in niche applications, mostly as expensive toys until commodity hardware completely overtakes them or they run out of money.

The reason people end up using desktop and mobile derived architectures is because they’re cheap and their price/performance and price/watt is often hard to match. Companies like Intel can afford to invest Billions in R&D, even if the architecture is clunky and ill suited to many applications, it still comes out ahead.

The present

A while ago I took a look at the Tilera platform, Tilera make a chip that looks a lot like the Epiphany-IV (this is the device they’ll make if they reach their 3million USD stretch goal), it’s called the TILEPro64, and is available today. The architecture of the Epiphany-IV and the TILEPro64 looks VERY similar (see the architecture diagrams below). I’d be surprised if there weren’t some patent fights over this in the future if either platform gets that far. They’re both mesh networked CPUs with limited on core memory, and you have to carefully optimise your code to keep the cores fed with data.

In Tilera’s case I was unconvinced. I think they have a product that probably shows at most a 2 to 5x performance benefit over Intel at the same Wattage (for some applications) and costs more than 10 times as much. Development kits are also likely to be HUGELY expensive.

In Tilera’s case my call was that if the unit cost was the same as Intel, and they showed a 10x performance benefit, they might have a chance. Even in this case I think it would be a hard slog to gain traction in the market, and it would be a constant fight as Intel and ARM licensees bring out new CPUs. So in Tilera’s case I felt they might find there way in to some high end routers, and will be used in a few HPC applications but eventually they’ll get left behind by commodity CPUs and disappear.

The future

So can Adapteva pull it off, when a bunch of people have tried and failed in the past? I’m still pretty skeptical. I’d say you need to be 10 times faster than Intel (at the same cost or wattage) for people to take you seriously.

The Epiphany-IV has several advantages over Tilera, the first is price. If you can really get the Epiphany-IV for 99 dollars in volume that’s pretty amazing. The second is that the Epiphany has hardware floating point, for many applications that’s an advantage too. The third is power, Adapteva talk about a 2 watt power consumption whereas the numbers I’ve heard for Tilera are more like 20 watts.

With lower power consumption than the Tilera, it’s just about possible that they might hit the sweet spot and be 10times faster than Intel per watt. So I’m slightly more optimistic than I was about Tilera.

However their current product, the Epiphany-III doesn’t look anything like as good. I don’t think that device will buy you very much over using commodity CPUs, it will however be an interesting toy and prime you for the release of the Epiphany IV.

I wish them the best of luck, I think the Kickstarter project could give them some momentum. I’d love to see a affordable massively multicore CPU on the market. At the end of they day though, I still think our best bet will be Intel and ARM slowly iterating in this direction.

SFlow configuration and usage on Dell 7048 (and other) switches

Via the web interface:


Navigate to: System->sFlow

Select "Receiver Configuration"

Set:
Receiver Owner: 1
Receiver IP : IP of server
Tick "No timeout"
Click Apply

Select "Sampler configuration"

Set Sampler Datasource (anything)
Receiver Index as "Receiver Owner" above, e.g. 1
Sampler rate: 1024
Click Apply

On a Linux server, receiving the SFlow packets. Get sflowtool-3.25, untag it/build.

Create a tcpdump format capture of incoming data:

./sflowtool -t >  a.cap

View it in tcpdump:

tcpdump -r a.cap

JSON Decoding in Go (golang)

A quick example of JSON decoding (or unmarshaling) in Go. This is basically magic, it’s totally amazing I love it.

It’s possible to decode the JSON into generic maps, but if you know the structure you can get the JSON to populate native go structures automatically. You need to be mindful of types, go wont for example convert an int to a string, it’ll just ignore it.

This means if you have a JSON object that contains string:int key values and string:string key values and you try to populate a golang string map from it, you’ll lose all you string:int pairs. You are better off creating a struct to represent it as seen below.

package main

import (
	"encoding/json"
	"fmt"
)

type LogEntry struct {
	Time string
	Cpm		float32
	Duration	int32
	Accel_x_start	int32
	Accel_y_start	int32
	Accel_z_start	int32
	Accel_x_end	int32
	Accel_y_end	int32
	Accel_z_end	int32
}

type Log struct {
  Log_size 			int
	Onyx_version 	string
	UTC_offset		string
	Log_data			[] LogEntry

}

func main() {

	b := []byte(`{"log_size":61,"onyx_version":"pre11","UTC_offset":"undef","log_data":[{"time":"2012-10-23T22:23:54Z","cpm":46,"duration":30,"accel_x_start":-4,"accel_y_start":-97,"accel_z_start":-3,"accel_x_end":-1,"accel_y_end":-98,"accel_z_end":-2}]}`)	

	var l Log
	json.Unmarshal(b, &l)

  fmt.Printf("logsize: %d onyxversion: %s data1: %s\n",l.Log_size,l.Onyx_version,l.Log_data[0]);
}

How to justify anything as a developer

One way of calculating pi is from the area of a circle, you could even embedded that image in the code. You /could/ then suggest someone call this as an external program, to calculate pi from a script. This is clearly a stupid thing to do.

Here’s a badly written program to do it:

#include <stdio.h>
#include <math.h>

char mask [20][20] = {

// 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
  {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},
  {0,0,0,0,0,0,1,1,1,1,1,1,1,0,0,0,0,0,0,0},
  {0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0},
  {0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0},
  {0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0},
  {0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0},
  {0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0},
  {0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0},
  {0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0},
  {0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0},
  {0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0},
  {0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0},
  {0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0},
  {0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0},
  {0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0},
  {0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0},
  {0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0},
  {0,0,0,0,0,0,1,1,1,1,1,1,1,0,0,0,0,0,0,0},
  {0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}

};


int main() {

  int area=0;

  for(int x=0;x<20;x++) {
    for(int y=0;y<20;y++) {
      if(mask[x][y] == 1) area++;
    }
  }

  printf("pi: %f\n",(float)area/((17/2)*(17/2)));
}

And here are some ways of justifying it:

Hmm perhaps we should refactor this, maybe there’s a better way?
It works so it’s fine, there are more important things for us to be working on.

Why don’t you just use a hardcoded value, or value from a library?
That’s crazy, you should /always/ avoid magic numbers in your code. How do you know a hardcoded value is correct? You’re developers get no intuitive feeling for the value of pi. They don’t know how to increase the precision of the value. I’m sorry that’s just nuts.

The answer is WRONG it calculates pi as around 3.7
There’s no /right/ answer, all values of pi are approximations. 3.7 is good enough for many applications. It’s also trivial to modify this program to use larger circles and get a better approximation.

OK, but there are FASTER ways of calculating pi
Have you benchmarked it? (people are generally too lazy to benchmark). If it’s really a performance bottleneck you can calculate the value once and store it. In any case, don’t be sucked into premature optimisation. Developer time is more expensive than compute time.

But it’s completely UNCLEAR
I disagree, this method gives the developer a visual representaion of the value of pi. They can intuatively see where the value is coming from. What’s more it’s easy from them to change to code and add larger circle images as required. There are even peer reviewed images of circles all over the Internet which can easily be incorporated.

You’re nuts
You just don’t understand the business case for doing it this way, you’re too wrapped up in the technical issues to see the big picture. You’ll understand better when you’ve been programming for (as long|at the same scale|with large teams) as me.

You can attempt to justify pretty much any programming position by appealing to: utility, premature optimisation, readability and intuition, business cases, and the old standby: experience.