- On-line code generation - 4 Updates
- Pragma once support - 4 Updates
- experimental multi-mutex algorithm... - 5 Updates
| scott@slp53.sl.home (Scott Lurndal): Dec 02 04:14PM >that sound great. I wasn't impressed, though with their >C++ compiler. It produced chubby (text) segments compared >to gcc or even clang. A more useless metric for code quality is hard to imagine. |
| woodbrian77@gmail.com: Dec 02 10:03AM -0800 On Sunday, December 2, 2018 at 10:14:40 AM UTC-6, Scott Lurndal wrote: > >C++ compiler. It produced chubby (text) segments compared > >to gcc or even clang. > A more useless metric for code quality is hard to imagine. I should note that I'm using -Os to build. Here's an example of the output of the 'size' command: text data bss dec hex filename 45936 2400 1584 49920 c300 icc.cmwA 35009 1232 8 36249 8d99 clang.cmwA 27782 1176 8 28966 7126 gcc.cmwA Why does icc produce such a big bss segment? Those bytes have to be zeroed out before the program runs. Somehow icc makes clang look good. Brian Ebenezer Enterprises - "This year, Jews around the world will celebrate Hanukkah from Sunday at sundown until Dec. 10 at sundown. While the holiday is widely known as the Festival of Lights, it is really the Festival of Miracles." https://www.foxnews.com/opinion/rabbi-tuly-weisz-hanukkah-is-not-just-a-festival-of-lights-but-a-festival-of-miracles |
| Richard Damon <Richard@Damon-Family.org>: Dec 02 02:30PM -0500 > have to be zeroed out before the program runs. Somehow > icc makes clang look good. > Brian I suppose you could look at the linker map and see what things were put into the bss segment. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 02 10:42PM > Why does icc produce such a big bss segment? Those bytes > have to be zeroed out before the program runs. Somehow > icc makes clang look good. It isn't a matter of concern and as such nobody cares about it except you. /Flibble -- "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| Vir Campestris <vir.campestris@invalid.invalid>: Dec 02 09:58PM On 01/12/2018 15:32, Bonita Montero wrote: > I'll bet my right hand that parsing the C++-source and generating > code takes magnitudes more CPU-time than parsing and branching upon > the include-guards. I benchmarked this at my last company. One order, maybe. Two - no. It was scary how long it took opening those files. Mind, this was on spinning rust. Andy |
| Vir Campestris <vir.campestris@invalid.invalid>: Dec 02 09:58PM On 30/11/2018 21:59, Alf P. Steinbach wrote: > Did you try Lakos external include guards? Never heard of them. And now I've looked - no. And I don't intend to. It's bad enough making sure a copy of a file has an updated guard name without copying those guard names into a load of source files. <fx looks down> I've not (yet) been bitten by having two versions of a 3rd party library in the source tree, and if I found that I'd be trying to dump one of the versions. Andy |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 02 10:29PM On Sun, 2018-12-02, Vir Campestris wrote: > I benchmarked this at my last company. > One order, maybe. Two - no. It was scary how long it took opening those > files. Mind, this was on spinning rust. The rust shouldn't matter much, since these headers quickly end up in the disk cache -- on Unix anyway, with adequate amounts of RAM. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| David Brown <david.brown@hesbynett.no>: Dec 02 11:35PM +0100 On 02/12/2018 23:29, Jorgen Grahn wrote: >> files. Mind, this was on spinning rust. > The rust shouldn't matter much, since these headers quickly end up in > the disk cache -- on Unix anyway, with adequate amounts of RAM. If he is using Windows (at least Win7 and before - I haven't used any later versions enough to comment about them), it /does/ matter. Windows file caching is ridiculously bad, and it will re-read them from the disk most of the time. |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Dec 01 06:53PM -0800 On 11/30/2018 11:18 AM, Pavel wrote: >> pointers into a table of locks. A thread can create a little array of >> hashed pointers, sort them, remove duplicates, then take all of the >> locks in the table. The sorting and uniqueness factor prevents deadlock. [...] > transactionally alter multiple rows (or records or sets etc for > non-relational DBMSs) for concurrent transactions so the algorithm > itself is sound. Wrt threads, the use cases are generally geared toward in memory database type schemes. Or any time a thread needs to lock a couple of objects, read/write, unlock. The n-ary dining philosophers problem is solved by this. One interesting use case is implementing C++11 or C11 atomics. Every type that uses locks would have to take the following into account wrt the value of the ATOMIC_*_LOCK_FREE macros, and the atomic_is_lock_free function: https://en.cppreference.com/w/cpp/atomic/atomic_is_lock_free They need to be zero wrt a locking scheme. The multex can also be used for the writer side of a RCU algorithm. Big time point, this is NOT recursive!, must keep that in mind. One point, we can augment the lock table for other fun things besides lock-based algorithms... We can define ATOMIC_*_LOCK_FREE as 1, or even 2. > (I saw code that did it but always in the context where I would either > refactor it to not do it or at least wanted to refactor it so). It might > certainly be that my experience is skewed so I am curious to see a use case. Hashed address locking can be used to implement DCAS, that can be used to build other things. The fact that the atomic lib can be created by addr locks means it exists at a lower level to build higher level objects with. This can be used for inter or intra process communications using robust mutexes. The robust type are hard to simulate in user-space without using a watchdog process, so to speak. C11 or C++11 do not offer such things. They are POSIX, and Windows. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Dec 02 09:43AM +0100 Am 02.12.18 um 03:53 schrieb Chris M. Thomasson: >> itself is sound. > Wrt threads, the use cases are generally geared toward in memory > database type schemes. I wrote an in memory DB kernel some years ago and avoided this type of locking. Snapshot isolation with immutable objects and optimistic locking provided better performance and simplified locking significantly with almost no risk of deadlocks. > Or any time a thread needs to lock a couple of > objects, read/write, unlock. The n-ary dining philosophers problem is > solved by this. I think especially considering NUMA and/or cluster servers traditional mutex locking will become less useful. It is a bottleneck due to the limited speed of synchronization. Of course, for now there are use cases where a mutex perfectly fit the needs. But I strongly recommend to avoid to gather more than one mutex at a time. Sooner or later it will cause problems, at least increased effort. > One interesting use case is implementing C++11 or C11 > atomics. Dark chapter. Who needs atomics that /might/ be lock free? OK, in practice most of the time they /are/ lock free, at least for small types. But there is always the risk of running into a performance bottleneck on the next platform. :-/ > One point, we can augment the lock table for other fun things besides > lock-based algorithms... We can define ATOMIC_*_LOCK_FREE as 1, or even 2. ? Marcel |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Dec 02 04:30PM -0500 Chris M. Thomasson wrote: ... > Wrt threads, the use cases are generally geared toward in memory database type > schemes. Or any time a thread needs to lock a couple of objects, read/write, > unlock. The n-ary dining philosophers problem is solved by this. ... Which variation did you solve? Any requirements on fairness / starvation avoidance? (Asking to try to decompose it without multiple lock of mutexes. Obviously, locking of multiple chopsticks have to be done as it's a part of the problem statement, but a chopstick does not have to have a mutex). Thanks! -Pavel |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Dec 02 02:01PM -0800 On 12/2/2018 12:43 AM, Marcel Mueller wrote: > locking. Snapshot isolation with immutable objects and optimistic > locking provided better performance and simplified locking significantly > with almost no risk of deadlocks. That's fine. Any risk of livelock wrt the optimistic locking in your scheme? Seqlocks can be pretty nice at getting a fast snapshot: https://en.wikipedia.org/wiki/Seqlock > I think especially considering NUMA and/or cluster servers traditional > mutex locking will become less useful. It is a bottleneck due to the > limited speed of synchronization. This is just an example of address based locking. There are a lot of faster, and much more scalable synchronization algorithms out there. > needs. But I strongly recommend to avoid to gather more than one mutex > at a time. Sooner or later it will cause problems, at least increased > effort. There are places where it is required. For instance, if you have to simulate something like DCAS with locks, then there are two addresses involved. >> One interesting use case is implementing C++11 or C11 atomics. > Dark chapter. Who needs atomics that /might/ be lock free? Very dark. > OK, in practice most of the time they /are/ lock free, at least for > small types. But there is always the risk of running into a performance > bottleneck on the next platform. :-/ Well, if your program runs on such a system, it can warn the user that the performance might not be up to par... ;^o >> One point, we can augment the lock table for other fun things besides >> lock-based algorithms... We can define ATOMIC_*_LOCK_FREE as 1, or >> even 2. The address based hashing can be used to distribute some algorithms. |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Dec 02 02:08PM -0800 On 12/2/2018 1:30 PM, Pavel wrote: >> unlock. The n-ary dining philosophers problem is solved by this. > ... > Which variation did you solve? I did one a while back for fun where each diner was a different creature that could have more than two hands. > Any requirements on fairness / starvation avoidance? It shall not deadlock. It shall provide forward progress. > (Asking to try to decompose it without multiple lock of mutexes. Obviously, > locking of multiple chopsticks have to be done as it's a part of the problem > statement, but a chopstick does not have to have a mutex). It depends on how fine of a grain one uses with the locking scheme. You can lock the table. Lock each diner. Lock each chopstick. |
| 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