- Are there any asm-instructions to support OOP - 16 Updates
- Does std::regex need to be so large? - 9 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Aug 27 02:43AM +0200 >> or methods bound to ne namespace of the structures doesn't make a >> difference. > I don't think you have any idea what either of us is talking about. Yes, I know. And I've designed cache-aware and cache-oblivious OOP-algorithms. |
| Juha Nieminen <nospam@thanks.invalid>: Aug 27 07:23AM > Object locations could be stored contiguously in an instance of a > LocationArray class and linked (vie pointers or indexes) or otherwise > associated with the object or objects that have those locations. I don't think it's a "simplistic view of OO". It's the standard view that has always existed, since the very beginning of OOP. The way that object-oriented programming (and modular programming) works is rather logical and practical: Every object has an internal state (usually in the form of member variables) and some member functions. You can easily handle such objects, such as passing them around, copying them, querying or modifying their state, have objects manage other objects, and so on. When coupled with the concept of a public/private interface division, it makes even large programs manageable, maintainable and the code reusable. Back when OOP was first developed, in the 70's and 80', this design didn't really have any sort of negative impact on performance. After all, there were no caches, no pipelines, no fancy-pansy SIMD. Every machine code instruction typically took the same amount of clock cycles regardless of anything. How your data was arranged in memory had pretty much zero impact on the efficiency of the program. Conditionals and function calls took always the same amount of clock cycles and thus were inconsequential. (You could make the code faster by reducing the amount of conditionals, but not because they were conditionals, but because they were just extra instructions, like everything else.) However, since the late-90's and forward this has been less and less the case. The introduction of CPU pipelines saw a drastic increase in machine code throughput (in the beginning with instructions that typically took at least 3 clock cycles being reduced to taking just 1 clock cycle). On the flipside, this introduced the possibility of the pipeline getting invalidated (usually because of a conditional jump, sometimes because of other reasons). As time passed pipelines became more and more complicated, and longer and longer, and consequently the cost of a pipeline invalidation became larger and larger in terms of clock cycle penalties. Optimal code saw incredible IPS numbers, but conversely suboptimal code that constantly causes pipeline invalidation would suffer tremendously. Likewise the introduction of memory caches brought great improvements to execution speed, as often-used data from RAM was much quicker to access. But, of course, for a program to take advantage of this it would need to cause as few cache misses as possible. Nowadays SIMD has become quite a thing in modern CPUs, and compilers are becoming better and better at optimizing code to use it. However, for optimal results the code needs to be written in a certain way that allows the compiler to optimize it. If you write it in the "wrong" way, the compiler won't be able to take much advantage of SIMD. The problem with OOP is that, while really logical, practical and quite awesome from a programmer's point of view, making it much easier to manage very large programs, it was never designed to be optimal for modern CPUs. A typical OOP program will cause lots of cache misses, lots of pipeline invalidations, and typically be hard for the compiler to optimize for SIMD. In order to circumvent that problem, if one still wants to keep the code more or less object-oriented, one needs to resort to certain design decisions that are not traditional (and often not the best, from an object-oriented design point of view). Such as no longer objects having their own internal state, separate from all the other objects, but instead grouping the states of all objects in arrays. Or not having distinct objects for certain things at all, and instead use data arrays for those things. Likewise eschewing using member functions for certain things, and instead accessing the state data arrays directly (something that bypasses the abstraction princples of OOP.) Many an expert efficiency-conscious programmer will often choose a mixed approach: Use "pure" OOP for things that don't require efficiency, and use more of a Data-Oriented Design for things that do. (Also, encapsulating the DOD style arrays inside classes, to make them "more OO".) |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 27 07:49AM On Wed, 2020-08-26, Juha Nieminen wrote: >> to get, though. If anyone wants that.) > Inheritance and dynamic binding (ie. virtual functions) are not the > only performance-killers. The others were discussed in the part you snipped (although not in a lot of detail) and upthread in general. > the data related to one object into the same place, the same > data structure, is one of the major performance killers in modern > CPUs. [snip long and useful text] /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Terje Mathisen <terje.mathisen@tmsw.no>: Aug 27 10:01AM +0200 David Brown wrote: > obvious OOP hierarchy with data held in classes will not cut it. > And the speed gains can easily be an order of magnitude - it /is/ worth > doing. In the opinion of real games developers. _Anything_ that can give you a 10% speedup is worth it in games programming, at least doing it to the point where you measure a real increase in average/worst case frame rate. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching" |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 27 01:06AM -0700 On 8/27/2020 1:01 AM, Terje Mathisen wrote: > _Anything_ that can give you a 10% speedup is worth it in games > programming, at least doing it to the point where you measure a real > increase in average/worst case frame rate. Big time agreed. |
| boltar@nuttyella.co.uk: Aug 27 08:08AM On Wed, 26 Aug 2020 17:44:20 +0200 >> If you can't use much in the way of OOP you might as well just use C. >No. C++ supports OOP - but doing OOP is certainly not the only reason >to choose C++ over C. Its the main reason. Without any kids of objects - meaning no STL either - all you're really left with that means a damn is exceptions (limited usefullness if you can only throw POD types), generics, lambdas and overloading. Whether thats enough to make it worthwhile I guess depends on your use case. |
| boltar@nuttyella.co.uk: Aug 27 08:10AM On Wed, 26 Aug 2020 18:19:00 +0000 (UTC) >the year (displays are already surpassing 144 Hz refresh rates), being >able to process data as efficiently as possible with the CPU can be >a huge advantage. Given the human eye generally only notices flicker below about 30hz any greater refresh rate is simply game developer willy waving. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 27 11:40AM +0100 > objects, and so on. When coupled with the concept of a public/private > interface division, it makes even large programs manageable, maintainable > and the code reusable. Of course, but what properties belong to what objects is a matter for careful thought. We should not assume the position of something in a game will obviously be a property of the thing. Maybe there is a "scene" object that associates a vector of objects with a vector of positions. That might complicate other parts of the program, so this organisation can't be assumed to be the way to do it either. My talking about a "simplistic view of OO" was just my experience of students who tend to put everything they can think of that relates to a single object into that object. That's not always the right way. <many thoughtful comments cut -- I just don't have much to add to them> -- Ben. |
| Terje Mathisen <terje.mathisen@tmsw.no>: Aug 27 12:54PM +0200 >> a huge advantage. > Given the human eye generally only notices flicker below about 30hz any > greater refresh rate is simply game developer willy waving. First of all, bragging rights do matter, and there is at least some evidence of top e-sports players doing better with a real 60 Hz vs 30 Hz update rate. More importantly at this point is the minimum frame rate: Can your game engine stumble just at the point where maximum "stuff" is happening on-screen at the same time? Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching" |
| boltar@nuttyella.co.uk: Aug 27 01:59PM On Thu, 27 Aug 2020 11:40:26 +0100 >"scene" object that associates a vector of objects with a vector of >positions. That might complicate other parts of the program, so this >organisation can't be assumed to be the way to do it either. Any data that is unique to an object should be internal to that object unless there's a *really* good reason for that not to happen. |
| boltar@nuttyella.co.uk: Aug 27 02:02PM On Thu, 27 Aug 2020 12:54:20 +0200 >First of all, bragging rights do matter, and there is at least some >evidence of top e-sports players doing better with a real 60 Hz vs 30 Hz >update rate. Or it could be just that more expensive monitors that can support higher refresh rates also simply provide a better picture - eg less aliasing artifacts, no tearing etc. Though tbh, any activity that involves a bunch of pasty faced out of condition kids sitting in armchairs for hours and calls itself a sport without any hint of irony is hard to take seriously. |
| Stefan Monnier <monnier@iro.umontreal.ca>: Aug 27 11:09AM -0400 > Its the main reason. Without any kids of objects - meaning no STL either - all > you're really left with that means a damn is exceptions (limited usefullness if > you can only throw POD types), generics, lambdas and overloading. Hmm... remove variable assignments while you're at it, and then give it a sane syntax and call it Haskell. > Whether thats enough to make it worthwhile I guess depends on your > use case. It's actually a pretty nice language if you ask me ;-) Stefan |
| Juha Nieminen <nospam@thanks.invalid>: Aug 27 04:28PM > Given the human eye generally only notices flicker below about 30hz any > greater refresh rate is simply game developer willy waving. The "humans can't distingish anything above 24/25/30/whatever Hz refresh rate" is one the most widespread and most persistent misconceptions in modern times. It comes from cinema having standardized 24 frames per second for a very long time, and later TV standardizing 25 (PAL) and 30 (NTSC) frames per second. People don't understand why these framerates were chosen and have this completely wrong misconception about them. In cinematography 24 frames per second was chosen (more or less by trial and error) as *the absolute minimum* framerate that's *not distracting* to the average person. Film was extremely expensive especially during the first decades of cinematography, so they wanted a framerate as low as possible (because it saves film) that still "works" in the sense that people don't get too bothered by it, and it's not distracting. This doesn't mean people cannot see the difference between 24 Hz and something higher. They *most definitely* can. Pretty much *all* people can. Why do you think that when The Hobbit used 48 frames per second a huge bunch of people complained about it looking somehow "unnatural"? *Because they could see the difference.* It doesn't really matter why they felt it looked unnatural, the mere fact that they noticed is definitive proof that people *clearly see the difference* between 24 Hz and 48 Hz. Of course there are countless double-blind tests where people are tested whether they can see a difference between 60 Hz and 120 Hz, and they can, especially those who have played games with the latter refresh rate a lot). And it's not like these people get it like 75% right or something. They get it 100% right, no matter how many tests are performed. So yes, even when we go as high as beyond 60 Hz, people *can still see the difference*. Thinking that "people can't see the difference between 30 Hz and 60 Hz" is like thinking that people can't see the difference between a candle light and full sunlight, just because people can read a book with both. Anyway, the fact remains that modern games need to be able to calculate a crapload of things at a very minimum 60 times per second (which is about 16 milliseconds per frame), preferably 144 times per second and beyond. |
| mac <acolvin@efunct.com>: Aug 27 04:53PM > object protection-levels like private, protected, publich (and > package in Java)? > I think that would be very cool since you could establish security In prehistoric times (1980s) intel promoted "the Silicon Operating System", because that stuff is too hard to do in software. As recent history shows, it's even harder in hardware. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 27 07:44PM +0200 On 27.08.2020 18:28, Juha Nieminen wrote: > they felt it looked unnatural, the mere fact that they noticed is > definitive proof that people *clearly see the difference* between > 24 Hz and 48 Hz. I agree wholeheartedly with I perceive you mean, but did you get this backwards? It seems to me that people must have reacted to the 24 Hz Hobbit and found the 48 Hz Hobbit more acceptable, yes? Personally I find 23.9 Hz OK for very slow moving stuff, but especially horizontal panning and horizontal running is very annoyingly jerky at that frame rate -- which is all I have with my "private copy" films (I generally download and show my old mother one movie each Sunday, at first because in these rural parts of Norway it would be risky to use streaming service, but now also simply because of better quality such as better subtitles and no ads or warnings etc. on downloaded movies). > calculate a crapload of things at a very minimum 60 times per > second (which is about 16 milliseconds per frame), preferably > 144 times per second and beyond. - Alf |
| David Brown <david.brown@hesbynett.no>: Aug 27 08:00PM +0200 On 27/08/2020 19:44, Alf P. Steinbach wrote: > backwards? > It seems to me that people must have reacted to the 24 Hz Hobbit and > found the 48 Hz Hobbit more acceptable, yes? That would be logical - but people are not logical. People complained about the /higher/ rate, and felt it was "unnatural". What they really meant was it is different from what they were used to. You get this effect in many areas - the most obvious case being in audio hifi. When CD's came out, people complained they sounded "artificial" compared to records, when they were actually more accurate. People who use valve amplifiers feel transistor amplifiers are "unnatural" because the transistor amplifiers lack the second harmonic distortion that they have become accustomed to. And so on. > first because in these rural parts of Norway it would be risky to use > streaming service, but now also simply because of better quality such as > better subtitles and no ads or warnings etc. on downloaded movies). I've just read on the news that a popular illegal movie copying group and website has just been caught, with a Norwegian ringleader. It wasn't you (or your mother), was it? :-) |
| boltar@nuttyella.co.uk: Aug 27 08:14AM On Wed, 26 Aug 2020 13:52:12 -0700 >> Do you really think the graphics in his example were 288K times better? >;^) Try to get the following running at 60fps on a 1.5mhz 6809 CPU: >https://www.shadertoy.com/view/XtscDl You're going to have to do better than that. I've seen similar stuff in the 90s assembly demo scene runing on 486s and less. Heres the 93 winner: https://www.youtube.com/watch?v=rFv7mHTf0nA How about somebody post something that is actually impressive for a 3Ghz, 4/8 core modern PC with a dedicated GPU that is written in wasm. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 27 01:18AM -0700 >> https://www.shadertoy.com/view/XtscDl > You're going to have to do better than that. I've seen similar stuff in the > 90s assembly demo scene runing on 486s and less. Heres the 93 winner: Well the demo scene are total pros! I bow down to their skills. They are great! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 27 01:20AM -0700 > https://www.youtube.com/watch?v=rFv7mHTf0nA > How about somebody post something that is actually impressive for a 3Ghz, > 4/8 core modern PC with a dedicated GPU that is written in wasm. Fwiw, here is a favorite of mine: https://youtu.be/Gm0NWMdcbmU |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 27 01:22AM -0700 > https://www.youtube.com/watch?v=rFv7mHTf0nA > How about somebody post something that is actually impressive for a 3Ghz, > 4/8 core modern PC with a dedicated GPU that is written in wasm. Here is another fav: https://youtu.be/T_U3Zdv8to8 |
| boltar@nuttyella.co.uk: Aug 27 08:38AM On Thu, 27 Aug 2020 01:20:49 -0700 >https://youtu.be/Gm0NWMdcbmU >Here is another fav: >https://youtu.be/T_U3Zdv8to8 To fit something like those in 64K (even though I assume it doesn't include the dlls required) is just staggering. These guys really are programmming geniuses. The music from the 2nd one sounds familiar. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 27 01:53AM -0700 > To fit something like those in 64K (even though I assume it doesn't include > the dlls required) is just staggering. These guys really are programmming > geniuses. Indeed! Big time. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 27 02:43AM -0700 On 8/27/2020 1:53 AM, Chris M. Thomasson wrote: >> the dlls required) is just staggering. These guys really are programmming >> geniuses. > Indeed! Big time. Fwiw, check this out, a little experiment: https://youtu.be/P_lAP4IiYyE |
| boltar@nuttyella.co.uk: Aug 27 10:23AM On Thu, 27 Aug 2020 02:43:20 -0700 >> Indeed! Big time. >Fwiw, check this out, a little experiment: >https://youtu.be/P_lAP4IiYyE Not really in the same league tbh :) |
| Juha Nieminen <nospam@thanks.invalid>: Aug 27 04:15PM > You're going to have to do better than that. I've seen similar stuff in the > 90s assembly demo scene runing on 486s and less. Heres the 93 winner: > https://www.youtube.com/watch?v=rFv7mHTf0nA Running at 320x200 resolution, 256 colors. Let's see the same 486 run the same effects in 1920x1080 32-bit color, 60 Hz. Of course you can run almost anything if you lower the resolution and color depth enough, use untextured polygons, and so on. |
| 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