Re: Apple IIGS ROM 1 or ROM 3, which is better?

Polymorph wrote:
On Jul 12, 6:42 am, pau...@xxxxxxx (Paul Schlyter) wrote:

In article <OYSdnXwEJbZQuQjbnZ2dnUVZ_v6tn...@xxxxxxxxxxx>,
Michael J. Mahon <mjma...@xxxxxxx> wrote:




mdj wrote:

On Jul 2, 11:23 am, "Michael J. Mahon" <mjma...@xxxxxxx> wrote:

With object orientation comes a surplus of indirection. ;-)

At least you stopped short of saying that's a bad thing ;-)

From the point of view of speed, *avoidable* indirection is a
*very* bad thing. Memory latency is hundreds of processor
cycles, at least.

With good data organization, reasonable cache design, and a
compiler that can prefetch object instances before use, much
of the *simple* indirection cost can be amortized, but compiler
designers tend to be relatively ignorant of what machines must
actually *do* to execute their code. ;-(

-michael

Actually, that's good news, not bad news - it means it's still worthwhile
to program in assembly language!!!!! ;-)

--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/


Although I agree with you regarding a pure speed comparison, please do
not write off OO.

Not only do I not write it off, I was using what is now called OO
programming techniques in the 1960s, when it was one of several
way of modularizing code.

But I do think that programming, since it is still much more art
than science, is beset by fashions. No single methodology is the
best for everything, and every methodology has a terrible dark side.

All I can say to someone wishing to write a large enterprise scale
multi-threaded application in assembly is - "Good luck! See you in 20
years...." ;-)

And if the original developer left the code for someone else to
maintain and enhance, I'd say "OK! time for a re-write...."

I understand that today, OO is the most widespread method of making
code with firm interfaces allowing isolation and factorization. But
there are other methods, too.

The OO paradigm was conceived to separate and control the interactions
(interfaces) between distinct entities of a program rather than for
speed. It also allows for the re-use of tried and tested objects.
These ideas are invaluable when you are dealing with large complex
applications. With modern processors and more mature compilers, the
percentage of processing power lost to the overheads of the OO
methodology is sufficiently small to be acceptable. Especially when
you consider the time spent developing and maintaining such an
application.

What is acceptable is relative to the demands of your application.

If the application is non-critical, or relatively undemanding of
performance, then inefficient implementations are effective. If,
on the other hand, current processors are marginally capable of
meeting the performance requirement, then giving up a factor of
ten in efficiency for the ability to write a high-level "shell"
calling on a hundred times as much general-purpose "library" code,
is not a good tradeoff.

In such cases, writing much closer to the silicon is called for,
and can deliver factors of ten to one hundred in problem solution
speed. If the problem has a real-time component, that can easily
make the difference between feasibility and infeasibility.

On the other hand, if the problem is readily decomposed into
relatively independent pieces, then a "SETI@home"-style solution
may be just the thing--and then the efficiency of any particular
piece is much less critical.

One of the ways that OO is actually helping get the benefit of
hardware performance strategies is by localizing performance-
critical behaviors in a few libraries (such as graphics libraries)
that can be replaced with versions closely adapted to accelerating
hardware, so that most of the application need not adapt to new
approaches to accelerate the algorithms.

No modularization strategy allows code to be leveraged longer than
the lifetime of its interfaces, which makes interface design one of
the most demanding design activities. Unfortunately, this us usually
realized about an interface after numerous short-lived tradeoffs have
been set in stone.

-michael

NadaNet file server for Apple II computers!
Home page: http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."
.

Relevant Pages

  • Re: Apple IIGS ROM 1 or ROM 3, which is better?
    ... and every methodology has a terrible dark side. ... code with firm interfaces allowing isolation and factorization. ... any new programmers on how your methodology works. ... This is where a good initial design becomes ...
    (comp.sys.apple2)
  • Re: Apple IIGS ROM 1 or ROM 3, which is better?
    ... and every methodology has a terrible dark side. ... code with firm interfaces allowing isolation and factorization. ... any new programmers on how your methodology works. ... This is where a good initial design becomes ...
    (comp.sys.apple2)
  • Re: Grundsatzfrage zum Klassen-Design
    ... Dass, wenn sich Tabellen ändern, sowohl Du als auch ich in den Code ... Sicherlich haben Interfaces ihren Zweck. ... den Compiler zum Generieren von Fehlermeldungen zu bewegen. ... weil mich SPs nun endgültig auf eine DBE festnageln. ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: OT: Binary Search - Should They Know It?
    ... Considering you are having problems it would be advisable to design the app ... that the classes inside the DLL are unlikely to change but are reused ... Interfaces - This holds the interfaces for the data objects in the ... Our calculation engine is a monster. ...
    (microsoft.public.dotnet.languages.csharp)
  • Interface standards (was Re: Dual Port RAM)
    ... instead of hiding complex functions behind simple interfaces, ... "TTL 7400" design mentality. ... Of course, vendors' in-house synthesis tools ... do anything similar on the IP core side. ...
    (comp.arch.fpga)