Linked by Thom Holwerda on Thu 9th Sep 2010 13:00 UTC
Hardware, Embedded Systems So, we have Intel and AMD. These guys are doing pretty well in laptops, servers, and of course desktops, but when it comes to mobile devices, they've so far been unable to adapt the x86 architecture to the stricter requirements that come with those devices. ARM, on the other hand, pretty much owns this market at this point. And you know what? It's time for Intel and AMD to get worried - really worried. ARM has just announced its Cortex-A15 MPCore chips - which will reach 2.5Ghz in quad-core configurations.
E-mail Print r 9   · Read More · 75 Comment(s)
Thread beginning with comment 440157
To view parent comment, click here.
To read all comments associated with this story, please click here.
lucas_maximus
Member since:
2009-08-18

.NET hype is very real for ASP.NET applications and website. Pretty much every job around my Area in England is either ASP.NET.

These chips seem to be going being pushed for servers, where most ASP.NET applications are run, if the cost of the machines and the saving via power (which is very important for the organisation I work for since they have a large "green drive") is worth it, I can see organisations moving to this.

Reply Parent Score: 1

jabjoe Member since:
2009-05-06

Yes, for the server, it's different. I was talking about the desktop. On the server, you can throw hardware at the problem, there is one server. On the client, you can't throw hardware at the problem as there is N clients.

[The following is a bit of a rant, and probably should be taken with a pinch of sult]
But even on the server, native is still better as it means cheaper servers, but then it comes down to, is the server cheaper enough against the extra development-time/cost? I think byte coded can make sense on the server, but if you have the source, you can just compile it native for the hardware, which is always going to be better. Facebook php compiler is a example of doing this (compiled over interpretted). Yes byte coded languages compile to native, and sometimes even keep the native compile for reuse, but the compile must always be done quickly, which means full optimization isn't possible. The move from compiled-to-native language to compiled-to-byte coded languages is often paralleled to the move from assembler to compiled languages, but it's a false comparison. The jump in productivity vs the loss of performance are nothing like the same. What byte coded languages give you is the ability to run the same binary on multiple platforms, but in an open source world, we can just compile. It is cheaper to develop stuff in byte coded languages, if there is no competition, but when there is, the fastest one that gives the features required wins (assuming no cost all round). I see of the .NET move as mostly a critism of C++ on Windows, especially with MFC. If a nicer compiled language comes along (Google's Go?) the picture will change again. Or of course proper compiling .NET to native becomes common, but then you are back were you where with each company having to decide if it's worth doing. It's going to be interesting if MS try and use .NET to aid moving to ARM. It means they are going to be competing with something native on Linux against .NET things on Windows. What I guess MS will do, is native compile all their stuff, but tell everyone else to use byte code .NET, and tell people to use Mono so the same thing runs on Linux. Running on regardless of OS or chips. They can then try and use the whole chasing tail lights things to try and stay on top (like they did with WISE on Unix). Failing that, there is always use legal against Mono for anything "the promise" doesn't cover. Could be very Interesting times! :-)

Reply Parent Score: 1