9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "rob pike" <rob@plan9.bell-labs.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] third edition, installation experiences
Date: Sat, 10 Jun 2000 14:22:10 -0400	[thread overview]
Message-ID: <200006101822.OAA27083@cse.psu.edu> (raw)

	/dev/draw seems slower than /dev/bitblt.  I wonder if the difference is
	from not doing runtime code generation.

Perhaps.  Draw() is also a much more general operator, which causes it to be
slower in the worst case.  On the other hand, we (well, Russ) worked on getting
draw() to talk to the graphics accelerator on some of the cards, and there are
simple examples like catting /dev/words where the new system is *much*
faster (factors of 10 or more) than even bitblt was.  I hope folks will
connect the code to the hardware on more graphics cards so the speedups
will be more widely available.

On the issue of run-time code generation, we abandoned it because it was
too hard to write portable code to handle the synchronization of instruction
and data caches.  The problem is not processors so much as systems; the
details of cache management in different architectures are often delegated
to motherboard makers who choose widely varying ways to handle cache
flushing and make it very hard for a portable program to divine what to do.
If you're just on PCs, it's not so hard, but we use a lot of non-PC machines.
Also, it's possible that the rise of JITs will help this situation, but if the
VGA industry is anything to go by...

	Plumbing is... interesting.  I normally like to have several editors
	running, keeping different work in different contexts.  The new system
	makes that difficult, because when one editor opens a file, the
	others want to open it too.

There was a long discussion about how and whether to handle fan-out in
the plumber.  What we did reflects our style of use.  If it doesn't suit your
needs, you have the source...  Also of course it's mostly controlled by
configuration files, so you might be able to try another arrangement just
by using different plumbing rules.  (The fan-out isn't explicit in the
configuration, but I suppose on reflection it could be made to be.) I've
also done tricks where I've rebound things to rearrange plumbing ports
for temporary purposes; that might work well for you.

Failing that, B is a shell script that could easily be adapted to use other
information to direct the file to a port other than edit, or to add
attributes that different editors could check.

-rob



             reply	other threads:[~2000-06-10 18:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-10 18:22 rob pike [this message]
     [not found] <200006081831.OAA25336@smtp1.fas.harvard.edu>
     [not found] ` <20000608191813.8754.qmail@g.bio.cse.psu.edu>
2000-06-09  8:27   ` Fco. J. Ballesteros
2000-06-12 15:49     ` Lyndon Nerenberg
2000-06-15  9:09       ` Fco. J. Ballesteros
2000-06-15 16:58         ` Lyndon Nerenberg
2000-06-12  9:59   ` kajri jain
  -- strict thread matches above, loose matches on Subject: below --
2000-06-10 19:25 jmk
2000-06-11 19:12 ` Scott Schwartz
2000-06-12 10:27 ` Douglas A. Gwyn
2000-06-10 18:56 presotto
     [not found] <rsc@plan9.bell-labs.com>
2000-06-10 18:18 ` Russ Cox
2000-06-11 19:09   ` Scott Schwartz
2000-06-10 17:54 Scott Schwartz
2000-06-09 15:58 jmk
2000-06-08 19:18 Scott

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200006101822.OAA27083@cse.psu.edu \
    --to=rob@plan9.bell-labs.com \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).