Thinking of PlayStation 4 (PS4) Cluster

PS4 is finally unveiled along with its hardware specification. It would probably be a very nice system for HPC cluster, despite not officially. But there are several matters that I'm going to evaluate:

1. The problem set that I'm planning to tackle involves Computational Fluid Dynamics that would be "enriched" with lot's of chemical equations as constraints in the not so distant future. Is this kind of workload suit the architecture? Moreover, the connectivity speed (max at GbE) between nodes of PS4 must be taken into account. Therefore, as Jack Dongarra, et.al put it (http://www.netlib.org/lapack/lawnspdf/lawn185.pdf), only compute intensive algorithm is best suited to game console HPC cluster. Because, only on problem types where you can keep the node busy and don't communicate intensively with each other--read within the GbE bandwidth--the game console HPC cluster would make sense. This means applications that inherently have a lot of "chatter" are best kept out of this kind of system.
2. Installing Linux on the PS4 nodes. Is this going to be supported? or will it require some hacks? Well, probably Sony puts TPM hardware in the motherboard to prevent tampering with the (UEFI???) firmware. But, yeah, maybe I could do something about it?

This is just a food for thought at the moment but I think I'm going to go for it once PS4 is available. It would be worth trying. Another added "bonus" is the hUMA support in the machine (http://www.gamasutra.com/view/feature/191007/inside_the_playstation_4_with_mark_.php) is very intriguing for me. Despite AMD Kaveri CPUs would have them as well, it's much more interesting in PS4, given that the latter has 8GB GDDR5 main memory :D

Update:
----------
Well, I ended up buying four Gigabyte Brix with Celeron 2955U CPUs (see: http://www.gigabyte.com/products/product-page.aspx?pid=4743#sp). It costs me around $1K along with 4GB RAM per-node at todays exchange rate. The unit itself supports up-to 16 GB RAM per-node. Therefore, I would be able to upgrade the units RAM once I'm playing around with "big data". Anyway, what's interesting is because Celeron 2955 CPU is actually a Haswell CPU, despite its meager 1.4GHz frequency.

"Process Identifier" Support in x86-64/x64 CPUs TLB

Recent x86-64 CPUs--at least from Intel--supports a sort of process identifier in the Translation Look-aside Buffer (TLB). This is important for multiprocessing in user mode, i.e. supporting more than one process running in user mode and switching between them without invalidating and flushing the TLB.

In ARMv6 architecture and above, there is an Application Space IDentifier (ASID) hardware that identifies the process which owns an entry in the TLB. This kind of support in x86/x86-64 CPUs is long overdue. Very probably because of the need to preserve compatibility with older OS running on the platform.

However, in newer x86-64 CPUs, there is a new "field" in the CR4 control register called Process-Context IDentifier Enable (PCIDE). This field controls whether Process-Context IDentifier (PCID) is enabled in the TLB or not. The value of the PCID for the "current" process is stored in CR3 register, in bits 0 to 11 (12-bits in total). This implies that the TLB can store up-to 4KB unique PCIDs.

You can read Intel64 Software Developer Manual Volume 3, section 4.10.1 Process-Context Identifiers (PCIDs) for the details. These two articles are also helpful:
http://linuxeco.com/?p=488
http://linuxeco.com/?page_id=2

PS: Thanks to Johan over at linkedin for the links ;-)

Dr. Dobbs Article on Buffer Overflow Prevention with GCC

This article: http://www.drdobbs.com/security/anatomy-of-a-stack-smashing-attack-and-h/240001832 is very helpful for *NIX developer working with GCC compiler(s), especially those targeting x86_64 CPU architecture.

The article goes to great length explaining how the buffer overflow protection is built into GCC. The protection is known as GCC Stack Smashing Protector (SSP).

Alternative Way to Store Information -- Quipu

Chinese, Japanese or Korean "writings" are exotic but all of them are still writings as we know it.
How about this: http://en.wikipedia.org/wiki/Quipu.

Quipu is entirely different. What makes me really amazed is that it proved that you don't need the "writing system as we know it" to store information. Thus, to build complex stuffs or develop complex system. Well, Quipu is a "sort of" writing but it's far more different than what other cultures have developed over the last several millenia. It's an original idea, an out-of-the box solution to store and presumably transmit information.