Differential D15539
[libcxxabi] Reducing stack usage of test Authored by bcraig on Dec 15 2015, 1:47 PM.
Details
This test has a lot of classes with large amounts of manually inserted padding in them, presumable to prevent various optimizations. The test then creates lots of these objects on the stack. On embedded targets, this was usually enough to overflow the stack. I moved the objects to global / namespace scope. Since the tests are each in their own namespace, there should be no cross-test conflicts.
Diff Detail Event TimelineComment Actions Could these large padding things be related to the fact that the test is used as a performance check for the implementation? That being said, I have no idea who is paying attention to the numbers that come out of this test (if anyone even is?). Maybe @howard.hinnant knows something about it? Comment Actions My expectation is that the only thing the padding numbers would effect with regards to execution time would be cache hits and misses. If there is something subtle going on though, then those sizes need some comments and rationale. "93481" looks like it was pulled out of a hat, and it is large enough on it's own to overflow many embedded stacks. Comment Actions As an alternative, would it be acceptable to heap allocate these Comment Actions Starting primes at 13, and skipping the larger twin in twin prime pairs. Using long double instead of char for padding to help alleviate fears of multiple structs having the same actual size. Comment Actions What does having them be long doubles give over just multiplying the counts by 16 (or however big it is on your platform)? Alignment? Seems like it'd be better to start with a prime that's ~16x larger, say 211, than to have that factor of 16 floating around everywhere. Comment Actions Alignment is the main answer. I'd use max_align_t directly, except that it got added in C++11, and this test should be able to run in C++98 and C++03. Comment Actions I'm on a platform where void* is 4 bytes (Hexagon). That's not what I was getting at though. Lets take x86_64 as an example instead. #include <iostream>
struct A {
virtual ~A() {}
char _[17];
};
struct B {
virtual ~B() {}
char _[19];
};
struct C {
virtual ~C() {}
char _[23];
};
int main() {
std::cout<<"A: "<<sizeof(A)<<std::endl; //prints 32
std::cout<<"B: "<<sizeof(B)<<std::endl; //prints 32
std::cout<<"C: "<<sizeof(C)<<std::endl; //prints 32
return 0;
}I could reasonable see an optimizer collapsing some of these classes together in some way or another. If you change the chars out for long doubles, then all three classes have different sizes. Comment Actions Ping. Comment Actions FOAD: Ball's in @mclow.lists's court, not mine. I don't feel comfortable signing off on this. Comment Actions I think you've reduced the scope of the tests significantly with this change. If you want to make the objects smaller, that's fine - but please heed Howard's advice in the email thread:
Comment Actions Any objections to using the original sizes, but constructing the objects at global scope? That fixes the stack usage without significantly changing the layout characteristics of the test? Comment Actions
I think that should work. | |||||||||||