Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: A defer mechanism for C Date: Thu, 24 Dec 2020 16:26:58 -0800 Organization: A noiseless patient Spider Lines: 82 Message-ID: <86ft3uybl9.fsf@linuxsc.com> References: <3a965b75-7eb6-4287-8e19-8969b6628d90n@googlegroups.com> <87h7ol3fd5.fsf@bsb.me.uk> <87czz81b4q.fsf@bsb.me.uk> <6aa2bacc-6885-4052-aeb2-ed4fb0c8ac94n@googlegroups.com> <0b136e48-e0e7-45f4-a6de-8a5406cefff2n@googlegroups.com> <81f236a7-76cc-499d-91c1-aff76ea471c2n@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="7eee579de7650cbf34b1a25e645eaa42"; logging-data="2451"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18UsrHVnRfnakApORQHoZLUQe/ySPyTJ8w=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:lVEReI+DO4POZxd1f/iLe9GE0u0= sha1:/Qpc53DqvEZWchoM77iswtVJIYs= Xref: csiph.com comp.lang.c:157717 Bart writes: > On 20/12/2020 12:59, David Brown wrote: > >> On 19/12/2020 20:57, Bart wrote: >> >>> If I run the binary trees benchmark: >>> >>> https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html >>> >>> >>> then a version using normal malloc/free, compiled with gcc-O3, runs at >>> half the speed of my version using my own allocator. >>> >>> I don't know what malloc version gcc on Windows happens to use, but for >>> this purpose, mine is faster. >>> >>> (Mine is a small-object allocator implemented on top of larger memory >>> blocks obtained with any other allocator including malloc. It doesn't >>> need to store the block size, which helps.) >> >> As seems to be the case so regularly, you don't know what you are doing >> when compiling and linking (you are often even unsure what your own >> home-made tools are doing), and yet you feel qualified to give opinions. >> >> There are many different ways to handle memory allocation, with >> different pros and cons, strengths and weaknesses. There are many >> different gcc builds for Windows, and many different C libraries that >> can be used with them. >> >> So all you actually know from your benchmarking is that some things are >> faster than others. Marvellous. > > That's usually the point of benchmarking... > > > Here are the figures (best using optimisation where available): > > Using regular malloc/free: > > Pelles C 2.0 seconds all on Windows > lccwin 2.2 > DMC 2.2 > gcc 3.2 > bcc 3.7 > tcc 3.8 > > gcc 3.9/1.7 on virtual Ubuntu > > > Using my allocator: > > bb 1.4 seconds on Windows > gcc 1.0 (via C) > > gcc 2.2/0.9 on virtual Ubuntu > > qq 7.2 seconds (dynamic bytecode) > > > What can I conclude from those figures? According to you, absolutely > nothing (never mind my allocator is up to 3 times as fast). > > I should abandon my allocator, just use malloc, and cross-my-fingers > that whoever builds my programs happens to be using a decent C > library. > > Personally I'd rather not have that special dependency coupled with > such an unknown quantity. With my allocator, I can guarantee that > performance. It DOESN'T MATTER what C library is used. > > (My gcc installation is only 750MB and 13,000 files; I guess they > couldn't squeeze in a decent C library.) > > > (Note that my allocators, going back forever, have never stored the > size of an allocated block. That needs to be maintained by the > application, [...] So the results you reported are actually apples-and-oranges comparisons, and the main conclusion is that it isn't meaningful to compare them.