NVIDIA Announces ARM CPU for Desktop, Server, HPC
Linked by Thom Holwerda on Wed 5th Jan 2011 21:22 UTC
Hardware, Embedded Systems Just - just hold on a second. This is big: NVIDIA, maker of graphics accelerator chips, has just announced, during its keynote at CES, that it is developing a high-performance ARM-based processor together with ARM, targeted squarely at the desktop, server, and even high-performance computing markets. That Windows on ARM thing? NVIDIA referenced it multiple times! Update: Boom, and we have a press release. "NVIDIA announced today that it plans to build high-performance ARM based CPU cores, designed to support future products ranging from personal computers and servers to workstations and supercomputers. Known under the internal codename 'Project Denver', this initiative features an NVIDIA CPU running the ARM instruction set, which will be fully integrated on the same chip as the NVIDIA GPU."
E-mail Print r 12   · Read More · 82 Comment(s) http://osne.ws/ioh
Thread beginning with comment 456324
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: games
by lemur2 on Fri 7th Jan 2011 11:49 UTC in reply to "RE[2]: games"
lemur2
Member since:
2007-02-17

"One merely needs to take the C++ source code and compile it for the ARM architecture which one is targetting. One thereby produces an ARM executable binary, not an x86 executable binary, for the exact same game application.


In theory, this approach should work fine. But in practice it's not going to be anywhere near as simple as that.

For instance, game producers could very well find themselves facing a situation in which they need to link their application against some third party library. If they've been linking to that library as an x86 binary, there's no guarantee that they'll be able to obtain corresponding binaries for ARM. Depending on the level to which they rely on that library, this could end up being a complete show stopper for many projects. "

If true, this has nothing at all to do with either C++ or games, it is a completely separate issue.

Insofar as this issue itself goes ... I thought that the general rule on Windows was not to dynamically link libraries. That is to say, it wasn't advisable on Windows to simply expect another library of the correct version to already be installed on a system, so that one can link to it, but rather one included any required libraries within one's own application code (that is, typically all required libraries are statically linked for every application). In turn, this is the reason why the same number and complexity of Windows applications requires many times more disk space than Linux applications.

Reply Parent Score: 2

RE[4]: games
by Darkmage on Fri 7th Jan 2011 13:25 in reply to "RE[3]: games"
Darkmage Member since:
2006-10-20

It'll be interesting to see what is actually available for this platform when it is released. Does this mean wine is going to need a rewrite to become compatible with Windows ARM applications? On day one of release Linux will have more applications and how long will it take for Microsoft partners to catch up? In terms of marketshare I'm skeptical of what this will mean for both linux and windows.

Reply Parent Score: 1

RE[5]: games
by lemur2 on Fri 7th Jan 2011 13:44 in reply to "RE[4]: games"
lemur2 Member since:
2007-02-17

It'll be interesting to see what is actually available for this platform when it is released. Does this mean wine is going to need a rewrite to become compatible with Windows ARM applications?


Wine Is Not an Emulator.

http://wiki.winehq.org/Debunking_Wine_Myths#head-3049e5862dfd3e6de4...

Wine right nows runs on x86 only because Windows executables run on x86 only.

AFAIK, if one were to re-compile Wine source code to target ARM, then the resulting Wine for ARM program would run Windows for ARM executable binaries on Linux ARM machines.

On day one of release Linux will have more applications and how long will it take for Microsoft partners to catch up? In terms of marketshare I'm skeptical of what this will mean for both linux and windows.


The Linux community has source code for the majority of Linux applications, there are relatively few closed source drivers and applications for Linux. It would be utterly stupid for a hardware OEM to make an ARM system right now for which there was no open source Linux driver for some of the components. All ARM systems will have all open source drivers for all components. Almost the entire Linux ecosystem software ensemble is available right now for ARM.

http://www.linuxine.com/story/ubuntu-based-arm-server-runs-80-watts
http://www.linuxfordevices.com/c/a/News/ZT-Systems-R1801e-/?kc=rss
http://www.computersandcomputersoftware.com/?p=1591

Windows is almost the exact reverse. Microsoft holds the source code for only the bare OS and a very few applications and drivers, all other source code for Windows is held by third parties.

This means that when Windows for ARM is first released, there will only be the bare OS itself and MS Office and a few other Microsoft applications available for it. Microsoft will have to plead with hardware OEMs to create systems with only components for which Microsoft is in a position to provide drivers.

As a consequence, when it first comes out, Windows for ARM will be very much a Johnny-come-lately that works fully only a very few selected ARM machines and with very few available applications.

Edited 2011-01-07 13:53 UTC

Reply Parent Score: 2

RE[4]: games
by BeamishBoy on Fri 7th Jan 2011 16:10 in reply to "RE[3]: games"
BeamishBoy Member since:
2010-10-27

If true, this has nothing at all to do with either C++ or games, it is a completely separate issue.


Not so.

Insofar as this issue itself goes ... I thought that the general rule on Windows was not to dynamically link libraries. That is to say, it wasn't advisable on Windows to simply expect another library of the correct version to already be installed on a system, so that one can link to it, but rather one included any required libraries within one's own application code (that is, typically all required libraries are statically linked for every application).


This is to rather completely miss the point of what I was saying. The issue is not what libraries are available to be installed with the application when it's deployed; that's a secondary concern. The real issue arises when there's a chance that needed libraries won't be available even to the developer because the producer of a library hasn't made them available for ARM.

I understand that everyone likes the idea of portable code as an ideal. Unfortunately, things don't work like that in practice when you're dealing with C++. Even something like Boost, a wonderful and almost entirely header-only library, has significant components that need to be built explicitly before use.

Reply Parent Score: 1