- faster "CRC"- / "FNV"-hashing - 11 Updates
- Some old allocator code I want t share - 1 Update
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 11 10:42AM > your OoO-CPU, but in most cases the compiler generates better code. > I've seen code from clang where you might think: there would be no > ASM-programmer that knows all of these optimization-tricks. Human always beats compiler, as you can always examine compiler generated code, learn and bit it : Also humans are better in algorithms :P As major optimisation is *always algorithm* :P -- 7-77-777 Evil Sinner! with software, you repeat same experiment, expecting different results... |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 11 01:03PM +0200 Am 11.10.2021 um 12:42 schrieb Branimir Maksimovic: > Human always beats compiler, as you can always examine > compiler generated code, learn and bit it : Humans tend to write Asm that is readable. Compilers generate Asm that's often not readbale for performance reasons. |
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 11 11:12AM >> compiler generated code, learn and bit it : > Humans tend to write Asm that is readable. Compilers generate > Asm that's often not readbale for performance reasons. Readable and compact, not bloated :P Optimize in iterations :P -- 7-77-777 Evil Sinner! with software, you repeat same experiment, expecting different results... |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 11 01:44PM +0200 > Readable and compact, not bloated :P Inlining makes bloat - but is usually more performant. Loop-unrolling of small loops makes bloat - but is usually more performant. > Optimize in iterations :P Hand-written asm is usually slower because there are only a small number of asm-writers that know all the optimizaztion-tricks that compilers have learned for decades. F.e. the code of clang 12 is meanwhile somewhat faster than that of gcc 11. I think in five years absoutely no asm writer can beat a compiler. |
| Bo Persson <bo@bo-persson.se>: Oct 11 01:58PM +0200 On 2021-10-11 at 11:18, Bonita Montero wrote: > your OoO-CPU, but in most cases the compiler generates better code. > I've seen code from clang where you might think: there would be no > ASM-programmer that knows all of these optimization-tricks. In this case the asm code is supplied by Intel. I bet they qualify for "you know everything about your OoO-CPU". :-) |
| David Brown <david.brown@hesbynett.no>: Oct 11 02:23PM +0200 On 11/10/2021 13:58, Bo Persson wrote: >> ASM-programmer that knows all of these optimization-tricks. > In this case the asm code is supplied by Intel. > I bet they qualify for "you know everything about your OoO-CPU". :-) Well, kind of. Intel as a whole probably knows most of what there is to know about Intel processors. But Intel does not write code - people working at (or for) Intel write code, and there is absolutely no guarantee that the person or people who wrote the code know all about all of Intel's processors - never mind non-Intel x86 processors, or non-x86 processors, or any other device. At best, you can probably be quite confident that the code is close to optimal if you run it on the same processor the assembly author used. How well it will run on the dozen other current Intel processor variations is another matter (by "dozen", I am ignoring devices that differ only in clock speed or core count, and ignoring older devices). How well it will run on AMD processors is also another matter. You write these routines in C (or C++), and you tune the optimisation. You compile with "-fmarch=native", or whatever flag your compiler has to get the fastest code for your particular processor. You use compiler features for multi-versioning for target-specific optimisations, so that the compiler generates versions for different SIMD and other instruction set extensions, and picks the best version for the real cpu when the code starts up. You use inline assembly or intrinsics for specific target versions if you are /sure/ your assembly works faster, and have measured it. General use of assembly language is something that comes /way/ down on the list when you are trying to get fast implementation of code. |
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 11 12:56PM > measured it. > General use of assembly language is something that comes /way/ down on > the list when you are trying to get fast implementation of code. Compiler at best can produce generic optimistic code that does not stand a chance against dedicated human :P ONly reason we do not program in assembler is because lerning curve is steep :P -- 7-77-777 Evil Sinner! with software, you repeat same experiment, expecting different results... |
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 11 03:55PM +0200 Am 11.10.2021 um 14:56 schrieb Branimir Maksimovic: > Compiler at best can produce generic optimistic code that does not stand > a chance against dedicated human :P It was easy to beat a compiler before 10 years, but today not anymore. And in five years it will be almost impossible. |
| David Brown <david.brown@hesbynett.no>: Oct 11 05:19PM +0200 On 11/10/2021 14:56, Branimir Maksimovic wrote: > a chance against dedicated human :P > ONly reason we do not program in assembler is because lerning curve is > steep :P I'm going to assume the ":P" smiley means you are being sarcastic. |
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 11 04:55PM >> a chance against dedicated human :P > It was easy to beat a compiler before 10 years, but today not anymore. > And in five years it will be almost impossible. Look, humans write compilers, start at that :P -- 7-77-777 Evil Sinner! with software, you repeat same experiment, expecting different results... |
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 11 04:57PM >> ONly reason we do not program in assembler is because lerning curve is >> steep :P > I'm going to assume the ":P" smiley means you are being sarcastic. Well, problem with assembler is that brain overheat :P When I write something bigger in it, my brain overheats in order to undertsand what I wrote before :P -- 7-77-777 Evil Sinner! with software, you repeat same experiment, expecting different results... |
| Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 11 10:46AM //============================================================================= // // Copyright : (c) 2004 by Dzenis Softic / http://www.dzeni.com // // Filename : // // Description: // // Company : Seenetix D.O.O. // // Authors : // // $Id$ // //============================================================================= #ifndef VMP_BUFFERED_MEM_MANAGER_H #define VMP_BUFFERED_MEM_MANAGER_H #include <map> #include <list> #include <vector> #include <utility> #include <stdio.h> #include <pthread.h> #include <cstdlib> #include <new> #include <stdlib.h> #include "vmpthreads.h" /* use new allocator */ #define MALLOCATOR #if !defined(MALLOCATOR) #include "vmp_malloc_allocator.h" #else #include "vmp_mallocator.h" 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment