Re: How does this make you feel?
- From: Jason Ozolins <jason_abroad@xxxxxxxxxxxx>
- Date: Tue, 12 Jul 2005 11:27:16 +1000
prep@xxxxxxxxxxxxxxxx wrote:
Jason Ozolins wrote:
[listing system programmers, app programmers, end users]
This is listed in *increasing* order of importance - think of the relative numbers in each group. NOTE WELL: the end user doesn't care in the least about computer architecture aesthetics. They either want a faster computer, a cheaper computer, or some amazingly useful new feature.
No it is in inverse order, because problems at lower levels flow up to bite the end user EVEN IF HE DOES NOT KNOW OR CARE. Pentium FP anyone...
That's actually not a counterexample: The FDIV bug was nasty because there was no easy way to isolate its effects from app programmers and end users. The only ways to completely work around it would have been super-ugly, like dynamically translating FP code to insert checks/fixups around FDIVs, or disabling the FPU and interpreting each FP opcode in a trap handler.
Consider the "F00F" bug that crashes old Pentiums. There is a workaround for it that can be done purely at the OS level. In fact, many of the errata listed by Intel for their processors are handled by the folks writing the OS, and you don't get to know about them. In those cases, a quite nasty bug for the OS implementors is of no concern to the end user.
So:
Bugs that are visible all the way up to the end user: big impact.
Bugs that can be handled by apps programmers: some impact
Bugs that can be handled by system programmers without appreciable overhead: who cares?
This fits with what I was asserting:
Features visible to end users (increased speed, new capabilities, better reliability): big impact
Features that make life easier for apps programmers: some impact
Features that only get noticed if you're an OS programmer: who cares?
Just treat a bug as a "negative feature" and the relation holds.
Say you propose a new mechanism for handling page faults on some processor. Let's say with this new mechanism the average code path through the fault handler is reduced by 50%, but the fault handler execution time only drops by 1% because the big limiter is memory latency. This new feature might be appreciated by system programmers writing a new OS, because their fault handling code gets simpler, but will be pretty much invisible to the end user. A feature that is only appreciated by systems programmers is of limited commercial value.
By contrast, take the Altivec SIMD extensions for the PowerPC. Introducing this feature makes *more work* for apps programmers - they have to write new code to take advantage of the new instructions - but assuming that Altivec doesn't slow down the rest of the processor, this is offset by the happiness of users who get better media player performance or quicker response from Photoshop, etc, and who pay money to get hold of that new feature (as well as software upgrades). That feature is of much greater commercial value than the better page fault handler feature.
My point to Steve in my posting was that to sell anyone on a new ISA, you need to nail down enough specifics about the implementation to make some predictions about who (if anyone) will actually see a reason to use a processor based on that ISA. In doing so, the opinions of OS implementors and apps programmers are usually heavily outweighed by the end users, who want something like a smaller/faster/lighter gadget, or a faster word processor/games box/web browser, and couldn't care less whether the processor is elegantly powerful or a dog's breakfast that gets the job done. Some of them (not so much the open source crowd) would also like all the binary-only software that was installed on their last computer to work on their new computer too. :-/
John Mashey has made the point that one of the few places a new ISA could get traction these days is in embedded devices. Even there, aesthetics aren't what matters, it's engineering: lower power implementations, reduced time to market, lower manufacturing cost are all ways to sell a new processor architecture. So Steve would still need to come up with a pragmatic justification for his new ISA.
-Jason =:^) .
- Follow-Ups:
- Re: How does this make you feel?
- From: Steve
- Re: How does this make you feel?
- From: Terje Mathisen
- Re: How does this make you feel?
- References:
- Re: How does this make you feel?
- From: Edward A. Feustel
- Re: How does this make you feel?
- From: Steve
- Re: How does this make you feel?
- From: Eric P.
- Re: How does this make you feel?
- From: John Mashey
- Re: How does this make you feel?
- From: Steve
- Re: How does this make you feel?
- From: John Mashey
- Re: How does this make you feel?
- From: Jan Vorbrüggen
- Re: How does this make you feel?
- From: Steve
- Re: How does this make you feel?
- From: Jason Ozolins
- Re: How does this make you feel?
- From: Steve
- Re: How does this make you feel?
- From: prep
- Re: How does this make you feel?
- Prev by Date: Re: CPU utilization quandry
- Next by Date: Where do the gains of OOO architecture actually take effect?
- Previous by thread: Re: How does this make you feel?
- Next by thread: Re: How does this make you feel?
- Index(es):
Relevant Pages
|