About API's and CPU's

[The Keeper]

My first post here, I hope this is the right board to post this.

There are many different API's, like DirectX and OpenGL for graphics and PhysX API for physics accelerators for example. Because of these API's, developers have to write relatively little card specific code.

I was wondering why this does not apply to CPU's at all. If there was an API for CPU's, it wouldn't matter much if the CPU was an x86 or PPC based for example. Mostly only operating system kernel would need to be compiled for specific CPU architecture and the API would take care of rest.

There probably is a performance hit in using an API, but since DirectX and OpenGL is so heavily used for graphics, it can't be that bad, can it?

Probably a stupid question but it has been nagging me quite some time.

 

[CTho9305]

I was wondering why this does not apply to CPU's at all. If there was an API for CPU's, it wouldn't matter much if the CPU was an x86 or PPC based for example. Mostly only operating system kernel would need to be compiled for specific CPU architecture and the API would take care of rest.

Well, as far back as the IBM/360, the instruction set actually has been something like an API - some CPUs (all major x86 chips nowadays) translate the instructions internally to a different representation. Transmeta's CPUs took this to the extreme by executing one native instruction set and using software to translate x86 instructions.

There probably is a performance hit in using an API, but since DirectX and OpenGL is so heavily used for graphics, it can't be that bad, can it?

Well, part of what's going on is that the driver is compiling the API calls into GPU native code. You can view shaders as source code. This works out OK, because usually the GPU is running the same shaders for very long periods of time, and the shaders aren't all that long (so they can be compiled pretty quickly, and the compiled result can fit in a small amount of memory).

It gets a lot uglier for the CPU, because programs that run on the CPU tend to be gigantic, and there are large segments of code that are only run through a couple times. It takes a relatively long time to translate code to a native language, so it's only worth doing the up-front translation if the resulting code is going to be used many times (otherwise, it may be faster to just translate each instruction as it's executed). You don't really want to translate everything up front. The additional program size also makes it more expensive to store all the translated code in memory.

As it happens, if you ship programs as source code, you can compile them on the user's machine, and as long as you write portable code, it won't matter what architecture their CPU is. Some programming languages force you to write portable code by not providing features that can be used to write non-portable code (unfortunately in practice, they've historically been slower than C and C++).

Part of the complexity probably arises due to the nature of the x86 language. I could imagine that an architecture with more restrictions could be translated more easily (x86 instructions have all sorts of funky side-effects and corner cases which make it difficult to translate a whole binary and make sure that the result will be fast and correct). Java is pretty much what you're asking for - programs aren't shipped as true binaries but rather as half-compiled code (and that language is fairly simple and straightforward). The JVM then compiles the rest of the way dynamically when you run it. Unfortunately, Java turned a lot of people off to JITing, because its initial implementations were horrendously slow and bloated, and Java applications took forever to start up. You can actually do some pretty interesting things with JIT / dynamic recompiling - read up on the HotSpot JVM and HP's Dynamo project.

 

[BrownTown]

Well, in a way there are, you have the windows API functions to interface with the rest of the computer, and you can include your own libraries and such. But in the end, a CPU is a general purpose device, a GPU is special purpose. The variety of code executed on a CPU is far far in excess of what a GPU normally does, so it would be considerably harder to write a complete API containing every usefull function since there are so many. Also, the shaders in GPUs can be programmed in assembly, or in higher level shader languages, but if the programmer wants he can get down and effect the individual registers however he sees fit (within the constraints of the ISA which used to be VERY constrained, but in newer chips has many more registers, much more memmory, and allows much longer code fragments).