Mashed Articles

The end is nigh for the modern graphics chip. It genuinely pains me to say that. After all, I’m an unapologetic chip aficionado, someone who loves the technology of integrated circuits for the sake of it. But it’s becoming increasingly apparent that GPUs are over-engineered, increasingly irrelevant and almost definitely not long for this world.

The background here involves a confluence of technological trends. The most ominous of these in terms of the GPU’s longevity as a discrete component is the architectural convergence of CPUs and GPUs. However, one of the most debilitating symptoms of the graphics chip’s terminal malaise is complexity – sheer, pointless complexity. Take Nvidia’s latest uber pixel pumper, the GeForce GTX 480. It weighs in at three billion transistors. That’s getting on for triple the size of Intel’s beefiest PC processor, the six-core Core i7-980X.

If the GTX 480 was any use, that monster transistor count would actually add to the allure. But the harsh truth is that it isn’t – for almost anything. And that makes it dumb. You see, despite the hype regarding running non-graphics applications on GPUs, there’s still very little outside of games that makes more than passing use of a desktop or laptop GPU. More to the point, the number of games demanding a really high-end GPU that are actually worth playing isn’t merely a small number. It’s zero.

Put it all together and you have a terminal mismatch between the cost and complexity of GPUs and their real-world utility. In truth, I’ve felt this way for some time. But it’s the apparent emergence of a radical alternative to established 3D rendering technologies that really brings home how bloated and ludicrous graphics chips have become.

This alleged revolution in rendering comes from a small Australian software startup known as Unlimited Detail. It’s not actually brand spanking new, having been in development for a year or three. But thanks to the random nature of web-based content aggregators, Unlimited Detail was lifted from obscurity recently in a flurry of YouTube-powered publicity.

Anyway, as far as I could tell the basics of this new rendering technology involve ditching polygons in favour of atomic points in 3D space. The claimed result is quite literally unlimited geometric detail. Oh, and the whole thing runs in software at smooth framerates on a conventional PC processor. The GPU doesn’t get a look in until it’s time to spit out the final 2D images.

You hardly need me to point out it all seems too good to be true. So, there was nothing for it other than to go straight to the source and speak to the guys at Unlimited Detail. The technical brains are provided by Bruce Dell, a former supermarket manager, while the business nous comes courtesy of Greg Douglas, a games insider formerly of developers Auran.

The idea of using atoms or points is not new, of course. The really clever bit in UD is the 3D search algorithm developed by Dell. The precise details are UD’s big secret. But according to Dell, “The algorithm takes point cloud data and files it in a certain way so that it can be quickly sorted and accessed.”

When the algorithm searches for points, it doesn’t do so indiscriminately. Instead, it only pulls up a single point for each on-screen pixel being rendered. “We only grab the atoms we need for each pixel, we don’t touch the others,” explains Dell. In other words, the workload depends on screen resolution, not the underlying geometric detail of the scene being rendered. Thus, an impression of unlimited geometry is created.

The UD guys claim the algorithm is so efficient it runs in real-time in a single thread on just one core of a conventional PC processor. Apparently, it will even scale down to simple CPUs in mobile devices.

So far, the only hard evidence for these incredible claims takes the form of a few pre-recorded videos of dubious quality. However, having spoken to the UD pair, I’m happy to confirm they’re not only incredibly passionate, but strike me as completely genuine. It’s potentially extremely exciting stuff.

Still, even if UD works exactly as advertised, the established players in graphics are hardly going to embrace a technology that instantly renders several decades and billions of dollars of investment obsolete overnight. You have to assume Nvidia, and to a lesser extent AMD, will resist the idea strongly. But if Unlimited Detail’s technology gains any traction at all, GPUs really will look sillier than ever.

And so it happened: on 28 of May, I entered the realm of the fanboy. Early morning saw me queueing outside the Apple Store in Bath, eager to get my hands on one of the first British iPads. As the utterly incongruous whooping and hollering began to emanate from the bowels of the store – and those in the queue looked around sheepishly, hoping they wouldn’t be expected to HIGH FIVE! – we knew we were just seconds away from the doors being thrown open to… yet more queuing. This is how these things tend to play out. It was a bit crap, really – especially considering that over the following few days, I couldn’t move for sodding iPads. Still, unfounded fears of gadget scarcity aside, what the queuing did reveal was a serious amount of excitement about a bit of kit that most of the assembled shoppers hadn’t even played with yet. iPad fever appears to have landed in Blighty, too.

For the past few weeks, I’ve had to listen to gushing accounts from our American cousins about how great the iPad is (as well as a few crowing importers who couldn’t wait to experience the joy of Apple’s new device). At last, I can finally make a few observations based on more than blog posts and Twitter witterings myself.

1. The iPad is going to be huge!

I’m not really saying anything new here, but there were reports that claimed the iPad wouldn’t resonate with the British. Simpson Carpenter’s qualitative research concluded that the iPad “won’t be mass market in the UK”. ‘Mass market’ is a very vague term, but the report did get more specific, claiming that “the iPad will take longer to achieve the sales growth and wider market impact of the iPhone”. My qualitative observations don’t quite reflect those of Simpson Carpenter. For instance, the last time I visited an Apple Store, around 100 people were assembled around the iPad display area, leaving the flashy new MacBook Pros feeling like Woody in Toy Story! The people responsible for this research may need to rethink their esteemed judgement, given that the iPad has already pushed past two million global sales.

2. March of the web apps

The iPhone’s big story was the sheer number of apps you could download from the App Store, which was perfectly summed up in Apple’s ‘There’s an app for that!’ marketing campaign. But I think the iPad’s 1,024 x 768 pixel resolution will provide a great canvas for developers wanting to create web apps that utilise the strengths of the next generation of web standards, such as CSS3 and HTML5. The iPad version of Safari doesn’t have full support for these technologies just yet, but you can see some great examples of what it does support.

If monetisation isn’t your primary focus, then the simpler development route (using web standards, rather than Cocoa Touch) and cross-platform support should see a big increase in optimised web apps. Gmail is already optimised for the iPad, but there are still issues for developers: take Google Docs, for example. As things stand, Safari for iPhone OS does not support ‘contenteditable’ (which is used to enable text input within a styled element), but contenteditable is an integral part of the code that powers Google Docs (and many other web apps). Bummer! There are claims that version 4 of the iPhone OS will support contenteditable, and this will be an important addition – requirement, even – if web apps are to take off in earnest on the iPad.

Is the iPad a laptop replacement?

No. It’s already become patently obvious to me that trying to execute certain processes just doesn’t work on the iPad. Tasks such as heavy word processing, and any editing job that requires precision mouse control, are severely limited by the iPad’s design (and the need to navigate the device using a chubby skin stylus, otherwise known as your finger). But what you have in the iPad is a perfect bridging device: one that enables you to take care of day-to-day tasks for which a laptop has become overkill. Watching videos, playing games, checking email and browsing the web no longer require a laptop, and the iPad looks set to launch a new wave of optimised sites and apps that address the challenges of designing for gesture-based tablets. It’s only once you’ve had the device in your possession for a while that you begin to realise the impact it could have on the development, design and consumption of digital media.

Although languages like APL, Prolog and COBOL might seem unusual to many of today’s programmers, they are serious languages developed to address a specific requirement or a particular model of programming. We’re looking here at those languages that have been designed, first and foremost, to be odd. Referred to as esoteric programming languages, some are intended as jokes, some as parodies of other languages, whereas others were designed to be downright strange.

Esoteric programming languages: is there room in your brain for these nutty devices?

Bizarre or not, though, all of them truly are programming languages in the sense that they really can be used to provide instructions to your PC. Our intention here isn’t to show you a lot about any one language – after all, you’re not exactly going to be using them for genuine programming projects – but to look at three of then, fairly briefly, to give you a feel for the variety of esoteric languages.

INTERCAL

The names of programming languages are often acronyms that give some clue as to their purpose. So BASIC is Beginners All-purpose Symbolic Instruction Code, COBOL is COmmon Business Oriented Language and FORTRAN is FORmula TRANslation. So you start to get a feel for INTERCAL when you read in the manual (which you can find at www.muppetlabs.com/~breadbox/intercal/intercal.txt) that its full name is “Compiler Language With No Pronounceable Acronym, which is, for obvious reasons, abbreviated INTERCAL”. It was designed with the aim of being as obtuse as humanly possible, mainly so you that you can amaze your fellow programmers by your ability to do something useful in this bizarrely complicated language which was designed specifically to have nothing at all in common with any other major language.

Ironically, since our stated aim is to show you how to program in esoteric languages, we’ve not even going to try with INTERCAL. Instead we’ll show you how to use the INTERCAL-J compiler using a sample program provided and then we’ll leave you to peruse the manual. We suggest you do this in a darkened room and clear a week or two from your diary before you start. If you consider this a dereliction of our duties, take a look at the INTERCAL program below, which has been provided to illustrate how fiendishly involved even a simple program can be. Its purpose is to read in 32-bit unsigned integers, treat them as signed, 2s-complement numbers, and print out their absolute values, terminating if the absolute value is zero. A comparable APL program runs to 16 characters.

DO (5) NEXT
(5) DO FORGET #1
PLEASE WRITE IN :1
DO .1 <- 'V":1~'#32768$#0'"$#1'~#3
DO (1) NEXT
DO :1 <- "'V":1~'#65535$#0'"$#65535'
~'#0$#65535'"$"'V":1~'#0$#65535'"
$#65535'~'#0$#65535'"
DO :2 <- #1
PLEASE DO (4) NEXT
(4) DO FORGET #1
DO .1 <- "'V":1~'#65535$#0'"$":2~'#65535
$#0'"'~'#0$#65535'"$"'V":1~'#0
$#65535'"$":2~'#65535$#0'"'~'#0$#65535'"
DO (1) NEXT
DO :2 <- ":2~'#0$#65535'"
$"'":2~'#65535$#0'"$#0'~'#32767$#1'"
DO (4) NEXT
(2) DO RESUME .1
(1) PLEASE DO (2) NEXT
PLEASE FORGET #1
DO READ OUT :1
PLEASE DO .1 <- 'V"':1~:1'~#1"$#1'~#3
DO (3) NEXT
PLEASE DO (5) NEXT
(3) DO (2) NEXT
PLEASE GIVE UP

So to business and in particular we’re going to compile and run a program that prints out prime numbers. J-INTERCAL runs from the command prompt so Select Run… from the Windows Start menu, enter ‘cmd’ into the Open box in the Run window before clicking on OK. Then, at the prompt in the command line window, type ‘cd c:\jintercal-0.12\samples\’ and you’ll notice that the prompt will change to reflect the new default directory which is, in fact, the one where you’ll find an INTERCAL source file called primes.i. To compile it, type ‘Java intercal.Compile primes.i’, noting the capital C in ‘Compile’. All being well it will create the Java class file primes.class that you’ll be able to see if you type ‘dir’ at the prompt to list all the files in the folder. Now to run it, type ‘Java primes’ and you’ll see prime numbers flash down the screen expressed as Roman numerals which is INTERCAL’s standard form of output.

Brainfuck

INTERCAL programs are long and convoluted, aided and abetted, to no small degree, by the requirement to write polite programs with sufficient PLEASE statements included. Not so with the inappropriately sweary Brainfuck. Its programs couldn’t be more different. The aim was to implement a language with the smallest possible compiler – the compiler we’re using is just over 2Kbytes in length (yes, Kbytes, not Mbytes) and the record is somewhat less than 200 bytes. This required simplicity and despite the fact BF is Turning complete, meaning that it can perform any computation that “serious” languages can perform, it has just eight instructions, each of which is represented by a single character. That doesn’t make for the most readable program – so again you’ll reach guru status if you can master it – but it does mean that we can teach you the language in its entirety.

There is no concept of named variables, as there is in most languages. Instead BF has a string of 8-bit memory locations and a pointer that records which of those locations the current instruction will operate on. Initially all the locations contain zero and the pointer is initialized to the left-most location. With that bit of background we can now introduce the eight instructions, which are:

+    Increment the value at the pointer
-    Decrement the value at the pointer
>    Move the pointer to the right
<    Move the pointer to the left
[    Start of loop
]    End of loop (exit if value at pointer is zero)
,    Input an ASCII character and store it at the pointer
.    Print the ASCII character at the pointer

Of course a simple instruction set invariably means a complicated program so the simplest of operations, that might be achievable in a single instruction of a conventional language, can take dozens of instructions in BF. As an example we’re going to create a program that accepts two single digit numbers as its input and outputs their sum. The program to do this is as follows and, despite the fact it has 30 instructions, it still only works correctly if the answer is represented by a single decimal digit:

, > + + + + + + [ < - - - > - ] , [ < + > - ] < .

Your first job is to create a file containing the code showed above using Notepad. Since the space character isn’t a valid instruction it’s ignored and although we put a space between each character to make the code easier to read, you can leave them out. Note also that the full-stop at the end is part of the program. Call the file add.b and place it in the c:\bfd100 folder. Actually Notepad will try to give the file the name “add.b.txt” so you’ll have to rename it in Windows Explorer.

Now start up the command line window and change the directory to c:\bfd100\ – if you’re not familiar with command line prompts we did something very similar when we started to use INTERCAL. At the prompt type ‘bfd add.b’. BF will respond with the message ‘File assembled’, and if you do a directory listing you’ll see that the file add.com has indeed been created. This is a DOS executable file so all you have to do to execute it is to type ‘add’ at the prompt. Now type in your two one-figure numbers (with no space or punctuation between them) and the program will display their sum, immediately after the input, again without a separating space.

Now a slight aside. To be quite honest, of the three languages here, BF is the only one that you might want to delve into. After all, it’s quite an interesting language in its own way, in contrast to the others which are, quite frankly, plain dumb, and that’s being charitable. So to start you on your voyage of discovery, let’s see how the simple program above manages to add together two numbers.

The comma reads the first of the two figures and places it where the pointer is positioned which is, initially, in the left most memory location. However, the value read is an ASCII character which, for the figures 0 to 9, are the codes 48 to 57 so, to yield the actual number represented, we need to subtract 48. That’s achieved with the rest of the code up to but not including the second comma. It does that by moving the pointer to the right and incrementing that memory location six times so that it contains the value 6 which will then be used as a loop counter. Next it enters a loop that decrements the ASCII code eight times and the loop counter once. Since this loop will execute eight times, and each time it will subtract six from the ASCII code, when it does exit 48 will have been subtracted from the value input. The second comma inputs a second ASCII code which, because of the position of the pointer, will be stored one location to the right of the first value and again this will be used as a loop counter. The second loop causes the first value to be input (now decremented by 48) to be incremented as many times as the value of the second ASCII code input. When the loop exits, the value in the left-hand memory location (which is a valid ASCII value for a digit since we only subtracted 48 from one of the input values) is printed out.

BF commands might be terse but that doesn’t mean that programs can’t be made readable. Since all but the eight characters representing instructions are ignored, comments can be placed anywhere, as the following program shows.

===INPUT NUMBER===
+      cont=1
[
-      cont=0
>,
======SUB10======
----------

[      not 10
<+>     cont=1
=====SUB38======
----------
----------
----------
--------

>
=====MUL10======
[>+>+<<-]>>[<<+>>-]< dup

>>>+++++++++
[
<<<
[>+>+<<-]>>[<<+>>-]< dup
[<<+>>-]
>>-
]
<<<[-]<
======RMOVE1====
<
[>+<-]
]
<
]

Java2K

Unlike our previous two languages which were supported by compilers, Java2K is implemented as an Integrated Development Environment (so it’s a bit of a mystery why it’s referred to as DIE for Win32 instead of IDE). But before you get too excited, this doesn’t mean a fancy integrated editor and all the works, it just means that immediately after compiling the code it runs it. To start it just double click on the Java2K.exe icon in the c:\java2k\ folder it’ll open in a command line window and announce its presence with the rather puzzling statement “ELVIS HAS LEFT THE BUILDING AT 0.0.1900 <chair>:”. To see it in action just type the name of one of the sample Java2K programs supplied, say “26”, and you’ll see the output which, in this case, is the letter “F”. Having seen something of the astonishing power of this remarkable language you’ll be eager, no doubt, to try out more of the sample programs. However if, for the moment, you can get over your understandable excitement, we’ll first take a look at Java2K behind the scenes.

Like INTERCAL and most other languages, but unlike BF, Java2K has operators that work on variables. Like BF, Java2K is obscure in the extreme but whereas in the case of BF that was by necessity (i.e. to achieve the goal of producing a tiny compiler), in the case of Java2K it’s by design. First of all, where most languages use decimal numbers, perhaps with the option of binary, octal or hexadecimal, Java2K uses numbers to the base 11 which, as the manual points out, is close enough to decimal. Because base 11 numbers require an additional digit to the usual 0-9, Java2K uses 0-9 plus space. The upshot of this is that since a space will be interpreted as the number ten, spaces can’t be used just to make programs more readable. Second, function names are numbers rather than words, and so too are the names of variables. So you can forget, for example, of using meaningful variable names such as “Total” or sensible instruction names such as “Print”. In the case of this latter instruction Java2K uses the instruction “1 1 “ (note the two spaces, after all this is a base 11 number) instead. And finally, on the subject of obscuration, because numbers are interpreted as functions or variables, you can’t use them as numerical constants. Instead, if you want to refer to the number one, you have to use some function that will produce 1 as its output. The classic way of doing this is to use the code “11 6/*/_\”. If we point out that “11 6” is the divide function, “*” returns a random number, “_” repeats the previous argument, “/” is a separator and “\” is an end-of-instruction marker, it should be clear that this will produce a 1. Surprisingly, then, this statement isn’t quite correct as we’re about to see.

1 1 /125 /131 /119 /125 /11 6/*/_\/_\/125 /13 2
/*/_\/_\\/131 /119 /125 /11 6/*/_\/_\/125 /13 2
/*/_\/_\\/119 /125 /11 6/*/_\/_\/125 /13 2/*/_\
/_\\\\/131 /119 /125 /11 6/*/_\/_\/125 /13 2/*/
_\/_\\/131 /119 /125 /11 6/*/_\/_\/125 /13 2/*/
_\/_\\/131 /119 /125 /11 6/*/_\/_\/125 /13 2/*/
_\/_\\/131 /119 /125 /11 6/*/_\/_\/125 /13 2/*/
_\/_\\/131 /119 /125 /11 6/*/_\/_\/125 /13 2/*/
_\/_\\/119 /125 /11 6/*/_\/_\/125 /13 2/*/_\/_\
\\\\\\\/*\1 1 /125 /119 /11 6/*/_\/13 2/*/_\\/
125 /131 /119 /125 /11 6/*/_\/_\/125 /13 2/*/_\
/_\\/119 /125 /11 6/*/_\/_\/125 /13 2/*/_\/_\\\
/125 /131 /119 /125 /11 6/*/_\/_\/125 /13 2/*/_
\/_\\/131 /119 /125 /11 6/*/_\/_\/125 /13 2/*/_
\/_\\/131 /119 /125 /11 6/*/_\/_\/125 /13 2/*/_
\/_\\/131 /119 /125 /11 6/*/_\/_\/125 /13 2/*/_
\/_\\/119 /125 /11 6/*/_\/_\/125 /13 2/*/_\/_\\

Using the Java2K IDE (sorry, DIE) run the program 13 which is supposed to display “Hello, World”. We’ve included a small chunk of it above. Run it a few times and you’ll probably notice something odd – it doesn’t always get it right. The reason for this is that unlike virtually any other language, Java2K is a probabilistic language rather than a deterministic one so all its functions generate the “correct” answer only 90% of the time; for the remaining 10% it will give a random result. So the method of generating a one that we saw above only has a 90% chance of success. And that’s just for generating a one. The obvious way of generating a two is to add two ones together using the code “125 /11 6/*/_\/_\” but we’re now introducing another instruction that also has a 90% chance of success so the combined likelihood of getting the expected result drops to 81%. In this light of this you might find it surprising that the program 13 manages to produce “Hello, world” as often as it does.

The fact is that there are clever tricks that Java2K programmers can use to improve a program’s success rate but the result is that even the simplest of programs can be extremely long, not to mention virtually incomprehendable. As proof of this why don’t you take a look at program 13 using Notepad. Having done so we suggest that you use the experience to convince yourself that there are better ways of spending your time than attempting to learn Java2K. If you choose to ignore this advice you’ll find the programming manual, in all it succinct glory, at www.p-nand-q.com/humor/programming_languages/java2k/manual.html but we won’t be responsible for the consequences.