zubirus

>> If you look at effective highly scalable parallel codes of this nature, you see two big themes: pervasive latency hiding and designing the topology of the software to match the topology of the hardware

Do you have any good reference to learn general HPC and those topics? Best I could find when I searched last time was Udacity's High Performance Computing mooc and its reference book "Introduction to Parallel Computing".

By skimming through the code, this seems to have the same data-flow model as Intel's TBB, but extended to distributed memory configurations using MPI as backend.

I was mainly curious about the performance hit of drawing operations. But your subjective assessment is enough to understand that the penalty is lower than I expected.

While I agree with the article's reasoning, I never seen the argument on performance. Could it be that the overhead of Plan9 "everything is a file" abstraction was too much to handle when compared with the more pragmatic UNIX sockets?

Overall I love the Steam Machines idea. I have many games in my library and I can't wait to play them in the living room with my friends. I think that what Valve got wrong was just two topics:

- There is no game compatibility information. When I buy a console game, I know that the game will be compatible with my system. There is no such guaranty with Steam games. I would like to see a simplified benchmark tailored to pre-made Steam Machines so that consumers can understand how well they'll play their AAA games.

- They lost momentum with the SteamOS platform, and many developers are now skeptical of porting their games to Linux. The Steam Machines were supposed to be launched one year ago and with them their Linux platform. Some developers took a big investment to port their games to Linux and fight around subpar OpenGL drivers. When they were done there was no Steam Machines and they were met with a Linux userbase of just 1%. Now, I believe, we'll only see more Linux launches once the developers trust the Steam Machines as an established gaming platform.

Edit: formatting

The MPI+OpenMP duality has been around the HPC community as a for of heterogenous computing. Recently, with the addition of CUDA to the mix, HPC codes have added yet another code path; I'm skeptical about the maintainability of such systems. It's sad because the three tools exist to solve the same data-parallel paradigm, albeit in different configurations. In an alternative universe, where plan9 had succeeded, I could see this issue addresses by the OS, but I imagine a well designed library+runtime to fill this gap perfectly well. Intel's TBB addresses the shared-memory problem with a work graph, could we extend such philosophy to the three tools?

Very nice and polished game! Small problem I encountered: whenever I died in the game, the dungeon I respawned at was much easier than the initial one.

I've been reading about Plan9 for a while. While I love the elegance of everything being a file addressable through the 9P protocol, I wonder about the feasibility of piping a "framebuffer" or other heavy process. Does someone know how the Plan9 holds, in this area, agains Unix in performance?

>> In this approach, threads own their data, and communicate with message-passing.

This is the same paradigm as MPI, the message parsing interface. Using it, you also get for free the ability to deploy your "threaded" code in distributed memory architectures. But any person who had just a bit of experience with this standard can tell you how tedious is to develop a parallel code with it. Maybe this is product of the paradigm or just the verbosity of the API (see for example: http://www.mpich.org/static/docs/v3.1/www3/MPI_Alltoallv.htm...).I wish there was some sort of OpenMP or Intel TBB equivalent for MPI to ease out the pain.

The abstract reads "Nicotine addiction negatively correlates the changes of developing Parkinson's disease". I'm not a fan of the wording of the HW title to make it sound like smoking could be a good habit.

> As described in Section 3, our prototype uses a loadable kernel module to [allow the GPU to monitor the keyboard buffer]. We should note that this choice was made only for convenience, and the same stealthy approaches that are typically used for the installation of kernel-level rootkits can be employed, e.g.,by exploiting a vulnerability and injecting malicious code directly into the kernel.

I'm not a security expert, so could the binary kernel module for the NVIDIA driver be exploited for this effect?