- Shitposts - 2 Updates
- std::vector<>::capacity()-growth - 9 Updates
- Conditional compilation based on templates - 3 Updates
- Is there a way to use literal-suffixes without selecting a namespace ? - 2 Updates
- beaks - 1 Update
| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Mar 20 08:35PM https://twitter.com/linuxshitpost is my new Twitter account for my Linux shitposts; please follow. Original, quality memes! :D /Flibble -- π |
| Sam <sam@email-scan.com>: Mar 20 07:00PM -0400 Mr Flibble writes: > https://twitter.com/linuxshitpost is my new Twitter account for my Linux > shitposts; please follow. Original, quality memes! :D How is it different from all the other Twitter accounts? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 19 06:14PM -0700 On 3/19/2021 12:18 AM, Bonita Montero wrote: > have a linear behaviour. > Please post your results and tell the compiler- / standard-libary > -version ! I got: 256 26.5625 512 23.4375 1024 24.1211 2048 14.9414 4096 8.44727 8192 8.8623 16384 10.5225 32768 8.40759 65536 10.6934 131072 7.61719 262144 8.93364 524288 9.865 1048576 8.03614 2097152 9.17945 4194304 12.5399 8388608 11.4621 16777216 9.46465 and one more run: 256 51.1719 512 27.1484 1024 23.8281 2048 19.3359 4096 8.27637 8192 8.63037 16384 9.61304 32768 7.76978 65536 8.69446 131072 11.3541 262144 9.21021 524288 10.709 1048576 12.0368 2097152 13.9337 4194304 12.8456 8388608 11.6393 16777216 9.28596 |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 19 06:15PM -0700 On 3/19/2021 3:23 PM, Ian Collins wrote: >> MSVC2019 + tbbmalloc >> 256 383.594 > Blimey! [...] DAMN! That is wild! I wonder if the system was under load or something? wow. |
| red floyd <no.spam.here@its.invalid>: Mar 19 06:20PM -0700 On 3/19/2021 6:14 PM, Chris M. Thomasson wrote: > 4194304 12.8456 > 8388608 11.6393 > 16777216 9.28596 Here's mine. 256 22.2656 512 8.39844 1024 3.41797 2048 5.0293 4096 3.07617 8192 3.06396 16384 2.83813 32768 3.7323 65536 4.47998 131072 5.04456 262144 5.21202 524288 5.62763 1048576 6.04553 2097152 6.34499 4194304 6.82788 8388608 7.28205 16777216 7.19015 g++ 10.2.0, Cygwin, under Windows 10. |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 20 06:48PM +0200 20.03.2021 03:15 Chris M. Thomasson kirjutas: > [...] > DAMN! That is wild! I wonder if the system was under load or something? > wow. This was the first call of TBB scalable_malloc(), so this number probably includes some setup. Indeed, when I call it first separately beforehand some times, the number becomes a bit better. 256 85.1563 512 18.1641 1024 13.5742 2048 9.7168 4096 8.39844 8192 7.55615 16384 3.83911 32768 4.36096 65536 4.50745 131072 2.98157 262144 3.80096 524288 5.81131 1048576 4.12359 2097152 5.42884 4194304 6.82046 8388608 7.73486 16777216 6.8723 |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 20 06:49PM +0100 > 4194304 6.82046 > 8388608 7.73486 > 16777216 6.8723 I guess the high overhead in the 2 ^ 24 * 8 (assuming 64 bit addres- sing, i.e. size_t is 8 bytes) = 512MB case results from the high memory-latency when writing to the memory. Usually latency is only a load-operation topic, but when you fill such a large amount of memory, the memory-interface, caches and write-buffers stall. |
| wij <wyniijj@gmail.com>: Mar 20 11:08AM -0700 On Sunday, 21 March 2021 at 01:49:46 UTC+8, Bonita Montero wrote: > memory-latency when writing to the memory. Usually latency is only > a load-operation topic, but when you fill such a large amount of > memory, the memory-interface, caches and write-buffers stall. I think the memory growing factor by x2 is correct. After all, it is a C++ program, and lots of other library functions depend on this feature. If concerned, use reserve(size_t) beforehand. |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 20 07:36PM +0100 > I think the memory growing factor by x2 is correct. After all, it is a C++ program, > and lots of other library functions depend on this feature. > If concerned, use reserve(size_t) beforehand. That's not related to what I said. Because the allocation-overhead becomes more negligible with a growing allocation-size the memory -latency rules and pre-reserve()-ing wouldn't help much. Only if moving the objects has a high overhead reserve() would gain some- thing here. |
| wij <wyniijj@gmail.com>: Mar 20 11:57AM -0700 On Sunday, 21 March 2021 at 02:36:37 UTC+8, Bonita Montero wrote: > -latency rules and pre-reserve()-ing wouldn't help much. Only if > moving the objects has a high overhead reserve() would gain some- > thing here. It seemed to me you were trying re-implementing the low level function void *malloc(size_t) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 20 01:10PM -0700 On 3/20/2021 9:48 AM, Paavo Helde wrote: > 4194304 6.82046 > 8388608 7.73486 > 16777216 6.8723 Ahhhh! I think you are correct. It been a while since I tested against the tbb. I remember conversing with TBB implementers way back in some Intel threading forums. |
| MrSpook_K3me@636umvily2vqnpy.com: Mar 20 10:47AM Is there any way of munging this or if not does anyone know if it might be coming in the forthcoming standard? Eg I'd like code similar to the following to compile: if (typeid(T) != typeid(chrono::steady_clock)) { time_t tend = T::to_time_t(end); cout << "Finished at: " << ctime(&tend); } Sure, I could just specialise a function but the above would be a lot more convenient. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 20 04:25PM +0100 > } > Sure, I could just specialise a function but the above would be a lot more > convenient. If this is in template code then you can just check the type at compile time, like if constexpr( not is_same_v<T, chrono::steady_clock> ) { Possibly you may have to remove reference and cv-qualification of T. Ref. <url: https://en.cppreference.com/w/cpp/types/is_same> --- Not what you're asking, but the code essentially says that only if type T is not a steady_clock do you want to output the end time, and in that case you're sure that type T has a to_time_t static member function, and that's all quite baffling to me. I would think about ways to reorganize that so that it doesn't depend so much on the details of the (unspecified) context. Because: as general habit that makes it easier to change things in code without having to worry about that a piece of it here or there might stop working because it depended on a contextual detail. - Alf |
| MrSpook_6r2z@s5p.net: Mar 20 03:38PM On Sat, 20 Mar 2021 16:25:07 +0100 >time, like > if constexpr( not is_same_v<T, chrono::steady_clock> ) { >Possibly you may have to remove reference and cv-qualification of T. Thanks, worked. |
| Christian Gollwitzer <auriocus@gmx.de>: Mar 20 08:23AM +0100 Am 19.03.21 um 20:14 schrieb Bonita Montero: >> Sure, it's longer, but a lot easier to read and understand at a >> quick glance. > I always select the std::/chrono::-namespaces in my .cpp-file globally. How about importing only the suffixes, like "using std::chrono::s" ? (untested) Christian |
| Bonita Montero <Bonita.Montero@gmail.com>: Mar 20 10:18AM +0100 >> I always select the std::/chrono::-namespaces in my .cpp-file globally. > How about importing only the suffixes, like "using std::chrono::s" ? > (untested) That's a matter of taste and too much work for me to import every single entity. |
| Mr Flibble <flibble@i42.REMOVETHISBIT.co.uk>: Mar 20 01:36AM "You are a big posh sod with plums in your mouth, and the plums have mutated and they have got beaks. You make pigs smoke. You feed beef burgers to swans. You have big sheds, but nobody's allowed in. And in these sheds you have 20ft high chickens, and these chickens are scared because the don't know why they're so big, and they're going, "Oh why am I so massive?" and they're looking down at all the little chickens and they think they're in an aeroplane because all the other chickens are so small. Do you deny that? No, I think his silence speaks volumes." /Flibble -- π |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment