Re: [darktable-dev] compiler warnings regarding variable length arrays
On Sun, Sep 24, 2017 at 11:39 AM, johannes hanika wrote: > hi, Hi. > i disagree. i really like variable length arrays > and std::vectors dynamically allocate memory on the heap https://llvm.org/docs/ProgrammersManual.html#dss-smallvector > with standard implementations locking a global mutex > on the way causing slowdown for multithreaded cases. That *might* be not so true today https://sourceware.org/glibc/wiki/MallocInternals#Arenas_and_Heaps > just incrementing the stack pointer is a simple thing, it's > thread local and light weight. and memory resources will run out > whether i do a complicated or a simple memory allocation scheme (with > linux overcommitting, you can't even test malloc == 0, so i don't see > how heap allocation is any safer). also, variable sized arrays mean > it's not known compile time, but once you enter the function you know > exactly how large you need it (no need for dynamically growing > complicated structures). To add to that, it's somewhat even worse than with overcommitting, if the VLA stack allocation fails, i believe it results in a SIGSEGV.. Though, less stack usage, less pages the kernel has to swap out, mark dirty, etc Also, i guess, having some default stack size can be compared to each application [thread] doing malloc(512Mb), and then maybe using it or maybe not. Assuming no overcommit, that already puts some limits on the number of simultaneously running apps. > i understand however that some libc implementations have issues with > that and that it makes people feel uncomfortable about predicting > whether the code is correct or not. so we do the inconvenient grown-up > thing and warn about it in dt. > > cheers, > jo Roman. > On Sat, Sep 23, 2017 at 8:07 AM, Heiko Bauke wrote: >> Hi, >> >> Am 22.09.2017 um 15:35 schrieb Tobias Ellinghaus: >>> >>> No, you are missing the point of those pragmas: darktable from git always >>> builds with "-Werror", thus the "-Wvla" switch actually throws an hard >>> error >>> when using VLAs. With the pragma we are relaxing that back to a warning >>> again >>> to be able to use VLAs in some places. >> >> >> I understand, makes sense. After reading the article about the save usage >> of variable length arrays mentioned in my other mail, I thing variable >> length arrays are actually not as great as I thought. What one really wants >> is probably a std::vector. But this has not yet been invented in C. >> >> >> >> Heiko >> >> -- >> -- Number Crunch Blog @ https://www.numbercrunch.de >> -- Cluster Computing @ http://www.clustercomputing.de >> -- Professional @ https://www.mpi-hd.mpg.de/personalhomes/bauke >> -- Social Networking @ https://www.researchgate.net/profile/Heiko_Bauke >> ___ >> darktable developer mailing list >> to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org >> > ___ > darktable developer mailing list > to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
Re: [darktable-dev] compiler warnings regarding variable length arrays
Am Sonntag, 24. September 2017, 21:39:33 CEST schrieb johannes hanika: > hi, > > i disagree. i really like variable length arrays. and std::vectors > dynamically allocate memory on the heap, with standard implementations > locking a global mutex on the way, causing slowdown for multithreaded > cases. just incrementing the stack pointer is a simple thing, it's > thread local and light weight. and memory resources will run out > whether i do a complicated or a simple memory allocation scheme (with > linux overcommitting, you can't even test malloc == 0, so i don't see > how heap allocation is any safer). also, variable sized arrays mean > it's not known compile time, but once you enter the function you know > exactly how large you need it (no need for dynamically growing > complicated structures). alloca() FTW ;-) [...] > cheers, > jo Tobias [...] signature.asc Description: This is a digitally signed message part.
Re: [darktable-dev] compiler warnings regarding variable length arrays
hi, i disagree. i really like variable length arrays. and std::vectors dynamically allocate memory on the heap, with standard implementations locking a global mutex on the way, causing slowdown for multithreaded cases. just incrementing the stack pointer is a simple thing, it's thread local and light weight. and memory resources will run out whether i do a complicated or a simple memory allocation scheme (with linux overcommitting, you can't even test malloc == 0, so i don't see how heap allocation is any safer). also, variable sized arrays mean it's not known compile time, but once you enter the function you know exactly how large you need it (no need for dynamically growing complicated structures). i understand however that some libc implementations have issues with that and that it makes people feel uncomfortable about predicting whether the code is correct or not. so we do the inconvenient grown-up thing and warn about it in dt. cheers, jo On Sat, Sep 23, 2017 at 8:07 AM, Heiko Bauke wrote: > Hi, > > Am 22.09.2017 um 15:35 schrieb Tobias Ellinghaus: >> >> No, you are missing the point of those pragmas: darktable from git always >> builds with "-Werror", thus the "-Wvla" switch actually throws an hard >> error >> when using VLAs. With the pragma we are relaxing that back to a warning >> again >> to be able to use VLAs in some places. > > > I understand, makes sense. After reading the article about the save usage > of variable length arrays mentioned in my other mail, I thing variable > length arrays are actually not as great as I thought. What one really wants > is probably a std::vector. But this has not yet been invented in C. > > > > Heiko > > -- > -- Number Crunch Blog @ https://www.numbercrunch.de > -- Cluster Computing @ http://www.clustercomputing.de > -- Professional @ https://www.mpi-hd.mpg.de/personalhomes/bauke > -- Social Networking @ https://www.researchgate.net/profile/Heiko_Bauke > ___ > darktable developer mailing list > to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org > ___ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
