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
next prev parent 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