All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Malek <dan@mvista.com>
To: Holger Bettag <hobold@Informatik.Uni-Bremen.DE>
Cc: linuxppc-dev@lists.linuxppc.org
Subject: Re: recent fixes in devel tree
Date: Mon, 18 Sep 2000 23:06:20 -0400	[thread overview]
Message-ID: <39C6D82C.38A7D9D1@mvista.com> (raw)
In-Reply-To: 8xk8cb57p2.fsf@s63.informatik.uni-bremen.de


Holger Bettag wrote:

> I know too little about the kernel to suggest specific tunings.

Suggestions always make people think......

> .... I
> thought along the lines you mention, inserting a 'data stream touch'
> here and there for improved bus utilization, occasional use of AltiVec
> code where it tends to speed things up a lot,

The data stream touch is maybe useful in some very specific places.
I have written user level performance tests to see where it is
beneficial, and you have to be careful.  Yes, it can speed things
up when all of the bits line up just right, but you can also screw up
with it as well :-).  Oh, I use it, but it isn't a quick and generic
solution.

> I mainly wanted to know wether there are efforts underway...
> .... or wether it will be only for wizards at
> the bleeding edge.

Oh, there are a few.  Bleeding edge is a good description, but
wizard is more like 'wizzing' (perhaps into the wind :-) in some
cases....

I'm working on several user applications (audio, video, MPEG, etc)
that utilize Altivec, so I'm getting a pretty good idea how to tune
data streams and caches.  Some of this will probably find it's way
into the C library (and has already in some of the MPEG libraries)
for performance enhancement.  The challenge in the kernel is making
the Altivec context available for the kernel.  The Altivec is faster,
but it comes at a higher set-up cost that you also have to consider.
We'll get some in there.  It is definitely hardware that will get
utilized more and more.


	-- Dan

--

	I like MMUs because I don't have a real life.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2000-09-19  3:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-16  5:04 recent fixes in devel tree Paul Mackerras
2000-09-16 11:16 ` Holger Bettag
2000-09-16 14:25   ` Dan Malek
2000-09-17 16:01     ` Holger Bettag
2000-09-19  3:06       ` Dan Malek [this message]
     [not found] <20000916152035.A517@olis.north.de>
2000-09-16 18:05 ` Benjamin Herrenschmidt
2000-09-16 21:51   ` Claus Enneper

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=39C6D82C.38A7D9D1@mvista.com \
    --to=dan@mvista.com \
    --cc=hobold@Informatik.Uni-Bremen.DE \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.