Steve
Guest
|
 Posted:
Sun Jul 17, 2005 12:15 am Post subject:
Re: How does this make you feel? |
|
|
Jason Ozolins wrote:
| Quote: | prep@prep.synonet.com 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.
|
This is all rather obvious, and indeed natural, as the hierarchy of
programming that comprises a functioning computer system that supports
applications suitable and usable to non-specialist users: i.e. word
processing apps and the like. However there may be some confusion of
nomenclature here as some people will conflate the use of words like
bug and feature since they are sometimes synonymous. "One man's bug is
another man's feature" type thing.
| Quote: | 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?
|
Of course, it is difficult to see how the pentium FOOF or FDIV bugs
could be percieved by anyone as features, save in the pathalogical case
where their behavior is a side effect of some other cause. I recall
reading about an instance where someone modified the CPU of a PDP to
add some useful feature and unintentionally caused working code to
malfunction in some bizarre way. I don't recall how the issue was
resolved, but that is not important. The issue here from my
perspective is that, sure, it is necessary to be extremely careful when
modifying existing systems so as to retain existing functionality.
However, it does not seem reasonable to be too conservative in design
simply to avoid the risk that something _might_ break in the field if
regression testing cannot cover all the cases during a shakedown
period.
| Quote: | 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?
|
We can restate your two sections to make your approach clearer:
Bugs or features visible to end users: big impact.
Bugs or features that make life easier for application programmers:
some impact.
Bugs or features that are only noticed by OS programmers: who cares?
| Quote: | Just treat a bug as a "negative feature" and the relation holds.
|
That is an interesting identity, but it is not necessarily valid.
(True) features are capabilities that are usually designed into a
system. Actual bugs are generally side-effects of inadequate design or
implementation. They are not entities that are diametrically opposed
like "good" and "evil", much as many of us are conditioned or
predisposed to think that way. The intention behind a feature, such as
what I was proposing earlier, is to improve the quality of an arbitrary
system.
| Quote: | 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.
|
You are correct with your example as it is written. However, the world
is not standing still. What happens when CPU clocking hits the wall,
and on-chip optimisation of instruction execution yields only linear
improvements in performance? Memory latencies are likely to improve
until they, too, hit a wall (speed of light signal propogation limits,
etc.) In this scenario, the ratio between instruction execution speed
and memory access frequencies is bound to settle into a different
stable state than the one that exists today. And even further out in
the left-field of speculation, we have optical gates, qbits, and
so-called quantum computing technologies on the horizon whose impact on
architecture is at present a matter of rank speculation.
| Quote: | 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.
|
Maybe. While I recognise the role to be played by commercial and
markeet valuation of technologies, I believe that should not be the
only consideration. There is the conception of a `social good' in our
society which is manifested in various ways. To the extent that
architecture dictates software design, there is a question as to what
architecture, or architecture features, lends itself to the creation of
the most useful tools, and hence contributes to the construction of the
most useful and functional applications. There are two basic
directions that this can go, and I happen to favour the one that is
more CISC than RISC.
The RISC direction looks to have been explored fairly thouroughly. As
to memory latencies, RISC seems to place the largest demand on the
memory bus in terms of feeding instructions to the CPU, and while a lot
of the busiest code will tend to fit in cache, there are still memory
latency issues with off-CPU access. At the extreme side of RISC, I
recall reading an article called "An introduction to array logic" (H.
Fleisher and L. I. Maissel, IBM J. Res., March, 1975 [v.20]) which
describes a system of logic programming that "can, in principle, be
changed at the same rate at which memory can be written". If this
method were adapted to CPU design, we would have a very RISC CPU that
was used essentially programmed by in-memory microcode. The recent and
now long-standing frequency differential between the CPU clocks and
memory bus speeds meant that it was not economically feasible to build
CPUs and write code generators for this kind of architecture.
I am approaching this problem from a different angle, and perhaps some
of this will help a couple of people who have stated that they do not
really understand what I propose. Instructions that can do more per
instruction cycle, which in this case means ranged memory operations,
in a parallel HW thread architecture, reduce cache memory footprints,
may exploit the memory bus more fully than existing designs, and add
features that may be exploited by compiler optimisers to improve code
efficiency.
And of course, as I have said, more flexible paging may (or should) be
a natual follow-on to complement a different kind of register that
would be needed to represent addressing modes that specify
quasi-arbitrary spans of memory.
| Quote: | 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. :-/
|
You say that 'end users' don't care about the architecture so long as
it 'gets the job done' but as you know, to some degree the design of
the architecture dictates how applications will perform and how they
are written. However, this topic branches off into the psychology of
design and innovation, and I am not yet prepared to write at length on
the issue. It must suffice to say that at least as far as programmers
are concerned, the tools they use to construct applications contain a
great many implicit assumptions that are specified by the structure of
the systems they are using. I am not quite convinced that the shape of
existing systems meets all the present and future needs of programmers.
And it must be remembered that existing tool chains represent a body
of work that will be harder to change the longer that an existing ISA
persists in shaping them. So, what is considered a bug or a feature at
this level is a matter of conviction or allegiance to a particular
design philosophy.
Whether or not complex registers are the Right Thing To Do is almost
immaterial at this level of abstraction. Part of the intent of my
discussion of this issue at all is to gauge prevalent opinions on the
shape of existing CPU design, at least in the mid to low-end of the
market. I have an opinion about the kind of system that I would like
to write software for, and you are getting it. :) As for the high-end
of things in the world of supercomputers, I simply have no way to have
an informed opinion. Hopefully my demonstration of ignorance is not
too amusing to those who work on those systems.
I will attempt to make a more detailed case for my approach later on as
time permits.
| Quote: | 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.
|
With the potential for demonstrable and real gains, and conditional on
backwards compatibility, it is not unreasonable to expect that ISA
upgrades might also impact conventional systems. But the point is well
taken. Niche makets present the best entry point for experimental
designs in an industry largely dominated by traditional designs and
practises.
Regards,
Steve |
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in