From: Sergey Kaplun via Tarantool-patches <tarantool-patches@dev.tarantool.org> To: Maxim Kokryashkin <max.kokryashkin@gmail.com> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH luajit v2 1/3] utils: add CRC32 hash implementation Date: Mon, 30 Aug 2021 17:08:20 +0300 [thread overview] Message-ID: <YSzmVF7LUI+NJibe@root> (raw) In-Reply-To: <5f67b8ba222f1071ee3f989353a14361c7fb1676.1629457244.git.m.kokryashkin@tarantool.org> Hi, Maxim! Thanks for the fixes! Please, consider my comments below. On 20.08.21, Maxim Kokryashkin wrote: > This commit adds an implementation of the CRC32 hash. The > implementation is taken from GNU libberty so it differs from the > classic CRC32 implementation. The values are not reflected, and there > is no final XOR value. These differences make it easy to compose the > values of multiple blocks. > > That hash implementation will be used in the memprof's symtab later on. > > Part of tarantool/tarantool#5813 > --- > On 28.07.21 Sergey Kaplun wrote: > > <snipped> > > > IINM we should compare this approach with a full dump of all .so > > functions. May you provide some benches of your approach against the > > aforementioned? > As for benchmarks, I'll provide them later in the separate letter. Yep, seen it here[1]. Do you check the reason of such huge difference (more than x200!!!)? I suspect the hash calculation from the whole library, but don't check it. Also, I didn't get the following: Are these measurements done for LuaJIT or for Tarantool. Tarantool has more libraries, so it would be nice to see benchmark for it too. Also, as far as this way is such heavy, do we need this patch? > > <snipped> > > >> +#define _GNU_SOURCE > > Locally, I need to define not _GNU_SOURCE, but __USE_GNU. May you please > > check what exactly define is required and why? > Defining __USE_GNU by yourself is a terrible practice as it is an > internal definition of the glibc. Consodering this, you should stick > to _GNU_SOURCE OK, thanks for clarification! > > <snipped> > > src/CMakeLists.txt | 1 + > src/Makefile.dep.original | 3 +- > src/Makefile.original | 2 +- > src/lj_utils.h | 29 ++++++++++ > src/lj_utils_hash.c | 110 ++++++++++++++++++++++++++++++++++++++ Nit: may be lj_utils_crc32.c is better here (at least we know the hash type). Feel free to ignore. > src/ljamalg.c | 1 + > 6 files changed, 144 insertions(+), 2 deletions(-) > create mode 100644 src/lj_utils_hash.c > > diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt > index 809aac68..74c7a205 100644 > --- a/src/CMakeLists.txt > +++ b/src/CMakeLists.txt <snipped> > diff --git a/src/Makefile.dep.original b/src/Makefile.dep.original > index f3672413..3dc6e9b4 100644 > --- a/src/Makefile.dep.original > +++ b/src/Makefile.dep.original > @@ -208,6 +208,7 @@ lj_trace.o: lj_trace.c lj_obj.h lua.h luaconf.h lj_def.h lj_arch.h \ > lj_vm.h lj_vmevent.h lj_target.h lj_target_*.h > lj_udata.o: lj_udata.c lj_obj.h lua.h luaconf.h lj_def.h lj_arch.h \ > lj_gc.h lj_udata.h > +lj_utils_hash.o: lj_utils_hash.c lj_utils.h Dependencies are defined as the following: 1) The file itself. 2) Each header and all included LuaJIT headers in it. For example: lj_utils_leb128.o depends on the .c file itself. It includes <lj_utils.h>, so add it in dependencies too. <lj_utils.h> includes inside <lj_def.h>. <lj_def.h> includes <lua.h>, which includes <luaconf.h>. > lj_utils_leb128.o: lj_utils_leb128.c lj_utils.h lj_def.h lua.h luaconf.h > lj_vmevent.o: lj_vmevent.c lj_obj.h lua.h luaconf.h lj_def.h lj_arch.h \ > lj_str.h lj_tab.h lj_state.h lj_dispatch.h lj_bc.h lj_jit.h lj_ir.h \ > @@ -234,7 +235,7 @@ ljamalg.o: ljamalg.c lua.h luaconf.h lauxlib.h lj_gc.c lj_obj.h lj_def.h \ Also, I see tons of errors like the following: | /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: libluajit.a(ljamalg.o): in function `lj_err_throw': | ljamalg.c:(.text+0xaf50): multiple definition of `lj_err_throw'; libluajit.a(lj_err.o):lj_err.c:(.text+0x270): first defined here This problem is known, IINM. How do you check this patch? If you have unrelated patch, which fixes the mentioned build type, please send it to the mailing list. <snipped> > diff --git a/src/Makefile.original b/src/Makefile.original > index 031f0778..2a57c022 100644 > --- a/src/Makefile.original > +++ b/src/Makefile.original <snipped> > diff --git a/src/lj_utils.h b/src/lj_utils.h > index f5c15797..fe179753 100644 > --- a/src/lj_utils.h > +++ b/src/lj_utils.h <snipped> > diff --git a/src/lj_utils_hash.c b/src/lj_utils_hash.c > new file mode 100644 > index 00000000..8a7f0869 > --- /dev/null > +++ b/src/lj_utils_hash.c > @@ -0,0 +1,110 @@ > +/* <snipped> > +*/ > + > +#define lj_utils_hash Typo: s/lj_utils_hash/lj_utils_hash_c/ Minor: Please, add LUA_CORE define for consistency with other c modules. > + > +#include <stdio.h> Typo: Looks like the extra one. :) > +#include <assert.h> This is excess, see the comment near usage below. > + > +#include "lj_utils.h" > + > +static const uint32_t crc32_table[] = > +{ <snipped> > +}; > + > +uint32_t lj_utils_crc32 (const char *buf, size_t len, uint32_t init) > +{ > + assert(buf != NULL); Please, use `lua_assert()` instead -- it is common practise for all LuaJIT code. > + > + uint32_t crc = init; When build like the following (the `CCWARN` comment line in the <src/Makefile.original>): | cmake -DCMAKE_C_FLAGS="-Wextra -Wdeclaration-after-statement \ | -Wredundant-decls -Wshadow -Wpointer-arith" -DCMAKE_BUILD_TYPE=Debug \ | -DLUA_USE_ASSERT=ON -DLUA_USE_APICHECK=ON . && make -j I get the following compile warnings: | /home/burii/reviews/luajit/csymbols/src/lj_utils_hash.c: In function 'lj_utils_crc32': | /home/burii/reviews/luajit/csymbols/src/lj_utils_hash.c:104:3: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] | 104 | uint32_t crc = init; > + while (len--) { > + crc = (crc << 8) ^ crc32_table[((crc >> 24) ^ *buf) & 255]; > + buf++; > + } > + return crc; > +} > diff --git a/src/ljamalg.c b/src/ljamalg.c > index 3f7e6860..3a667a68 100644 > --- a/src/ljamalg.c > +++ b/src/ljamalg.c <snipped> > -- > 2.32.0 > [1]: https://lists.tarantool.org/pipermail/tarantool-patches/2021-August/025707.html -- Best regards, Sergey Kaplun
next prev parent reply other threads:[~2021-08-30 14:09 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-20 11:10 [Tarantool-patches] [PATCH luajit v2 0/3] memprof: add demangling capabilities for C functions Maxim Kokryashkin via Tarantool-patches 2021-08-20 11:10 ` [Tarantool-patches] [PATCH luajit v2 1/3] utils: add CRC32 hash implementation Maxim Kokryashkin via Tarantool-patches 2021-08-30 14:08 ` Sergey Kaplun via Tarantool-patches [this message] 2021-08-20 11:10 ` [Tarantool-patches] [PATCH luajit v2 2/3] memprof: extend symtab with information about .so libs Maxim Kokryashkin via Tarantool-patches 2021-08-30 14:10 ` Sergey Kaplun via Tarantool-patches 2021-08-20 11:10 ` [Tarantool-patches] [PATCH luajit v2 3/3] memprof: update memprof parser Maxim Kokryashkin via Tarantool-patches 2021-08-25 10:01 ` [Tarantool-patches] [PATCH luajit v2 0/3] memprof: add demangling capabilities for C functions Максим Корякшин via Tarantool-patches
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=YSzmVF7LUI+NJibe@root \ --to=tarantool-patches@dev.tarantool.org \ --cc=max.kokryashkin@gmail.com \ --cc=skaplun@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH luajit v2 1/3] utils: add CRC32 hash implementation' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox