| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 28 01:46AM +0100 Hi. Just published on article on C++ and data-oriented design: https://leighjohnston.wordpress.com/2018/08/27/data-oriented-design-and-avoiding-the-c-object-oriented-programming-zimmer-frame/ "Object-oriented programming, OOP, or more importantly object-oriented design (OOD) has been the workhorse of software engineering for the past three decades but times are changing: data-oriented design is the new old kid on the block." /Flibble -- "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." |
| Melzzzzz <Melzzzzz@zzzzz.com>: Aug 28 04:16AM > design (OOD) has been the workhorse of software engineering for the past > three decades but times are changing: data-oriented design is the new old > kid on the block." I really don't get this. If I need something to be polymorphic, it is, if I don't, it's not. And nowadays computers are not just orders of magnitude faster then zx spectrum ;) -- press any key to continue or any other to quit... |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 28 03:49PM +0100 On 28/08/2018 05:16, Melzzzzz wrote: > I really don't get this. If I need something to be polymorphic, it is, if > I don't, it's not. And nowadays computers are not just orders of > magnitude faster then zx spectrum ;) I think you will find that 3.5GHz is three orders of magnitude faster than 3.5MHz. /Flibble -- "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." |
| scott@slp53.sl.home (Scott Lurndal): Aug 28 03:12PM >> magnitude faster then zx spectrum ;) >I think you will find that 3.5GHz is three orders of magnitude faster than >3.5MHz. It's a lot faster than that, due to fast multi-level caches, multiple pipelines and out-of-order execution. That 1985 processor had slow memory, no cache and an IPC probably less than 0.1 (as compared with a modern processor which pushes an IPC close to 2.0). |
| boltar@cylonHQ.com: Aug 28 03:29PM On Tue, 28 Aug 2018 01:46:04 +0100 >design (OOD) has been the workhorse of software engineering for the past >three decades but times are changing: data-oriented design is the new old >kid on the block." If you don't need OO and purely care about speed then why bother with C++ at all, just use C and assembler. You don't need a Sprites class nor do you need a vector of sprite bodies, just use a C array or one of the *alloc*() functions or sbrk() if you want to so your own low level memory management (assuming you're using Linux , not the toy OS from MS). As for your intrusive_sort - your swapper seems inordinately complex with little explanation as to what index() or reverse_index() actually do. I can't see many takers frankly. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 28 05:13PM +0100 On 28/08/2018 16:12, Scott Lurndal wrote: > and out-of-order execution. That 1985 processor had slow memory, no cache > and an IPC probably less than 0.1 (as compared with a modern processor which > pushes an IPC close to 2.0). Yes indeed and if we take that and multiple cores into account it still doesn't invalidate my assertion that machines of today are orders of magnitude faster than the machines of the 1980s which is why I don't understand Melzzzzz's point. Perhaps Melzzzzz doesn't understand the term "orders of magnitude". /Flibble -- "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." |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 28 05:18PM +0100 > As for your intrusive_sort - your swapper seems inordinately complex with > little explanation as to what index() or reverse_index() actually do. I can't > see many takers frankly. The troll returns. You can't see many takers because you literally have no clue as to how to use C++ properly as evidenced by your previous posts to this group. I wasn't suggesting that you should stop using OOP all together but that it is just one tool in toolbox and data-oriented design is making a comeback due to the nature of modern hardware. You obviously didn't even attempt to understand my article at all. Troll: be gone! /Flibble -- "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." |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 28 01:27PM -0700 On Monday, August 27, 2018 at 8:46:19 PM UTC-4, Mr Flibble wrote: > design (OOD) has been the workhorse of software engineering for the past > three decades but times are changing: data-oriented design is the new old > kid on the block." My philosophy for the past 8+ years has been lower-level than C++, and has been that we have to look at data as data and not as the limitations of compute abilities exposed by the underlying hardware. We need to view data in constructs which have solidly defined rules by their data needs, and not by the machine needs which compute them under the hood. This necessarily translates the needs of a C or C++ compiler into a tool which addresses those fundamental constraints, and ahead of the mere computability of something, but rather the correct computability of something regardless of the machines underlying capabilities. -- Rick C. Hodgin A retort to Stephen Fry: ["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?"] God has identified Himself as male. He calls the church His bride, which hints of our future with Him, married to Him, possessing this entire universe as our own, as we will receive what He has as ours, and He will receive what we have as His, just as marriages here on Earth are patterned after. This gives us a future. ["I'd say, bone cancer in children? What's that about?" Fry replied.] God has taught us the cost of sin, and the nature of our free will. He has given us information about the power of our choices, that our own decisions can affect eternity for us, and others. He has revealed just how costly sin is, that it will completely subdue a man for all eternity. He has revealed His love to us in that even though we are all sinners, He still makes a way out for us, and He makes it available to us for free. ["How dare you? How dare you create a world to which there is such misery that is not our fault.] It /IS/ our fault. We disobeyed God's instruction, and He warned us in advance of the consequences. Adam would've been perfect in his understanding, and he would've known what God had meant. Adam made a choice to rebel against God, and it cost us everything we see in this world that is not right, and utterly, utterly evil. [It's not right, it's utterly, utterly evil."] It is not right, and it is utterly, utterly evil that such a thing exists. But it is /our own/ doing, and God has made a completely and totally free way to escape it. And even with that free way being given to people, taught on nearly every street corner, men and women like me proclaiming it even in the places people who do not go to church would hear ... yet will so many still ignore it, pass it by, think it's garbage, until the very day they are taken hold of and manhandled physically, cast into the lake of fire for all eternity. Then the true cost of sin will be known ... upon every soul who was not saved by their own rejection of God ... again. ["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."] God gives us the calling, power, ability, and choice, to not follow after that world so full of injustice and pain. But, because of our own sin, we do not follow after God's path here in this world. We choose to go the way of hate and meanness. We call people names and use profanity and insult attempts to bring things into a right order by presenting them as something that should be subject to God. No, Stephen Fry, God has not created this evil you see here. Man has. He has taken hold of sin with both hands, wrapped it around his body, and put up a perimeter of defense around himself such that anyone attempting to cross that border and strip him of his sin will be shot on sight multiple times until they are dead, dead, dead! That is the cost of sin in this world, Mr. Fry. And that is why God created a special place to contain it. No one from there can exit, and no one from here can enter, save through the judgment on that great and final day for so many. I'm sorry, Mr. Fry, but you do not understand as you should, which is why you are confused. If you do not straighten that out, it will cost you your eternal soul, which is a price more than you are able or willing to pay. It's why you need Jesus to pay that price for you. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 28 09:42PM +0100 On 28/08/2018 21:27, Rick C. Hodgin wrote: > tool which addresses those fundamental constraints, and ahead of the > mere computability of something, but rather the correct computability > of something regardless of the machines underlying capabilities. And fossils are an invention of Satan yes? /Flibble -- "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." |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Aug 28 01:47PM -0700 On 8/27/2018 5:46 PM, Mr Flibble wrote: > design (OOD) has been the workhorse of software engineering for the past > three decades but times are changing: data-oriented design is the new > old kid on the block." It is a good practice to allocate all of the sprites _data_ in a contiguous memory. Way more efficient than allocating each one individually. Still need to take a closer look at intrusive_sort. :^) |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Aug 28 02:01PM -0700 On Tuesday, August 28, 2018 at 4:42:28 PM UTC-4, Mr Flibble wrote: > And fossils are an invention of Satan yes? I'll answer your questions. You've never listened to a single reply of mine, have you, Leigh? Because I've answered this one before (more than once IIRC). No, fossils are not an invention of Satan, only the explanation is his that they are the result of evolution laid down over mil- lions and billions of years. Fossils exist properly as they are, buried in rock layers all over the world, and they have a true scientific explanation ... but you'll never hear it until God draws you from within, and that will never happen until you begin to seek the truth and don't just assert things you think are correct. -- Rick C. Hodgin |
| Vir Campestris <vir.campestris@invalid.invalid>: Aug 28 11:02PM +0100 On 28/08/2018 16:12, Scott Lurndal wrote: > and out-of-order execution. That 1985 processor had slow memory, no cache > and an IPC probably less than 0.1 (as compared with a modern processor which > pushes an IPC close to 2.0). That 1985 processor was a Z80. I can't quote you figures, but for an 8085 the IPC was around 2/3, and the speed was similar to a Z80. Many instructions took 4 clocks, quite a lot an extra 3, and not many any more than that. 8 bit operands and no HW divide would also slow you down a bit! Andy |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 28 01:39AM +0100 On Mon, 27 Aug 2018 20:25:35 +0100 > method. If it can be concurrently mutated the user needs an external > locking mechanism. It also happens to the be approach adopted by most > code I have seen, including the standard library. OK, I have now reread the entire thread twice to see where the disagreement is coming from. Piecing it together, I think you agree with what I have just said. The problem is that you expressed yourself, in your reference to thread safety, more expansively than perhaps you intended, and I took your words at face value. So let's agree on the above formulation. Let us agree to disagree on what it means for a function to be "thread safe", since it isn't material to the formulation that we can agree on. (I can carry on with "thread safe" if you wish to, but I suggest better not to.) |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 27 08:25PM +0100 On Mon, 27 Aug 2018 16:42:52 -0000 (UTC) > I mean is that "a const method should be implemented so that it can be > safely called from multiple threads without the need of a locking > mechanism". It's not even my idea. I would not agree with that point either. Const methods should, in my opinion, be implemented so that they can safely be called from multiple threads without the need for a locking mechanism provided that the object concerned cannot also be concurrently mutated by a non-const method. If it can be concurrently mutated the user needs an external locking mechanism. It also happens to the be approach adopted by most code I have seen, including the standard library. > supposed to behave. Yet, still, I am the one who is somehow in the wrong > here. Because of that one term "thread-safe" in one post, which you still > keep clinging onto. I am not trying to mock you. I was trying to point out, apparently unsuccessfully, that if you think that invoking a const method is going to be thread-safe by virtue of it being const, you will be writing thread-unsafe code. I think you are so self-defensive that you have become confused. As to the meaning of "thread-safe", (i) it is well established in the industry, and (ii) words cannot just mean whatever you want them to mean. Humpty Dumpty: "... There's glory for you!" "I don't know what you mean by 'glory'," Alice said. Humpty Dumpty smiled contemptuously. "Of course you don't – till I tell you. I meant 'there's a nice knock-down argument for you!'" "But 'glory' doesn't mean 'a nice knock-down argument'," Alice objected. "When I use a word," Humpty Dumpty said, in a rather scornful tone, "it means just what I choose it to mean – neither more nor less." "The question is," said Alice, "whether you can make words mean so many different things." "The question is," said Humpty Dumpty, "which is to be master - that's all." I am with Alice, not Humpty Dumpty. |
| Vir Campestris <vir.campestris@invalid.invalid>: Aug 27 10:53PM +0100 On 27/08/2018 17:42, Juha Nieminen wrote: > I mean is that "a const method should be implemented so that it can be > safely called from multiple threads without the need of a locking > mechanism". It's not even my idea. I've read all through this thread. Can I make a general appeal here to everyone to not drop to insults? It doesn't help. That aside, the view I've always taken for a const method is "it won't alter the visible state of the object". I can imagine a method that makes a summary of the state of the object. Suppose, for example, the collection can be boiled down to a string. The to_str() method would collate whatever data was needed to represent the object. That might involve significant calculations, and might be enough that it's worth caching the string internally. If calling the method from two threads simultaneously is permitted then the method will have to take a lock on the cache before operating. If the method will only ever be run in a single-threaded context then there is no need for the lock, and it is unnecessary overhead. It may be that in your application the use of threads is so widespread that it is worth having a coding standard that states that all const methods must be able to run concurrently with all other const methods, and that this makes the maintenance of your codebase easier. In fact, it probably does (and the codebase I am working on now might benefit from such a standard!) BUT It's not something that is needed everywhere. Specifically it is not needed for single threaded applications, and will only add complexity. Which means potential bugs. So I don't support your idea that _all_ const methods should be thread safe. Andy |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 27 11:19PM +0100 On Mon, 27 Aug 2018 22:53:17 +0100 > and that this makes the maintenance of your codebase easier. In fact, it > probably does (and the codebase I am working on now might benefit from > such a standard!) I do aim for that standard in my code. I don't think it causes much overhead. Generally it just requires locking of any member data marked 'mutable' and, so far as relevant, any static data, and synchronization of any i/o done by const methods. That is normally about it. The C++ standard library adopts this approach. > .. I don't support your idea that _all_ const methods should be thread safe. I am strongly against that. That would cause unacceptable overhead in my view. It would require locking of all member or static data read by the const methods which might be mutated by non-const methods. To make all const methods thread-safe you practically have to make all non-const methods thread safe as well. I think that it is better to leave such cases to external synchronization by the user. That is also the approach adopted by the standard library, except where otherwise stated. (Obviously things like mutexes have to be thread-safe.) Chris |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Aug 27 03:24PM -0700 On 8/27/2018 9:42 AM, Juha Nieminen wrote: > I mean is that "a const method should be implemented so that it can be > safely called from multiple threads without the need of a locking > mechanism". It's not even my idea. What about const functions that are only called from a single thread? Say the const function is on a per-thread data structure. Why would the function need any synchronization if it only operates on data that is totally owned by the only thread that will ever call it? ________________________ class per_thread { int foo; public: per_thread(int foo_) : foo(foo_) {} public: int get() const { return foo + 21; } }; ________________________ There is no need to make per_thread::foo an atomic type. |
| Juha Nieminen <nospam@thanks.invalid>: Aug 28 06:16AM > what it means for a function to be "thread safe", since it isn't > material to the formulation that we can agree on. (I can carry on with > "thread safe" if you wish to, but I suggest better not to.) I don't think it should be so controversial that the sentence "it's thread-safe to call this member function" implies, without the need for long explanations, that multiple threads can call *that particular function* at the same time without having to worry about concurrency issues. If you object to the word "thread-safe" being used for this purpose, then what other word would you use? I suppose that if one would want to be absolute clear about the meaning, one could add "(as long as no non-const functions of this object are being called at the same time)" or something to that effect. |
| Juha Nieminen <nospam@thanks.invalid>: Aug 28 06:20AM > Say the const function is on a per-thread data structure. Why would the > function need any synchronization if it only operates on data that is > totally owned by the only thread that will ever call it? I don't understand what you are asking. If a const function is safe to call from multiple threads, it's certainly safe to call from one single thread. (And let me clarify once again that what I mean is that it's safe for multiple threads to call *that particular function*. It does not mean that if some thread *also* calls some other non-const function, it's still safe. In practice this means that const methods shouldn't be modifying anything. Or even if for some reason they have to, that modification should be atomic or use a locking mechanism.) |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Aug 27 11:31PM -0700 On 8/27/2018 11:20 PM, Juha Nieminen wrote: >> function need any synchronization if it only operates on data that is >> totally owned by the only thread that will ever call it? > I don't understand what you are asking. Not all const needs to be thread safe? |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 28 09:59AM +0100 On Tue, 28 Aug 2018 06:16:33 -0000 (UTC) > function* at the same time without having to worry about concurrency issues. > If you object to the word "thread-safe" being used for this purpose, > then what other word would you use? I do object to it being used for that purpose. std::string::length() is const and meets your description. I doubt anyone would describe it as "thread-safe", because if another thread were to append or delete a character without external synchronization you would have undefined behaviour[1]. I don't think there is an expression which is generally used to meet your description. "const in a standard library sense" might do, but that would require the hearer to know what the C++ standard prescribes for the standard library on this point. > I suppose that if one would want to be absolute clear about the meaning, > one could add "(as long as no non-const functions of this object are > being called at the same time)" or something to that effect. That would do, although in the absence of synchronization "at the same time" is somewhat problematic. Different threads can have different views about state and time. [1] The standard says you have undefined behaviour. In fact on many platforms the code would work, albeit return values might be somewhat out of date as if by relaxed memory ordering, because the fundamental type of which std::size_t is a typedef is generally atomic at the hardware level. If it helps the point, visualize a more complex const method which might crash your program. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 28 10:10AM +0100 On Tue, 28 Aug 2018 09:59:15 +0100 > type of which std::size_t is a typedef is generally atomic at the > hardware level. If it helps the point, visualize a more complex const > method which might crash your program. I qualify that. std::string::length() wouldn't crash, but it would only "work" without synchronization in many std::string implementations if only one thread were to append or delete a character without synchronization. If two or more could do so without external synchronization the length counter (and the string) could get in an inconsistent state which would breach invariants. |
| Daniel <danielaparker@gmail.com>: Aug 28 08:31AM -0700 On Tuesday, August 28, 2018 at 4:59:34 AM UTC-4, Chris Vine wrote: > > then what other word would you use? > I don't think there is an expression which is generally used to meet > your description. How about "reentrant"? Daniel |
| "Öö Tiib" <ootiib@hot.ee>: Aug 28 08:42AM -0700 On Tuesday, 28 August 2018 09:16:49 UTC+3, Juha Nieminen wrote: > function* at the same time without having to worry about concurrency issues. > If you object to the word "thread-safe" being used for this purpose, > then what other word would you use? May be "reentrant"? |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 28 08:26PM +0100 On Tue, 28 Aug 2018 08:31:33 -0700 (PDT) > > I don't think there is an expression which is generally used to meet > > your description. > How about "reentrant"? I would need to think about it, but I think it is possible to have a non-reentrant member function which still meets the standard library demands for const member functions under discussion (below, "the const requirements"), or a reentrant member function which does not meet the const requirements. The rules on accessing and modifying non-local data such as member variables would be different between the two. In a reentrant member function suitable for use as a signal handler such member variables would have to be of type sig_atomic_t and qualified as volatile. Under the const requirements they would have to be marked mutable and be atomic or protected by locking, or be thread local. |
| 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