status update 1 (Re: assembler speed...)
in [ASM]
|
Prev: x86 instruction set usage-difference between windows 95 and windows xp ?
Next: peter-bochs-debugger is a GUI debugger for bochs
From: Nathan Baker on 8 Apr 2010 15:13 "cr88192" <cr88192(a)hotmail.com> wrote in message news:hp2s82$c8o$1(a)news.albasani.net... > > "wolfgang kern" <nowhere(a)never.at> wrote in message > news:hp2prm$ki5$1(a)newsreader2.utanet.at... >> >> So I actually wont care the time to assemble a piece of code >> as long the end-user get what he expect in terms of reliabilty >> and performance. [C-\+users and friends may see this different]. >> > > well, the simple answer for this one is for people not to write apps in > Python... > > Python is convinient for some developers, but many of the apps I have had > the most frustration with have been Python apps (poor performance, > randomly failing due to runtime errors, ...). > Scripting languages provide beneficial aspects to a specific set of use cases -- situations where using compiled (or hand-coded ASM) code would be a ridiculous choice. That said, I do see a small trend back to a performance-oriented development approach -- due to failure of CPU makers to address the issue. One, Google developed a new 'system programming language' called "Go" which brings some scripting-language features to the table.. amoung other goodies. Two, Facebook developed a compiler for a derivative of PHP... and it outperforms existing JIT implementations. Nathan.
From: James Harris on 8 Apr 2010 16:51 On 8 Apr, 20:13, "Nathan Baker" <nathancba...(a)gmail.com> wrote: .... > That said, I do see a small trend back to a performance-oriented development > approach -- due to failure of CPU makers to address the issue. What have the CPU makers not done? James
From: Nathan Baker on 8 Apr 2010 17:48 ----- Original Message ----- From: "James Harris" <james.harris.1(a)googlemail.com> Newsgroups: alt.lang.asm,comp.lang.misc,alt.os.development Sent: Thursday, April 08, 2010 4:51 PM Subject: Re: status update 1 (Re: assembler speed...) > On 8 Apr, 20:13, "Nathan Baker" <nathancba...(a)gmail.com> wrote: > > ... > >> That said, I do see a small trend back to a performance-oriented >> development >> approach -- due to failure of CPU makers to address the issue. > > What have the CPU makers not done? > There was a time when, every few years, the CPU clock speed seemed to be increasing geometrically... 1 MHz 8 MHz 25 MHz 90 MHz 133 MHz 500 MHz But when they got into the GHz range, the trend stopped. There is no longer a "user noticable" increase in performance gained by purchasing new hardware. This places the burden on software. Nathan.
From: James Harris on 9 Apr 2010 06:10 On 8 Apr, 22:48, "Nathan Baker" <nathancba...(a)gmail.com> wrote: > ----- Original Message ----- > From: "James Harris" <james.harri...(a)googlemail.com> > Newsgroups: alt.lang.asm,comp.lang.misc,alt.os.development > Sent: Thursday, April 08, 2010 4:51 PM > Subject: Re: status update 1 (Re: assembler speed...) > > > On 8 Apr, 20:13, "Nathan Baker" <nathancba...(a)gmail.com> wrote: > > > ... > > >> That said, I do see a small trend back to a performance-oriented > >> development > >> approach -- due to failure of CPU makers to address the issue. > > > What have the CPU makers not done? > > There was a time when, every few years, the CPU clock speed seemed to be > increasing geometrically... > > 1 MHz > 8 MHz > 25 MHz > 90 MHz > 133 MHz > 500 MHz > > But when they got into the GHz range, the trend stopped. There is no longer > a "user noticable" increase in performance gained by purchasing new > hardware. This places the burden on software. Forgive me but from at least two perspectives that's an extraordinary viewpoint. I thought you might be referring to compilers and other development tools. First, when an industry has progressed geometrically (your term) and *sustained* that improvement for such a long period of time http://en.wikipedia.org/wiki/Wheat_and_chessboard_problem to refer to the "failure of CPU makers to address the issue" says they have somehow failed. I would call what they have accomplished a success. Second, the user-noticeable increase in performance (your term) has lagged way behind hardware improvements. AIUI the problem is software. User interfaces and inefficient code continue to swallow up much of the increases in hardware speeds. So rather than hardware placing the burden on software, the burden is software. On topic for at least one of the crossposted groups (comp.lang.misc) we ought to be able to design a language that can exploit and benefit from the amazing hardware we programmers now have available. We've never had it so good! For example, as mentioned at http://en.wikipedia.org/wiki/Cray-1 one of the early supercomputers * weighed 5 or 6 tons * consumed over 100 kilowatts of power * cost millions * and had a cycle time of 12.5 ns That means it ran at a lowly 80 MHz. I know they don't have vector units etc but even mobile phones clock faster than that now. James
From: Robert Redelmeier on 9 Apr 2010 10:58
In alt.lang.asm Nathan Baker <nathancbaker(a)gmail.com> wrote in part: > There was a time when, every few years, the CPU clock speed > seemed to be increasing geometrically... > > 1 MHz > 8 MHz > 25 MHz > 90 MHz > 133 MHz > 500 MHz > > But when they got into the GHz range, the trend stopped. There is > no longer a "user noticable" increase in performance gained by > purchasing new hardware. This places the burden on software. Even outside of niches (video compression is still CPU-bound), this really is not true. The trend stopped mostly because it didn't pay. CPU time has dwindled to insignificance for common tasks, but other things (video rendering, disk seek, network response) have not. People can see signficant improvements in some tasks with appropriate hardware upgrades like videocards and SSDs. MS-Windows can boot in 10-15s with the latter. As for fixing software, fast CPUs _reduce_ the cost of locally suboptimal code. What matters is high-level optimization. As an example, Firefox can be made to open much quicker if you disable automatic checking for updates and set it to open on a blank page. Perhaps Firefox should delay update checking. This makes a bigger difference than a 2.0 vs 2.5 GHz CPU speed. -- Robert > > |