On Oct 16, 2017, at 3:05 AM, Graham Bloice <graham.blo...@trihedral.com> wrote:
> On 13 October 2017 at 21:50, Gerald Combs <ger...@wireshark.org> wrote:
>
>> Before we migrated away from NMake, epan/Makefile.nmake built the assembly
>> versions of various routines for x86 (but not x64) defined in
>> epan/asm_utils_win32_x86.asm. Should we resurrect it in epan/CMakeLists.txt
>> or get rid of it along with the NASM download in tools/win-setup.ps1?
>
> I was vaguely under the impression that compiler intrinsics were the way
> forward for these kind of things
Compiler intrinsics are the way to do things for which there are compiler
intrinsics. Unless by "compiler intrinsics" you're referring to "inline asms"
of the sort that GCC provides, I'm not sure there are compiler intrinsics for
most of the operations for which we're providing assembler-language
implementations. (The one exception is strcmp() and the like, which GCC, and
possibly other compilers, often turn into inline code, and for which there are
often optimized implementations, at least on some platforms, because it's part
of C.)
> However, I don't see much point in attempting to optimise things without
> measuring what we're trying to optimise, i.e. we need some form of benchmark.
Tomas did some profiling back in
https://www.wireshark.org/lists/wireshark-dev/200711/msg00303.html
and in
https://www.wireshark.org/lists/wireshark-dev/200711/msg00068.html
said
I was able (with about 80 lines in assembler) to reduce time spent in
libwireshark.dll during startup from cca 2600ms to 1300ms on my PC.
so that removed about 1.3 seconds of startup time.
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
