INightmare's ideas

AMD Kaveri is a a long awaited major leap forward in PC hardware. While we have CPU and GPU combined into one chip for quite some time, this brings a limited advantage over having them separate. What Kaveri brings is a shared memory architecture, that is GPU can use the same memory CPU does and vice versa. Including virtual memory.

Why am I calling this a "major leap forward"?

In all kinds of applications involving GPU, whether it's general purpose computations (using something like CUDA or OpenCL) or games a lot of time is actually spent copying memory buffers back and forth between CPU memory (RAM) and GPU memory. And all that copying is quite expensive. Having a more direct access to GPU memory is one of the reasons why game consoles are so much better at running games when compared with the same generation of PC hardware.

Games do a lot of copying. You need to load textures to GPU memory. First they are loaded to CPU memory and only then transfered to GPU memory. In case of games that use mega texturing (like Rage) it happens almost every frame. Also all games would pass vertex data, shader parameters, maybe even do some processing on buffers produced by GPU on CPU. If a game uses GPU accelerated physics there's even more data that is exchanged with CPU.

With Kaveri all of the data produced by CPU can be immediately made available for GPU to use.

That easy?

Not quite. While this all sounds awesome, there are some catches. While a faster direct use of GPU memory will be available as a hardware feature, it might take some time for software to catch up. While OpenCL is built with such capability in mind and some programs might even work faster out of the box, APIs like DirectX and OpenGL are a bit different. There will have to be an update for those APIs to enable this kind of zero copy memory sharing. While OpenGL can add this through extensions, DirectX is a bit more complicated.

Today I have setup maven repository for Dirmi. A nice bidirectional remoting sollution, intended to replace RMI.

Sharing it with the world.

URL: http://inightmare.org/maven2

Including into your project:

<dependency>
    <groupId>org.cojen</groupId>
    <artifactId>dirmi</artifactId>
    <version>1.0.6</version>
</dependency>
<dependency>
    <groupId>org.cojen</groupId>
    <artifactId>cojen</artifactId>
    <version>2.2.1</version>
</dependency>

I hope you'll find this useful.

Today I read the post by Internets highly respected author Neil McAllister where he responded to WHATWGs plans to drop HTML version numbers. You can read the whole article here.

He claims that dropping HTML version numbers will cause troubles for web application authors. Cite: "Once they do, their customers will end up with a browser that supports some form of HTML as it was specified at some point in time. Without so much as a version number to go by, it will be virtually impossible for the customer to understand -- or even express -- just what form of HTML that actually is."

Why would anyone care? It's not the standard version that matters, but separate features! And it's a common practice to check for the presence of the feature rather than supported HTML version. New HTML spec comes out once in few years, but separate features may show up any time. Why not start supporting it before its done? Lots of HTML5 features are already being used and users benefit a lot from those.

My suggestion is to complete separate feature standards and rely on that, rather than a whole pack of them.

Today I decided to run a SunSpider test on 4 popular browsers for Linux. Tested on my Asus F3Ka laptop. Here are the results:

• Opera 10.63 - 1300.2ms
• FireFox 3.6.11 - 3002.0ms
• Chromium 6.0.472.63 - 1096.2ms
• Rekonq 0.6.1 - 1678.4ms

It seems that FireFox is really behind all the other browsers. Unexpected I would say.

I always thought world needs a fast MVC framework for Java. As flexible and nice as say Ruby on Rails or Grails, but where controller actions where written in a faster languages such as Java. Current Java MVC frameworks (suchs as Struts or Spring Web MVC) are far from the beauty the former frameworks provide.

But... Today I was enlightened by my friend, who showed the Play Framework:

http://www.playframework.org/

The answer to Java web developer prayers. Thank you.