From: Kjetil Barvik <barvik@broadpark•no>
To: Steven Noonan <steven@uplinklabs•net>
Cc: "Shawn O. Pearce" <spearce@spearce•org>, git@vger•kernel.org
Subject: Re: Why Git is so fast
Date: Fri, 01 May 2009 11:19:04 +0200 [thread overview]
Message-ID: <864ow59o53.fsf@broadpark.no> (raw)
In-Reply-To: <f488382f0904301723i37ef03d9w4e93848e603ed28b@mail.gmail.com>
* Steven Noonan <steven@uplinklabs•net> writes:
| On Thu, Apr 30, 2009 at 2:36 PM, Kjetil Barvik <barvik@broadpark•no> wrote:
|> * "Shawn O. Pearce" <spearce@spearce•org> writes:
|> |> 4) The "static inline void hashcpy(....)" in cache.h could then
|> |> maybe be written like this:
|> |
|> | Its already done as "memcpy(a, b, 20)" which most compilers will
|> | inline and probably reduce to 5 word moves anyway. That's why
|> | hashcpy() itself is inline.
|>
|> But would the compiler be able to trust that the hashcpy() is always
|> called with correct word alignment on variables a and b?
<snipp>
| Well, I just tested this with GCC myself. I used this segment of code:
|
| #include <memory.h>
| void hashcpy(unsigned char *sha_dst, const unsigned char *sha_src)
| {
| memcpy(sha_dst, sha_src, 20);
| }
OK, here is a smal test, which maybe shows at least one difference
between using "unsigned char sha1[20]" and "unsigned long sha1[5]".
Given the following file, memcpy_test.c:
#include <string.h>
extern void hashcpy_uchar(unsigned char *sha_dst, const unsigned char *sha_src);
void hashcpy_uchar(unsigned char *sha_dst, const unsigned char *sha_src)
{
memcpy(sha_dst, sha_src, 20);
}
extern void hashcpy_ulong(unsigned long *sha_dst, const unsigned long *sha_src);
void hashcpy_ulong(unsigned long *sha_dst, const unsigned long *sha_src)
{
memcpy(sha_dst, sha_src, 5);
}
And, compiled with the following:
gcc -O2 -mtune=core2 -march=core2 -S -fomit-frame-pointer memcpy_test.c
It produced the following memcpy_test.s file:
.file "memcpy_test.c"
.text
.p2align 4,,15
.globl hashcpy_ulong
.type hashcpy_ulong, @function
hashcpy_ulong:
movl 8(%esp), %edx
movl 4(%esp), %ecx
movl (%edx), %eax
movl %eax, (%ecx)
movzbl 4(%edx), %eax
movb %al, 4(%ecx)
ret
.size hashcpy_ulong, .-hashcpy_ulong
.p2align 4,,15
.globl hashcpy_uchar
.type hashcpy_uchar, @function
hashcpy_uchar:
movl 8(%esp), %edx
movl 4(%esp), %ecx
movl (%edx), %eax
movl %eax, (%ecx)
movl 4(%edx), %eax
movl %eax, 4(%ecx)
movl 8(%edx), %eax
movl %eax, 8(%ecx)
movl 12(%edx), %eax
movl %eax, 12(%ecx)
movl 16(%edx), %eax
movl %eax, 16(%ecx)
ret
.size hashcpy_uchar, .-hashcpy_uchar
.ident "GCC: (Gentoo 4.3.3-r2 p1.1, pie-10.1.5) 4.3.3"
.section .note.GNU-stack,"",@progbits
So, the "unsigned long" type hashcpy() used 7 instructions, compared
to 13 for the "unsigned char" type hascpy().
Would I guess correct if the hashcpy_ulong() function will also use
less CPU cycles, and then would be faster than hashcpy_uchar()?
-- kjetil
next prev parent reply other threads:[~2009-05-01 9:19 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-27 8:55 Eric Sink's blog - notes on git, dscms and a "whole product" approach Martin Langhoff
2009-04-28 11:24 ` Cross-Platform Version Control (was: Eric Sink's blog - notes on git, dscms and a "whole product" approach) Jakub Narebski
2009-04-28 21:00 ` Robin Rosenberg
2009-04-29 6:55 ` Martin Langhoff
2009-04-29 7:21 ` Jeff King
2009-04-29 20:05 ` Markus Heidelberg
2009-04-29 7:52 ` Cross-Platform Version Control Jakub Narebski
2009-04-29 8:25 ` Martin Langhoff
2009-04-28 18:16 ` Eric Sink's blog - notes on git, dscms and a "whole product" approach Jakub Narebski
2009-04-29 7:54 ` Sitaram Chamarty
2009-04-30 12:17 ` Why Git is so fast (was: Re: Eric Sink's blog - notes on git, dscms and a "whole product" approach) Jakub Narebski
2009-04-30 12:56 ` Michael Witten
2009-04-30 15:28 ` Why Git is so fast Jakub Narebski
2009-04-30 18:52 ` Shawn O. Pearce
2009-04-30 20:36 ` Kjetil Barvik
2009-04-30 20:40 ` Shawn O. Pearce
2009-04-30 21:36 ` Kjetil Barvik
2009-05-01 0:23 ` Steven Noonan
2009-05-01 1:25 ` James Pickens
2009-05-01 9:19 ` Kjetil Barvik [this message]
2009-05-01 9:34 ` Mike Hommey
2009-05-01 9:42 ` Kjetil Barvik
2009-05-01 17:42 ` Tony Finch
2009-05-01 5:24 ` Dmitry Potapov
2009-05-01 9:42 ` Mike Hommey
2009-05-01 10:46 ` Dmitry Potapov
2009-04-30 18:43 ` Why Git is so fast (was: Re: Eric Sink's blog - notes on git, dscms and a "whole product" approach) Shawn O. Pearce
2009-04-30 14:22 ` Jeff King
2009-05-01 18:43 ` Linus Torvalds
2009-05-01 19:08 ` Jeff King
2009-05-01 19:13 ` david
2009-05-01 19:32 ` Nicolas Pitre
2009-05-01 21:17 ` Daniel Barkalow
2009-05-01 21:37 ` Linus Torvalds
2009-05-01 22:11 ` david
2009-04-30 18:56 ` Nicolas Pitre
2009-04-30 19:16 ` Alex Riesen
2009-05-04 8:01 ` Why Git is so fast Andreas Ericsson
2009-04-30 19:33 ` Jakub Narebski
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=864ow59o53.fsf@broadpark.no \
--to=barvik@broadpark$(echo .)no \
--cc=git@vger$(echo .)kernel.org \
--cc=spearce@spearce$(echo .)org \
--cc=steven@uplinklabs$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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