Thursday, November 7, 2019

Digest for comp.lang.c++@googlegroups.com - 25 updates in 5 topics

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 06 04:27PM -0800

On 11/6/2019 2:43 AM, Bonita Montero wrote:
> on the entires will outweigh the allocation.
> I'm asking myself if there's a class in boost or another well-known
> classlib that implements the same pattern.
[...]
 
This reminds me of my ralloc experiment. It can be used as a sort of alloca:
 
https://pastebin.com/raw/f37a23918
 
https://groups.google.com/forum/#!original/comp.lang.c/7oaJFWKVCTw/sSWYU9BUS_QJ
Bonita Montero <Bonita.Montero@gmail.com>: Nov 07 06:20AM +0100

>> alloca() calls a function called __chkstk which touches the pages down
>> the stack to tigger Windows' overcommitting of stacks,
 
> Guard pages are no Windows-only feature.
 
You didn't understand: Windows has a moving guard-page until the#
stack-bottom. This guard-page triggers Windows stack-overcomitting.
 
>> are touched down the stack, i.e. you'll get a exception if you skip
>> a page.
 
> Exactly. This prevents from accidental out of bounds access.
 
That's stupid. Windows doesn't know if it's a out-of-bound-access or
a correct access.
 
>> classlib that implements the same pattern.
 
> Not that I know. But some string implementations use this pattern.
> Keyword "short string optimization".
 
short-string-optimizations aren't made for stack-storage; they can
reside on the heap as well. But my class is made for stack-storage
only.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 07 05:40PM +0100

On 06.11.2019 11:43, Bonita Montero wrote:
> I just found that alloca() with MSVC isn't that fast that it could be.
 
Checking things out, at least in a little toy test program the standard
allocation with g++ is amazingly fast.
 
I got the following results from appending single chars to a
std::basic_string, respectively using an arena allocator I cooked up (it
works like alloca except it defers all deallocation to the end) and the
standard allocator, and -O3 option to g++
 
 
Arena alloc: 987654 chars in 0.0034617 seconds.
Standard alloc: 987654 chars in 0.0035589 seconds.
Arena alloc: 987654 chars in 0.003044 seconds.
Standard alloc: 987654 chars in 0.0038853 seconds.
Arena alloc: 987654 chars in 0.0030895 seconds.
Standard alloc: 987654 chars in 0.003398 seconds.
Arena alloc: 987654 chars in 0.0061186 seconds.
Standard alloc: 987654 chars in 0.003454 seconds.
Arena alloc: 987654 chars in 0.0031488 seconds.
Standard alloc: 987654 chars in 0.0041217 seconds.
 
Presumably the standard allocator, before memory starts getting
fragmented just ends up doing the same as an arena allocator. No costly
searches for free blocks. Still it boggles my mind that the standard
allocator at times is even /faster/ than the simple stack like
"increment a pointer or size" allocation.
 
- Alf
Bonita Montero <Bonita.Montero@gmail.com>: Nov 07 05:46PM +0100

>> I just found that alloca() with MSVC isn't that fast that it could be.
 
> Checking things out, at least in a little toy test program the standard
> allocation with g++ is amazingly fast.
 
Of course alloca() is very fast if you don't have this stupid stack
-touching. Here's a little benchmark:
 
#include <iostream>
#include <random>
#include <chrono>
#if defined(_MSC_VER)
#include <malloc.h>
#elif defined(__linux__)
#include <alloca.h>
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)