similar to: weak checksum

This drop-in patch increases the performance of the get_checksum1() function on x86-64. On the target slow CPU performance of the function increased by nearly 50% in the x86-64 default SSE2 mode, and by nearly 100% if the compiler was told to enable SSSE3 support. The increase was over 200% on the fastest CPU tested in SSSE3 mode. Transfer time improvement with large files existing on both ends

I've read up some more on the subject, and it seems the proper way to do this with GCC is g++ and target attributes. I've refactored the patch that way, and it indeed uses SSSE3 automatically on supporting CPUs, regardless of the build host, so this should be ideal both for home builders and distros. Getting the code to build right in c++ mode (checksum_sse2.cpp only) was a bit of an

What do you base this on? Per https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html : "For the x86-32 compiler, you must use -march=cpu-type, -msse or -msse2 switches to enable SSE extensions and make this option effective. For the x86-64 compiler, these extensions are enabled by default." That reads to me like we're fine for SSE2. As stated in my comments, SSSE3 support must be

Hi all, I am writing a xdelta-like application as a personal experiment and am busy implementing the rsync protocol, so far so good. I am using C++ templates and creating the algorithms so that operate on any stream, array, etc. through iterators. All seems well except that I am getting a lot of false hits with the weak checksum. When generating checksums of blocksize 1024 on the RedHat 7.1

Hi, Where can I get good pointers on the rolling checksum algorithm used in rsync? I need an 8-bit or 12-bit rolling checksum too. Any place where "rolling" checksum algorithms are discussed? Seun Osewa ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

On Sat, 29 Jun, at 04:46:00PM, Helmut Hullen wrote: > ld: i386 architecture of input file `zlib/adler32.o' is incompatible with i386:x86-64 output This is a problem with your toolchain - you don't have the necessary multilib support to build 64-bit objects. If you'll notice when building zlib/adler.o for efi64, the -m64 flag is being dropped. -- Matt Fleming, Intel Open Source

On Wed, Mar 11, 2015 at 1:23 PM, Hsiu-Khuern Tang <tangoh at gmail.com> wrote: > On Tue, Mar 10, 2015 at 10:47 PM, Avraham Adler <avraham.adler at gmail.com> wrote: >> On Wed, Mar 11, 2015 at 1:40 AM, Hsiu-Khuern Tang <tangoh at gmail.com> wrote: >>> On Tue, Mar 10, 2015 at 8:54 PM, Avraham Adler <avraham.adler at gmail.com> wrote: >>>>

I think you're missing a point here. Two different checksum algorithms are used in concert, the Adler-based one and the MD5 one. I SSE-optimized the Adler-based one. The Adler-based hash is used to _find_ blocks that might have shifted, while the MD5 hash is a strong cryptographic hash used to _verify_ blocks and files. You wouldn't want to replace the MD5 hash with the Adler-based hash,

would it perhaps make sense to have a "--disable-sse2/3" commandline switch in rsync, too - at least for some timeframe until this is considered "rock solid" ? i dislike having automatic cpu feature switching code in a tool which needs to be reliable for me, this new optimization may have issues - and without such switch it can't be easily workarounded without replacing

I think this is a great patch but, in my view, an even better way to tackle the fundamental problem (the performance limitations) is to use a much faster checksum like xxhash, as has been suggested before: https://lists.samba.org/archive/rsync/2019-October/031975.html Cheers, Filipe On Mon, 18 May 2020 at 17:08, Jorrit Jongma via rsync <rsync at lists.samba.org> wrote: > This drop-in

On Wed, Mar 11, 2015 at 1:40 AM, Hsiu-Khuern Tang <tangoh at gmail.com> wrote: > On Tue, Mar 10, 2015 at 8:54 PM, Avraham Adler <avraham.adler at gmail.com> wrote: >> >> I successfully rebuilt R-devel_2015-03-09 with the most recent version >> of Rtools tonight, building both ICU_531 and this time libcurl (7.39) >> as well (and OpenBLAS, of course). The

On Tue, 2015-06-16 at 15:47 -0400, Ilia Mirkin wrote: > On Tue, Jun 16, 2015 at 3:33 PM, Stephen Adler < > adler at stephenadler.com> wrote: > > Guys, > > > > Is there support for display port 1.2 with the nouveau driver and > > GTX > > 970? > > > > I have a dell 4K monitor and to run it in 4K mode at 60Hz I need to > > configure the

On Tue, Sep 1, 2015 at 10:57 AM, peter dalgaard <pdalgd at gmail.com> wrote: > > On 01 Sep 2015, at 16:21 , Avraham Adler <avraham.adler at gmail.com> wrote: > >> Hello. >> >> There used to be changelog of sorts for R-devel [1] and R-release [2]. >> Neither have been updated since 2015-07-24. Have these moved >> elsewhere, or are they no longer

The following zlib files need patches in order to compile using Compaq C on OpenVMS. These patches should also be needed on a Tru64 or LINUX on ALPHA using Compaq C. These should work on any ANSI compliant compiler. Operating System: OpenVMS ALPHA V7.3 Compiler: Compaq C T6.5 Compiler switches: /WARN=ENABLE=(LEVEL4, QUESTCODE) The module adler32.c is testing the unsigned value len to see if

I don't disagree that MD5 could (or even should) be replaced so it is no longer the bottleneck in several real-world cases (including mine). However this patch is not for MD5 performance, rather for the rolling checksum rsync uses to match blocks on existing files on both ends to reduce transfer size. On Mon, May 18, 2020 at 5:44 PM Filipe Maia via rsync <rsync at lists.samba.org>

On Tue, Jan 31, 2017 at 3:30 PM, peter dalgaard <pdalgd at gmail.com> wrote: > >> On 31 Jan 2017, at 18:56 , Avraham Adler <avraham.adler at gmail.com> wrote: >> >> Hello. >> >> When trying to unpack today's version of R-patched, > > From which source? The files from cran.r-project.org seems OK, both those in src/base-prerelease and those from

On Fri, May 29, 2015 at 1:54 AM Eitan Adler <lists at eitanadler.com> wrote: > On 27 May 2015 at 09:29, Justin Bogner <mail at justinbogner.com> wrote: > > Mehdi Amini <mehdi.amini at apple.com> writes: > >> Hi Manuel, > >> > >> I like Phabricator for code review much much more than emails. Let me > know how > >> I can help (I’m

Hello, the following patches should get multidisk access working. The syntax accepted is the following: (hdx,y)/path/to/file where x is the disk number and start at 0 and the y is the partition number starting at 1. So (hd0,1) is the first partition of the first disk. the other accepted syntax is using MBR's 32 bits disk signature so for example: (mbr:0x12345678,2)/foo/bar would address

On Mon, Nov 13, 2023 at 12:45?PM Avraham Adler <avraham.adler at gmail.com> wrote: > > On Mon, Nov 13, 2023 at 1:13?AM Dirk Eddelbuettel <edd at debian.org> wrote: > > > > > > Avi, > > > > Might be toolchain-dependent, might be options-dependent--it built fine here. > > Easier for you to vary option two so maybe try that? > > > >

On 27 May 2015 at 09:29, Justin Bogner <mail at justinbogner.com> wrote: > Mehdi Amini <mehdi.amini at apple.com> writes: >> Hi Manuel, >> >> I like Phabricator for code review much much more than emails. Let me know how >> I can help (I’m not afraid of PHP). > > Chandler updated the llvm phabricator doc to point at what we're deploying: > >