Denys Vlasenko wrote:
I tend to doubt that odd-byte aligned large memcpys are anywhere
near typical. malloc and mmap both return well-aligned buffers
(say, 8 byte aligned). Static and on-stack objects are also
at least word-aligned 99% of the time.
memcpy can just use "relatively simple" code fo
Denys Vlasenko wrote:
3164 line source file which implements memcpy().
You got to be kidding.
How much of L1 icache it blows away in the process?
I bet it performs wonderfully on microbenchmarks though.
I agree that the OpenSolaris memcpy is bigger than necessary. However,
it is necessary t
Gerald Pfeifer wrote:
See how user friendly we in GCC-land are in comparison? ;-)
Since there is no libc mailing list, I thought that the gcc list is the
place to contact the maintainers of libc. Am I on the wrong list? Or are
there no maintainers of libc?
Michael Matz wrote:
You must be doing something wrong. If the compiler decides to inline the
string ops it either knows the size or you told it to do it anyway
(-minline-all-stringops or -minline-stringops-dynamically). In both cases
will it use wider than byte moves when possible.
g++ (v.
nd the default builtin
function is slower than any other implementation I have seen (copies 1
byte at a time!).
Tarjei Knapstad wrote:
>2008/7/26 Agner Fog <[EMAIL PROTECTED]>:
>>I have libc version 2.7. Can't find version 2.8
>It's in Fedora 9, I have no idea why the sourc
Michael Meissner wrote:
On Fri, Jul 25, 2008 at 09:08:42AM +0200, Agner Fog wrote:
Gnu libc could borrow a lot of optimized functions from Opensolaris and
Mac and other open source projects. They look better than Gnu libc, but
there is still room for improvement. For example, Opensolaris
On Thu, 26 Jun 2008 Uros wrote:
>Please also add a runtime test that can be used to analyze the problem.
I am a temporary guest on the gcc mailing list and I haven't seen your
mail before. In case your problem hasn't been solved yet, I can inform
you that I have a disassembler which puts comme
Raksit Ashok wrote:
>There is a more optimized version for 64-bit:
>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s
>I think this looks similar to your implementation, Agner.
Yes it is similar to my code.
Gnu libc could borrow a lot of optimized function
Basile STARYNKEVITCH wrote:
>At last, at the recent (july 2008) GCC summit, someone (sorry I forgot
who, probably someone from SuSE)
> proposed in a BOFS to have architecture and machine specific
hand-tuned (or even hand-written assembly) low
> level libraries for such basic things as memset et
Joseph S. Myers wrote:
>I don't know if it was proposed in this context, but the ARM EABI has
>various __aeabi_mem* functions for calls known to have particular
>alignment and the idea is relevant to other platforms if you provide such
>functions with the compiler. The compiler could also generat
Dennis Clarke wrote:
>The Sun Studio 12 compiler with Solaris 10 on AMD Opteron or
>UltraSparc beats GCC in almost every single test case that I have
>seen.
This is memcpy on Solaris:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/i386/gen/memcpy.s
It uses exactly the sam
Hi, I am doing research on optimization of microprocessors and
compilers. Some of you already know my optimization manuals
(www.agner.org/optimize/).
I have tested many different compilers and compared how well they
optimize C++ code. I have been pleased to observe that gcc has been
improved
12 matches
Mail list logo
