Little Big Computer

Wow!

After taking the customary bow of respect at the person who designed this level on LBP, I’d just like to say that this was not that difficult to do – albeit very time consuming.

He did not actually design a complete computer but focused on the main computational component – the arithmetic unit. In this particular case, the arithmetic unit can perform two functions – addition and subtraction.

What this video actually shows is the exemplification of the Church-Turing thesis. In this case, the PS3 has successfully performed a simulation of an arithmetic unit, within the confines of a simulated virtual world. Nice recursion.

Also, it might seem weird that this computer was constructed from moving parts instead of, say, electrons. However, before we were inundated with the world of electronic digital computers like today, we were once using mechanical computers too, such as the Zuse Z1 currently on display in Berlin. Our history of computing is filled with all kinds of computers.

Now, if only it could be turned into a really interesting gaming level.

Multi-core Parallelism

As I mentioned in a previous blog, I am running a six-core machine – it is actually a virtual machine. Regardless, I noticed one thing while doing it. As I went from single-core to six-core, performance improved accordingly. But when I went up to eight-core, things deteriorated. The reason for this is probably because of the arrangement of the processors. I am running a two-socketed six-core AMD system. So, for an eight-core machine to work, it would need to cross sockets, which is not a good idea due to the communications hierarchy.

So, that’s why I ended up using a six-core VM.

Prefork vs Worker

Apache2 comes with several threading/process models to handle requests. The traditional method is maintained as prefork while the newer method is worker. The main difference is that the former relies on forking processes while the latter method uses multiple threads. The result is that worker is faster than prefork under load.

I tested this by setting up two servers, one with prefork and the other with worker. I used Apache Bench to hit both systems. At low concurrency of around 200 connections, both of them worked equally as well because in both cases, the main bottleneck was CPU. After I increased the CPU from single to six-cores, the load was handled equally well until I upped the ante to 500 concurrent connections.

At this point, the worker model would still run fine while the prefork model would start to fail periodically. It is like it has trouble handling the sudden spike. Once it has been hit a few times, it will also be able to handle the load but ramping up is less graceful. This is pretty obvious once you think about it a bit and preforking processes will have a larger overhead than spawning threads.

The only advantage of using preforking is when handling non-thread safe code. However, since my Apache serves only as a reverse proxy front-end, it does not need to handle any non-thread safe scripts. These are all handled at the back-end by other servers. So, there is really no necessity for the prefork model on my setup.

SSL Key Size

I have been doing some Apache optimisation recently and I thought that I will note down various tweaks for documentation purposes only. These tweaks will be written down as I find them.

Using larger RSA keys slow things down.

In my benchmark system, I only get around 500-600 connections/second for a 4096-bit RSA key but get a 800-900 connections/second for a 1024-bit RSA key. Seeing that our server certificates are issued only annually, there is no reason to use a 4k RSA key. Although a 768-bit RSA key is breakable today, a 1024-bit one still stands for now and will probably do so for a couple more years.

So, stick to using 1024-bit RSA keys for SSL until it gets broken.

Speaking at BarCamp KL

Should have named it Software instead of Layers!I gave a short 30-minute talk at BarCamp KL today. The title of the talk was “Open Source Hardware – non-Arduino”. My objective was to basically make people aware of Open Source Hardware and that we exist and it is not all about Open Source Software only. My secondary objective was to generate some interest in this area among the different people in Malaysia. I basically structured my talk and whipped together some slides in 5-minutes around the title – “Open Source Hardware”.

Hardware
First, I started by defining why Arduino is not Open Source Hardware. This falls squarely into the realm of embedded software programming. While you can work very closely with the hardware, you are still limited by the capabilities of the hardware. The actual layer that I talked about allows you to design the hardware itself. So, one is no longer limited by the hardware layer at all.

Hardware is further broken up into layers:

  • System – SystemC is the primary language used at this level to stitch up the software guys who code in low-level C/C++ and the hardware guys who talk a different language. It is mainly used for modeling rather than actual design.
  • RTL/Gate – Verilog and VHDL are the primary languages used at this level. This code can actually be translated directly into gates through a process called synthesis. This is the main area of work done by most digital designers.
  • Transistor – SPICE is the main language used. It allows you to model actual transistors by feeding in parameters such as gate length-width, source-drain sizes and dopant parameters. This is primarily the realm of analogue designers.

Source
Hardware design is similar to software work in a way. The flow is similar and the skill-set required is also similar. In software the general activities are: code, compile, debug and test. In hardware, the general activities are: code, synthesise, debug and test. The bulk of the difference is the process of translating code into hardware.

In software, the compilation takes the code and outputs a binary blob that contains the software bits. In hardware, the synthesis process takes the code and outputs a bunch of logic gates. These gates can then be mapped into real hardware implementations and plopped onto an electronic board.

Open
Of course, there are lots of open source hardware designs out there, mostly found on OpenCores.

I gave a guy the example of the Arduino. If you work with Open Source Hardware, you can actually build a super Arduino – take an open source AVR core and couple it with a ethernet core, a crypto core, a video core and then you’ve got a souped-up Arduino without the limitations. You have just opened up a whole new market.

There, a quick talk on Open Source Hardware.

Apple RISC Machines

The Internet is abuzz with rumours that Apple is considering to buy ARM – the makers of the ARM processor that has all but conquered the mobile computing space. In fact, the market has already reacted to such strong rumours and has caused the price of ARM stock to go up to £2.55 a share today.

Now, what do I think of the rumour?

The businessman in me says that it is baseless. Apple would have no incentive to buy ARM at all because ARM is an intellectual property company. It does not sell any real microprocessors but chooses instead to license out its designs to other people, of which Apple is a licensee. So, Apple can already do whatever it wants with the ARM core that it gets, short of re-selling it onto other people. It can pop it inside any product that it wishes to and even make modifications and customisations like it did for the A4 processors used in the iPad.

The only business reason for buying ARM would be to deny other competitors from using ARM chips. This makes some sense if you think of it from Steve’s point of view. ARM is undeniably the market leader in mobile computing for a reason – it has technology that allows its processors to run really fast while consuming little power. That is why everyone uses ARM cores. By controlling ARM, Steve would be able to essentially dictate who gets to make mobile devices and who does not.

However, the engineer in me thinks that Steve would be crazy to do that. Although the ARM processor is technically superior to its competition, it is by no means the only way to make mobile devices. If Apple blocks others from using ARM, there are many other people who would be happy to step into that market (including yours truly). It just does not make any sense for Apple to absorb ARM – considering that it would have to spend about $8 billion to acquire that asset.

Even if Steve decides that nobody else in the world can use ARM except Apple, they would not gain anything. Their chief rival in the mobile space – Google, would not even break a sweat. While the Android platform is currently based on ARM, there is no reason why it cannot be switched to MIPS or something else easily. The kernel is Linux, which supports dozens of microprocessor architectures besides ARM. So, while it would be a small hiccup, it would not be a show stopper.

What’s most likely happening is Apple interested in taking a significant stake in ARM. Now, that would make both engineering and business sense. A stake in ARM would allow Steve to ensure that Apple retains some sort of influence in that area as well and steers ARM in the right direction. It would also allow Apple to get cheaper licenses, which would allow Apple to put ARM in everything, including Macs and servers.

That said, I do hope that this gets ARM some much needed exposure. Not many people know them, even though they are most certainly using a device powered by an ARM processor. It is ubiquitous like that.