Linked by Thom Holwerda on Wed 18th May 2011 21:50 UTC, submitted by fran
Windows The ARM version of Windows 8 might have just become the most desired version of Windows in our hearts and minds. After us talking about legacy code and backwards compatibility in Windows for years now, an Intel senior vice president, Renee James, has just stated that Windows 8 on ARM will not have any form of compatibility for legacy applications whatsoever. Update: Microsoft has responded to Intel's claims. "Intel's statements during yesterday's Intel Investor Meeting about Microsoft's plans for the next version of Windows were factually inaccurate and unfortunately misleading," the company said, "From the first demonstrations of Windows on SoC, we have been clear about our goals and have emphasized that we are at the technology demonstration stage. As such, we have no further details or information at this time."
Thread beginning with comment 473699
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Comment by orestes
by toomuchtatose on Thu 19th May 2011 08:55 UTC in reply to "RE[3]: Comment by orestes"
toomuchtatose
Member since:
2011-05-15

As long as the underlying HAL is code-optimised (crucial job for OS developers), developers shouldn't be so engrossed with the performance of the architecture. I think that is his/her perspective.

But of course, the race to productivity is another issue, essentially it is my opinion that not any amount of assembly-optimisation can replace bigger monitors, better desk and chair, a good keyboard and mouse, for work requiring interactivity.

Else, non-interactive work should be relegate to something like itaniums, x86, ppc or sparc....

Reply Parent Score: 2

RE[5]: Comment by orestes
by toast88 on Thu 19th May 2011 23:54 in reply to "RE[4]: Comment by orestes"
toast88 Member since:
2009-09-23

As long as the underlying HAL is code-optimised (crucial job for OS developers), developers shouldn't be so engrossed with the performance of the architecture. I think that is his/her perspective.

Sorry, but this is non-sense. Anyone is interested in A/C codecs and JIT compiler with decent speeds, this got nothing to do with productivity.

If you want to find out what difference hand-optimized assembly code makes, just compare the JavaScript performance of Internet Explorer (32 bit) with the JavaScript performance of its 64 bit counterpart which does not yet have a JIT compiler.

Ask yourself why it took Sun ages to port the Java plugin to x86_64 or why Adobe still hasn't been able to push Flash on 64 bit further than beta status. It's because they have to keep up the assembly.

You're probably also going to tell me that one never needs more than one CPU cores because one person cannot perform more than one task at the same time, right? (completely neglecting high performance applications like data centers, rendering farms, compute clusters etc)

Adrian

Reply Parent Score: 1

RE[6]: Comment by orestes
by toomuchtatose on Fri 20th May 2011 16:38 in reply to "RE[5]: Comment by orestes"
toomuchtatose Member since:
2011-05-15

You made a point of "performance" which is the argument of the previous poster, but not the crux of my argument.

I take your argument is something along the lines of: If people want a faster Internet Browser on ARM, not any amount of 'simple porting' of IA-32 optimised code to ARM will work.

My argument is:

1) However, if people wants just a simple application e.g. internet browser on ARM, there are alternatives. E.g. Chromium initially requires SSE2 to compile but such dependencies are removed in order to run on ARM and pre-pentium 4 computers.

2) If productivity does not depend on the cpu performance (e.g. word processing, emails, stuff), one should never put performance as a priority.

3) Keeping hardware optimisation at the application level is absurd (IMO) for most applications, such optimisations should remain hidden under the OS. Only when very high performance/accuracy is required that developers should 'peer' closer to hardware.

4) You trying to 'put the point about CPU cores' does not make any sense to me, I assume you know more about CPUs than I do.

Reply Parent Score: 1