public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Knut Petersen <Knut_Petersen@t-online.de>
To: linux-fbdev-devel@lists.sourceforge.net
Cc: Andrew Morton <akpm@osdl.org>,
	"Antonino A. Daplas" <adaplas@gmail.com>,
	Linux Kernel Development <linux-kernel@vger.kernel.org>,
	Jochen Hein <jochen@jochen.org>
Subject: Re: [Linux-fbdev-devel] [PATCH 1/1 2.6.13] framebuffer: bit_putcs() optimization for 8x* fonts
Date: Tue, 30 Aug 2005 19:58:51 +0200	[thread overview]
Message-ID: <43149E5B.7040006@t-online.de> (raw)
In-Reply-To: <Pine.LNX.4.62.0508301814470.6045@numbat.sonytel.be>


>Probably you can make it even faster by avoiding the multiplication, like
>
>    unsigned int offset = 0;
>    for (i = 0; i < image.height; i++) {
>	dst[offset] = src[i];
>	offset += pitch;
>    }
>

More than two decades ago I learned to avoid mul and imul. Use shifts, 
add and lea instead,
that was the credo those days. The name of the game was CP/M 80/86, a86, 
d86 and ddt ;-)

But let´s get serious again.

Your proposed change of the patch results in a 21 ms performance 
decrease on my system.
Yes, I do know that this is hard to believe. I tested a similar 
variation before, and the results
were even worse.

Avoiding mul is a good idea in assembly language today, but often it is 
better to write a
multiplication  with the loop counter in C and not to introduce an extra 
variable instead. The
compiler will optimize the code and it´s easier for gcc without that 
extra variable.

More interesting would be the question what should be done for idx==2 or 
idx==3. Probably
fb_pad_aligned_buffer() is also slower for those cases. But does anybody 
use such fonts?

cu,
 knut

  reply	other threads:[~2005-08-30 17:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-30 16:15 [PATCH 1/1 2.6.13] framebuffer: bit_putcs() optimization for 8x* fonts Knut Petersen
2005-08-30 16:18 ` [Linux-fbdev-devel] " Geert Uytterhoeven
2005-08-30 17:58   ` Knut Petersen [this message]
2005-08-30 19:13     ` Roman Zippel
2005-08-30 22:26       ` Knut Petersen
2005-08-31  0:51         ` Roman Zippel
2005-08-31  6:42           ` Antonino A. Daplas
2005-08-31 15:49             ` Roman Zippel
2005-08-31 12:46           ` Knut Petersen
2005-08-31 17:15             ` Roman Zippel
2005-08-31 19:19               ` Knut Petersen
2005-08-31 19:34                 ` Roman Zippel
2005-08-31 19:52                   ` Knut Petersen
2005-08-30 19:59     ` Geert Uytterhoeven
2005-08-31  1:14     ` Antonino A. Daplas
2005-08-31  1:14 ` Antonino A. Daplas

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=43149E5B.7040006@t-online.de \
    --to=knut_petersen@t-online.de \
    --cc=adaplas@gmail.com \
    --cc=akpm@osdl.org \
    --cc=jochen@jochen.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox