Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #80744 > unrolled thread

"Nearly a quarter-century later, why is C++ still so popular?"

Back to article view | Back to comp.lang.c++

Contents

  "Nearly a quarter-century later, why is C++ still so popular?" Lynn McGuire <lynnmcguire5@gmail.com> - 2021-07-27 14:59 -0500
    Re: "Nearly a quarter-century later, why is C++ still so popular?" Siri Cruise <chine.bleu@yahoo.com> - 2021-07-27 13:48 -0700
      Re: "Nearly a quarter-century later, why is C++ still so popular?" Vir Campestris <vir.campestris@invalid.invalid> - 2021-07-27 22:05 +0100
        Re: "Nearly a quarter-century later, why is C++ still so popular?" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-07-27 14:23 -0700
          Re: "Nearly a quarter-century later, why is C++ still so popular?" legalize+jeeves@mail.xmission.com (Richard) - 2021-08-05 19:49 +0000
            Re: "Nearly a quarter-century later, why is C++ still so popular?" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-08-19 20:08 +0000
              Re: "Nearly a quarter-century later, why is C++ still so popular?" Siri Cruise <chine.bleu@yahoo.com> - 2021-08-19 18:20 -0700
                Re: "Nearly a quarter-century later, why is C++ still so popular?" Juha Nieminen <nospam@thanks.invalid> - 2021-08-20 06:13 +0000
                Re: "Nearly a quarter-century later, why is C++ still so popular?" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-08-20 06:17 +0000
                  Re: "Nearly a quarter-century later, why is C++ still so popular?" Siri Cruise <chine.bleu@yahoo.com> - 2021-08-20 00:03 -0700
                    Re: "Nearly a quarter-century later, why is C++ still so popular?" Juha Nieminen <nospam@thanks.invalid> - 2021-08-20 11:03 +0000
                      Re: "Nearly a quarter-century later, why is C++ still so popular?" mickspud@downthefarm.com - 2021-08-20 15:19 +0000
                Re: "Nearly a quarter-century later, why is C++ still so popular?" "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-08-20 14:26 +0200
                  Re: "Nearly a quarter-century later, why is C++ still so popular?" Öö Tiib <ootiib@hot.ee> - 2021-08-29 23:40 -0700
      Re: "Nearly a quarter-century later, why is C++ still so popular?" Cholo Lennon <chololennon@hotmail.com> - 2021-07-27 21:01 -0300
      Re: "Nearly a quarter-century later, why is C++ still so popular?" Juha Nieminen <nospam@thanks.invalid> - 2021-07-28 08:16 +0000
        Re: "Nearly a quarter-century later, why is C++ still so popular?" "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-07-28 16:22 +0200
          Re: "Nearly a quarter-century later, why is C++ still so popular?" Siri Cruise <chine.bleu@yahoo.com> - 2021-07-28 07:53 -0700
            Re: "Nearly a quarter-century later, why is C++ still so popular?" "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2021-07-28 21:23 +0200
              Re: "Nearly a quarter-century later, why is C++ still so popular?" Siri Cruise <chine.bleu@yahoo.com> - 2021-07-28 14:16 -0700
            Re: "Nearly a quarter-century later, why is C++ still so popular?" Juha Nieminen <nospam@thanks.invalid> - 2021-07-29 06:53 +0000
              Re: "Nearly a quarter-century later, why is C++ still so popular?" Öö Tiib <ootiib@hot.ee> - 2021-07-29 09:31 -0700
                Re: "Nearly a quarter-century later, why is C++ still so popular?" MrSpud_71i5@slwgrcbmd1l7yi1.org - 2021-07-30 11:21 +0000
                Re: "Nearly a quarter-century later, why is C++ still so popular?" Juha Nieminen <nospam@thanks.invalid> - 2021-08-01 08:28 +0000
                  Re: "Nearly a quarter-century later, why is C++ still so popular?" Öö Tiib <ootiib@hot.ee> - 2021-08-01 05:49 -0700
                    Re: "Nearly a quarter-century later, why is C++ still so popular?" Juha Nieminen <nospam@thanks.invalid> - 2021-08-02 10:23 +0000
                      Re: "Nearly a quarter-century later, why is C++ still so popular?" MrSpud_rLY23@_h_.co.uk - 2021-08-02 15:05 +0000
                      Re: "Nearly a quarter-century later, why is C++ still so popular?" Öö Tiib <ootiib@hot.ee> - 2021-08-03 04:57 -0700
                        Re: "Nearly a quarter-century later, why is C++ still so popular?" Juha Nieminen <nospam@thanks.invalid> - 2021-08-03 12:16 +0000
                          Re: "Nearly a quarter-century later, why is C++ still so popular?" Öö Tiib <ootiib@hot.ee> - 2021-08-03 06:01 -0700
                            Re: "Nearly a quarter-century later, why is C++ still so popular?" Ian Collins <ian-news@hotmail.com> - 2021-08-08 13:03 +1200
                              Re: "Nearly a quarter-century later, why is C++ still so popular?" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-07 22:43 -0700
              Re: "Nearly a quarter-century later, why is C++ still so popular?" Vir Campestris <vir.campestris@invalid.invalid> - 2021-08-01 21:40 +0100
            Re: "Nearly a quarter-century later, why is C++ still so popular?" Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2021-07-29 09:53 +0100
            Re: "Nearly a quarter-century later, why is C++ still so popular?" Manfred <noname@add.invalid> - 2021-07-30 13:51 +0200
        Re: "Nearly a quarter-century later, why is C++ still so popular?" Manfred <noname@add.invalid> - 2021-07-30 13:40 +0200
    Re: "Nearly a quarter-century later, why is C++ still so popular?" Bonita Montero <Bonita.Montero@gmail.com> - 2021-07-28 04:05 +0200
      Re: "Nearly a quarter-century later, why is C++ still so popular?" MrSpud_oyam9ltRb0@khlkg.info - 2021-07-28 09:30 +0000
    Re: "Nearly a quarter-century later, why is C++ still so popular?" Bo Persson <bo@bo-persson.se> - 2021-07-28 08:19 +0200
    Re: "Nearly a quarter-century later, why is C++ still so popular?" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-08-03 13:10 -0700
      Re: "Nearly a quarter-century later, why is C++ still so popular?" Lynn McGuire <lynnmcguire5@gmail.com> - 2021-08-03 18:37 -0500
        Re: "Nearly a quarter-century later, why is C++ still so popular?" Cholo Lennon <chololennon@hotmail.com> - 2021-08-05 18:17 -0300
    Re:"Nearly a quarter-century later, why is C++ still so popular?" Blue Hat <blue_hat@hackershaven.com.jm> - 2021-08-08 13:33 -0500

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#80757

Siri Cruise <chine.bleu@yahoo.com> wrote:
>> On 28 Jul 2021 10:16, Juha Nieminen wrote:
> 
>> > In the 1980's and largely the 1990's, when OOP was the absolute king,
>> > dynamically allocating tons of individual objects wasn't really such a
>> > huge problem. CPUs didn't care how you were accessing memory, or how
>> > the execution flow of the program jumped around. Each memory access was
>> > equally slow regardless of which memory address you were using, and
>> > every conditional jump was equally slow regardless of anything.
> 
> So C++ but no OOP?

I suppose it depends a bit on your definition of "object-oriented
programming".

In the most traditional sense OOP means that your program has been
structured into classes and sub-classes, in other words, inheritance
hierarchies, and most often this involves dynamic binding (ie. virtual
functions). The abstraction that such an inheritance hierarchy
introduces implies that much of the code handles base class type
references/pointers, which point to dynamically allocated objects,
and which member function implementations are done with virtual
functions implemented in the derived classes.

Most GUI libraries implement very traditional OOP inheritance
hierarchies (I often like to say that it's almost as if OOP was
created precisely for GUI programming, because it's the most
prominent and perfect example.)

Of course, as it turns out, this paradigm is inefficient in modern CPUs
(because of caches, pipelines, predictive branching, etc.) The CPU
doesn't really like objects that are randomly placed in memory, thus
with data being accessed from random memory locations. It also doesn't
like branches it cannot predict. Or branching at all, especially
indirect branching. (Also, compilers have a hard time optimizing
code full of true function calls, because they can't see what the
function is doing, and it hinders things like autovectorization.)

Of course in C++ in particular there's a slightly better alternative
to this, which is to handle objects by value rather than by pointer.
This allows, for example, to put objects into arrays (ie. the arrays
don't just contain pointers to objects, but the objects themselves).
This isn't yet completely optimal, but it's a step in the right
direction.

Of course if you want to handle objects by value, you need to restrict
your object-oriented design. The pointer-to-base-object-handles-derived-
object becomes limited, and the use of virtual functions becomes more
limited.

You still can have inheritance, and a full inheritance hierarchy,
which makes it OOP-like, but there are some limitations.

(But, data-oriented design needs more than just being able to handle
objects by value. The problem with handling arrays of objects is that
the member variables you are interested in will be spaced out,
sometimes by more than the cache line size, which makes it almost
useless in terms of cache optimization.)

[toc] | [prev] | [next] | [standalone]

#80759

On Thursday, 29 July 2021 at 09:54:13 UTC+3, Juha Nieminen wrote:
> 
> Of course, as it turns out, this paradigm is inefficient in modern CPUs 
> (because of caches, pipelines, predictive branching, etc.) The CPU 
> doesn't really like objects that are randomly placed in memory, thus 
> with data being accessed from random memory locations. It also doesn't 
> like branches it cannot predict. Or branching at all, especially 
> indirect branching. (Also, compilers have a hard time optimizing 
> code full of true function calls, because they can't see what the 
> function is doing, and it hinders things like autovectorization.) 

When it matters to performance then there are presumably
large containers of such objects? The boost::base_collection can help
there as instead of allocating each object dynamically in random memory
locations it keeps those in subcontainers by value. 

[toc] | [prev] | [next] | [standalone]

#80760

On Thu, 29 Jul 2021 09:31:33 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
>On Thursday, 29 July 2021 at 09:54:13 UTC+3, Juha Nieminen wrote:
>> 
>> Of course, as it turns out, this paradigm is inefficient in modern CPUs 
>> (because of caches, pipelines, predictive branching, etc.) The CPU 
>> doesn't really like objects that are randomly placed in memory, thus 
>> with data being accessed from random memory locations. It also doesn't 
>> like branches it cannot predict. Or branching at all, especially 
>> indirect branching. (Also, compilers have a hard time optimizing 
>> code full of true function calls, because they can't see what the 
>> function is doing, and it hinders things like autovectorization.) 
>
>When it matters to performance then there are presumably
>large containers of such objects? The boost::base_collection can help
>there as instead of allocating each object dynamically in random memory
>locations it keeps those in subcontainers by value. 

And where do these subcontainers allocate their memory from? The magic woo woo
heap in special moonbeam memory?

[toc] | [prev] | [next] | [standalone]

#80764

?? Tiib <ootiib@hot.ee> wrote:
> On Thursday, 29 July 2021 at 09:54:13 UTC+3, Juha Nieminen wrote:
>> 
>> Of course, as it turns out, this paradigm is inefficient in modern CPUs 
>> (because of caches, pipelines, predictive branching, etc.) The CPU 
>> doesn't really like objects that are randomly placed in memory, thus 
>> with data being accessed from random memory locations. It also doesn't 
>> like branches it cannot predict. Or branching at all, especially 
>> indirect branching. (Also, compilers have a hard time optimizing 
>> code full of true function calls, because they can't see what the 
>> function is doing, and it hinders things like autovectorization.) 
> 
> When it matters to performance then there are presumably
> large containers of such objects? The boost::base_collection can help
> there as instead of allocating each object dynamically in random memory
> locations it keeps those in subcontainers by value. 

As mentioned earlier, that's a step in the right direction, but it doesn't
achieve optimal performance (with the possible exception of very small
objects whose every data member is accessed during the same iterative
process).

The reason why putting objects by value into arrays is better but not
optimal is because most often, for a given operation that you want
to perform on each object, you are only interested in one (or a few)
of their member variables. Quite often the objects will also contain
other members variables, which will cause the ones you are interested
in to be spaced out in the array, with big gaps.

So, even if you are traversing the array linearly from beginning to
end, you will be making jumps of the size of these gaps, which is
not optimal for cache locality. The number of cache misses will be
larger than if the data you are interested in was stored exclusively,
without any gaps.

This is one the unfortunate drawbacks of the otherwise brilliant idea
of modularity and object-oriented design: It groups related values into
the same class, which is nice designwise, but suboptimal for performance
because quite often you aren't handling *all* of these member values,
only certain ones, so you'll be jumping in larger steps than necessary.

Things like game engines and number-crunching applications want to
squeeze out every single clock cycle they can, so this design is not
good for them. They need a completely different approach from the
traditional class design.

[toc] | [prev] | [next] | [standalone]

#80765

On Sunday, 1 August 2021 at 11:28:20 UTC+3, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote: 
> > On Thursday, 29 July 2021 at 09:54:13 UTC+3, Juha Nieminen wrote: 
> >> 
> >> Of course, as it turns out, this paradigm is inefficient in modern CPUs 
> >> (because of caches, pipelines, predictive branching, etc.) The CPU 
> >> doesn't really like objects that are randomly placed in memory, thus 
> >> with data being accessed from random memory locations. It also doesn't 
> >> like branches it cannot predict. Or branching at all, especially 
> >> indirect branching. (Also, compilers have a hard time optimizing 
> >> code full of true function calls, because they can't see what the 
> >> function is doing, and it hinders things like autovectorization.) 
> > 
> > When it matters to performance then there are presumably 
> > large containers of such objects? The boost::base_collection can help 
> > there as instead of allocating each object dynamically in random memory 
> > locations it keeps those in subcontainers by value.
> 
> As mentioned earlier, that's a step in the right direction, but it doesn't 
> achieve optimal performance (with the possible exception of very small 
> objects whose every data member is accessed during the same iterative 
> process). 
> 
> The reason why putting objects by value into arrays is better but not 
> optimal is because most often, for a given operation that you want 
> to perform on each object, you are only interested in one (or a few) 
> of their member variables. Quite often the objects will also contain 
> other members variables, which will cause the ones you are interested 
> in to be spaced out in the array, with big gaps. 
> 
> So, even if you are traversing the array linearly from beginning to 
> end, you will be making jumps of the size of these gaps, which is 
> not optimal for cache locality. The number of cache misses will be 
> larger than if the data you are interested in was stored exclusively, 
> without any gaps. 

The example must be always concrete as on general case there are
no optimal solutions. "Optimal" is always situational term and so no
such thing that is  optimal for everything is possible. 

The performance issues can never be decided even to exist without
profiling real data in real situations. When we profile then only small
fraction of code lines are executed vast majority of run-time and also
only small subset of types are those that instantiate vast majority of
run-time objects. 

For vast majority of code nice modular and object-oriented design
has no meaningful drawbacks in overall product performance.
So that is one thing that makes C++ powerful. We can use nice
and flexible design most of the time without worrying.

> This is one the unfortunate drawbacks of the otherwise brilliant idea 
> of modularity and object-oriented design: It groups related values into 
> the same class, which is nice designwise, but suboptimal for performance 
> because quite often you aren't handling *all* of these member values, 
> only certain ones, so you'll be jumping in larger steps than necessary. 

With that small performance-critical subset we can do in C++  whatever
performance tuning tricks are needed for the concrete situations. That
is other thing that makes C++ powerful. It is often possible to get several
times better overall performance by optimizing only small subset of code.

> Things like game engines and number-crunching applications want to 
> squeeze out every single clock cycle they can, so this design is not 
> good for them. They need a completely different approach from the 
> traditional class design.

Indeed but I lack imagination how even to use that traditional class
design within some concrete number crunching example. Can you
bring any example? Linear algebra subroutines?  Fourier transform?
Sparse matrices?  Graph analytics? Compression/decompression?
The number crunching is usually quite abstract, specific and 
constrained, not fit to process our arbitrary anything-goes data in
our OOP hierarchies and also it is often ran in GPU. So we need
translation layer that transforms data in our hierarchy for processing
and back anyway.

[toc] | [prev] | [next] | [standalone]

#80767

Öö Tiib <ootiib@hot.ee> wrote:
> Indeed but I lack imagination how even to use that traditional class
> design within some concrete number crunching example.

Suppose you are handling large triangle meshes where each vertex has quite
a lot of data. Rather obviously you have the vertex 3D position, but you
may also have texture UV coordinates for that vertex, a normal vector at
that vertex, its color, its brightness, and any other number of values that
may be needed for rendering the triangle mesh.

It would be a nice design to create a vertex class (or perhaps struct)
where every one of those types of data related to a verted has been
collected. So it could look something like:

class Vertex
{
    float position[3];
    float uv_coords[2];
    float environment_map_coords[2];
    float normal_vector[3];
    unsigned char color_rgba[4];

 public:
    // ...
};

That's really nice designwise. Not so nice in terms of performance.
Most often you want to do some operation to all vertices, and this
operation only cares about one or two of those member variables and
doesn't need the rest.

For example, suppose you want to transform the mesh in some manner,
by modifying its position values. Even if all the Vertex objects are
in an array, and even if you traverse the array linearly, you will
be jumping in large steps from one Vertex to the next, most probably
having a cache miss every time.

If, instead, you had an array that only contains the position coordinates
of all the vertices and nothing more, it will be much more compact, and
traversing it from beginning to end will cause significantly less
cache misses.

Or suppose you wanted to do some operations to the color of each vertex.
Again, you would be jumping in large steps from one Vertex object to
the next. If all the colors were exclusively in an array, then they
would be packed as compactly as possible, and a linear traversal would
thus be much more efficient.

(This is the idea with Data Oriented Design.)

[toc] | [prev] | [next] | [standalone]

#80768

On Mon, 2 Aug 2021 10:23:27 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>Or suppose you wanted to do some operations to the color of each vertex.
>Again, you would be jumping in large steps from one Vertex object to
>the next. If all the colors were exclusively in an array, then they
>would be packed as compactly as possible, and a linear traversal would
>thus be much more efficient.
>
>(This is the idea with Data Oriented Design.)

Which is just a trendy name for the way code used to be written before 
structured then OO design came along.

[toc] | [prev] | [next] | [standalone]

#80769

On Monday, 2 August 2021 at 13:23:45 UTC+3, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote: 
> > Indeed but I lack imagination how even to use that traditional class 
> > design within some concrete number crunching example.
> Suppose you are handling large triangle meshes where each vertex has quite 
> a lot of data. Rather obviously you have the vertex 3D position, but you 
> may also have texture UV coordinates for that vertex, a normal vector at 
> that vertex, its color, its brightness, and any other number of values that 
> may be needed for rendering the triangle mesh. 
> 
> It would be a nice design to create a vertex class (or perhaps struct) 
> where every one of those types of data related to a verted has been 
> collected. So it could look something like: 
> 
> class Vertex 
> { 
> float position[3]; 
> float uv_coords[2]; 
> float environment_map_coords[2]; 
> float normal_vector[3]; 
> unsigned char color_rgba[4]; 
> 
> public: 
> // ... 
> }; 
> 
> That's really nice designwise. Not so nice in terms of performance. 
> Most often you want to do some operation to all vertices, and this 
> operation only cares about one or two of those member variables and 
> doesn't need the rest. 

It is example of what I wrote that: 
"The number crunching is usually quite abstract, specific and
constrained, not fit to process our arbitrary anything-goes data in
our OOP hierarchies and also it is often ran in GPU."

Feels rather unlikely that we want to do anything with such Vertex instance
in separation. Instead we want those to be processed (in massive
amounts) by some rendering engine (like OpenGL). So we either have 
translation/generator functionality that produces those vertices in form
what engine needs or for simple static models can have engine primitives
directly in instance: 

class StaticModel {
    std::vector<glm::vec3> vertices;
    std::vector<glm::vec2> uvs;
    std::vector<glm::vec3> normals;
    // etc...
public:
    // etc...
};

> For example, suppose you want to transform the mesh in some manner, 
> by modifying its position values. Even if all the Vertex objects are 
> in an array, and even if you traverse the array linearly, you will 
> be jumping in large steps from one Vertex to the next, most probably 
> having a cache miss every time. 
> 
> If, instead, you had an array that only contains the position coordinates 
> of all the vertices and nothing more, it will be much more compact, and 
> traversing it from beginning to end will cause significantly less 
> cache misses. 

Majority of such per-vertex mass transformations are done by
rendering engine we just call a function. We can't pass our "nice" vertices
to engine anyway so the point is doubtful why to have those. OTOH when 
our model consists of higher level 3D primitives like moving cylinders,
cones and spheres then we change properties of those instead of tinkering
with each vertex. There OOP helps greatly.

[toc] | [prev] | [next] | [standalone]

#80770

?? Tiib <ootiib@hot.ee> wrote:
> Feels rather unlikely that we want to do anything with such Vertex instance
> in separation. Instead we want those to be processed (in massive
> amounts) by some rendering engine (like OpenGL).

I don't really understand why you have such a hard time imagining a situation
where something like that Vertex class would feel like a very convenient and
good design choice.

Not all programs that handle, for example, triangle meshes are doing so to
merely feed the data to OpenGL (or any other API). There may be myriads of
reasons why a program may want to handle triangle meshes in some manner,
and some of these applications may be something that benefit from extreme
speed (because they may need to do a lot of heavy operations to gigantic
triangle meshes).

It's very natural to think that since each vertex of the mesh has a lot
of data attached to it (such as its position, uv-coordinates, etc), to
group all this data into one class (or struct) for easy handling. After
all, if you need to, for example, copy a vertex, or remove a vertex,
or do many other types of operations to single vertex objects, it's
most convenient when the vertex is one single object.

Many operations become less convenient and more laborious, requiring
writing more code, when the data of the vertices has been split into
separate arrays.

But the thing is, if you want maximal efficiency, sometimes you need to
do some compromises regarding convenience and nice abstractions.

[toc] | [prev] | [next] | [standalone]

#80771

On Tuesday, 3 August 2021 at 15:17:10 UTC+3, Juha Nieminen wrote:
> Öö Tiib <oot...@hot.ee> wrote: 
> > Feels rather unlikely that we want to do anything with such Vertex instance 
> > in separation. Instead we want those to be processed (in massive 
> > amounts) by some rendering engine (like OpenGL).
> I don't really understand why you have such a hard time imagining a situation 
> where something like that Vertex class would feel like a very convenient and 
> good design choice. 
> 
> Not all programs that handle, for example, triangle meshes are doing so to 
> merely feed the data to OpenGL (or any other API). There may be myriads of 
> reasons why a program may want to handle triangle meshes in some manner, 
> and some of these applications may be something that benefit from extreme 
> speed (because they may need to do a lot of heavy operations to gigantic 
> triangle meshes). 

As rule we want to render those too. If for nothing else then for debugging.
Therefore if we really process 3D triangles directly then it is more convenient
to keep the data layout suitable for rendering API, even if we do part of
processing outside of that API as well. 

> It's very natural to think that since each vertex of the mesh has a lot 
> of data attached to it (such as its position, uv-coordinates, etc), to 
> group all this data into one class (or struct) for easy handling. After 
> all, if you need to, for example, copy a vertex, or remove a vertex, 
> or do many other types of operations to single vertex objects, it's 
> most convenient when the vertex is one single object. 
> 
> Many operations become less convenient and more laborious, requiring 
> writing more code, when the data of the vertices has been split into 
> separate arrays. 
> 
> But the thing is, if you want maximal efficiency, sometimes you need to 
> do some compromises regarding convenience and nice abstractions.

Yes, sometimes it can be inconvenient. It does not matter that I don't see
positive case with these vertices. I've seen it with other things. That all
is in conformance with what I wrote: "With that small performance-critical
subset we can do in C++ whatever performance tuning tricks are needed
for the concrete situations. That is other thing that makes C++ powerful.
It is often possible to get several times better overall performance by
optimizing only small subset of code." It does not mean that we need to
switch all our data into inconvenient to reason about format.

[toc] | [prev] | [next] | [standalone]

#80793

On 04/08/2021 01:01, Öö Tiib wrote:
> On Tuesday, 3 August 2021 at 15:17:10 UTC+3, Juha Nieminen wrote:
>> Öö Tiib <oot...@hot.ee> wrote:
>>> Feels rather unlikely that we want to do anything with such Vertex instance
>>> in separation. Instead we want those to be processed (in massive
>>> amounts) by some rendering engine (like OpenGL).
>> I don't really understand why you have such a hard time imagining a situation
>> where something like that Vertex class would feel like a very convenient and
>> good design choice.
>>
>> Not all programs that handle, for example, triangle meshes are doing so to
>> merely feed the data to OpenGL (or any other API). There may be myriads of
>> reasons why a program may want to handle triangle meshes in some manner,
>> and some of these applications may be something that benefit from extreme
>> speed (because they may need to do a lot of heavy operations to gigantic
>> triangle meshes).
> 
> As rule we want to render those too. If for nothing else then for debugging.
> Therefore if we really process 3D triangles directly then it is more convenient
> to keep the data layout suitable for rendering API, even if we do part of
> processing outside of that API as well.

Our application's positioning engine does not render the triangle meshes 
we use for mapping.  Its job is to work out where targets should be on a 
surface and to generate guidance lines on the map.  The rendering is 
done in using OpenGL on another device.

I'm sure this situation isn't uncommon.

--
Ian.

[toc] | [prev] | [next] | [standalone]

#80794

On 8/7/2021 6:03 PM, Ian Collins wrote:
> On 04/08/2021 01:01, Öö Tiib wrote:
>> On Tuesday, 3 August 2021 at 15:17:10 UTC+3, Juha Nieminen wrote:
>>> Öö Tiib <oot...@hot.ee> wrote:
>>>> Feels rather unlikely that we want to do anything with such Vertex 
>>>> instance
>>>> in separation. Instead we want those to be processed (in massive
>>>> amounts) by some rendering engine (like OpenGL).
>>> I don't really understand why you have such a hard time imagining a 
>>> situation
>>> where something like that Vertex class would feel like a very 
>>> convenient and
>>> good design choice.
>>>
>>> Not all programs that handle, for example, triangle meshes are doing 
>>> so to
>>> merely feed the data to OpenGL (or any other API). There may be 
>>> myriads of
>>> reasons why a program may want to handle triangle meshes in some manner,
>>> and some of these applications may be something that benefit from 
>>> extreme
>>> speed (because they may need to do a lot of heavy operations to gigantic
>>> triangle meshes).
>>
>> As rule we want to render those too. If for nothing else then for 
>> debugging.
>> Therefore if we really process 3D triangles directly then it is more 
>> convenient
>> to keep the data layout suitable for rendering API, even if we do part of
>> processing outside of that API as well.
> 
> Our application's positioning engine does not render the triangle meshes 
> we use for mapping.  Its job is to work out where targets should be on a 
> surface and to generate guidance lines on the map.  The rendering is 
> done in using OpenGL on another device.
> 
> I'm sure this situation isn't uncommon.

Not uncommon at all. Not sure if the following scenario is "comparable" 
or not, however... I have pure C++ that generates scenes for another 
application to render, PovRay. In this case, I did not implement a 
raytracer. Imvvho, PovRay is pretty fun to work with.

https://youtu.be/skGUAXAx6eg

Other times, I will implement a crude distance estimator for 3d work:

https://www.shadertoy.com/view/fdBSzm

[toc] | [prev] | [next] | [standalone]

#80766

On 29/07/2021 07:53, Juha Nieminen wrote:
> Of course in C++ in particular there's a slightly better alternative
> to this, which is to handle objects by value rather than by pointer.
> This allows, for example, to put objects into arrays (ie. the arrays
> don't just contain pointers to objects, but the objects themselves).
> This isn't yet completely optimal, but it's a step in the right
> direction.

My usual advice on collections is:

Use vector.
No, really use vector.
Are you sure you shouldn't use vector?

It's the right solution for most cases. One of the nice things is of 
course that vector represents an array of objects. Allocated all in a 
single block of contiguous memory.

Without needing pointer or references.

Yes, of course there are cases for using the other collections, but not 
as common in my experience.

Andy

[toc] | [prev] | [next] | [standalone]

#80758

On Wed, 28 Jul 2021 07:53:05 -0700
Siri Cruise <chine.bleu@yahoo.com> wrote:
> > On 28 Jul 2021 10:16, Juha Nieminen wrote:
> 
> > > In the 1980's and largely the 1990's, when OOP was the absolute king,
> > > dynamically allocating tons of individual objects wasn't really such a
> > > huge problem. CPUs didn't care how you were accessing memory, or how
> > > the execution flow of the program jumped around. Each memory access was
> > > equally slow regardless of which memory address you were using, and
> > > every conditional jump was equally slow regardless of anything.
> 
> So C++ but no OOP?

It's not just OOP which is the problem.  Move semantics are also an
issue, because the purpose of moving a rvalue, instead of copying it,
is to enable the internal implementation of the object to be transferred
into another object.  This usually involves allocating the parts of the
object to be transferred on free store so that pointers can be copied.

In cases where this is relevant, there is a contest between the
approaches of (i) moving internals which have been allocated on free
store, and (ii) copying internals which have been allocated on the
stack. In any given case, profiling is one way of determining which
approach is better.

[toc] | [prev] | [next] | [standalone]

#80762

On 7/28/2021 4:53 PM, Siri Cruise wrote:
>> On 28 Jul 2021 10:16, Juha Nieminen wrote:
> 
>>> In the 1980's and largely the 1990's, when OOP was the absolute king,
>>> dynamically allocating tons of individual objects wasn't really such a
>>> huge problem. CPUs didn't care how you were accessing memory, or how
>>> the execution flow of the program jumped around. Each memory access was
>>> equally slow regardless of which memory address you were using, and
>>> every conditional jump was equally slow regardless of anything.
> 
> So C++ but no OOP?
> 

I wouldn't rule out OOP entirely, but it is true that OOP has been 
overestimated in its early years.
It is not only a matter of efficiency and being hardware-friendly, it is 
also about the fact that OOP is well suited for some classes of 
problems, but not for others - Juha gave the good example of GUI 
programming, but there is an entire world outside that area.

For example, problems that are inherently procedural or algorithm 
oriented gain more trouble than benefit from an OOP model.

The strength of C++ is that it has lots to offer for several different 
programming paradigms beyond OOP.

[toc] | [prev] | [next] | [standalone]

#80761

On 7/28/2021 10:16 AM, Juha Nieminen wrote:
> Siri Cruise <chine.bleu@yahoo.com> wrote:
>> In article <sdpojb$aq7$2@dont-email.me>,
>>   Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>
>>> Because it just works ?
>>
>> Because too many people still think garbage collection is
>> inefficient
> 
> Because it is.
> 
> Or, more precisely, perhaps GC *in itself* is not inefficient, but the
> paradigm it's solving has turned out to be.
> 
> You see, garbage collection arose primarily from a practical problem in
> object-oriented programming, and that problem is: When you dynamically
> allocate tons and tons of individual objects, and they refer to each
> other in a complicated mesh of references, how do you keep track of all
> of this so that each object is properly destroyed once nothing refers to
> it, and do it in a manner that's as easy for the programmer as possible,
> as efficient and possible, and allows for circular dependencies without
> causing leaks?
> 
> Thus, an incredible amount of academic and practical research work was
> put into garbage collection algorithms and implementations that were as
> efficient as possible.
> 
> Problem is, it's an efficient solution for a fundamentally inefficient
> programming paradigm. It's a solution to something you actually shouldn't
> be doing in the first place, in a modern computer system. What is this
> thing you shouldn't be doing, you might ask?
> 
> Dynamically allocating tons and tons of individual objects. That's what.
> 
> In the 1980's and largely the 1990's, when OOP was the absolute king,
> dynamically allocating tons of individual objects wasn't really such a
> huge problem. CPUs didn't care how you were accessing memory, or how
> the execution flow of the program jumped around. Each memory access was
> equally slow regardless of which memory address you were using, and
> every conditional jump was equally slow regardless of anything.
> 
> No longer.
> 
> CPUs started introducing memory caches, long instruction pipelines,
> predictive branching, and a bunch of other optimizations which
> suddenly started caring about how you access memory and how you do
> your conditional jumps.
> 
> It has turned out that one of the greatest programming paradigms that has
> ever existed, object-oriented programming, is also a performance killer
> in modern CPUs. This is because OOP, at least the traditional approach
> to it, is extremely cache-unfriendly, predictive-branching-unfriendly,
> and pipeline-unfriendly, and thus tends to produce inefficient
> executables.
> 
> For this reason for quite some time now many of the major projects out
> there that require extreme performance, such as game engines, have
> started moving away from an OOP design to a more data-oriented design
> which optimizes for modern CPU architectures much better than OOP does.
> 
> And the thing about data-oriented design is that it so happens that it
> doesn't benefit nor rely so much on a garbage collector, because you
> are trying to avoid random dynamic memory allocations in the first
> place (and prefer all data to be neatly in large arrays).
> 
> So yes, perhaps garbage collection *in itself* is not inefficient, but it's
> fundamentally tied to a programming paradigm that is, and moving away from
> that paradigm also lessens the need for GC.
> 

Good points, agreed.

[toc] | [prev] | [next] | [standalone]

#80749

Am 27.07.2021 um 21:59 schrieb Lynn McGuire:
> "Nearly a quarter-century later, why is C++ still so popular?"
> 
> https://sdtimes.com/softwaredev/nearly-a-quarter-century-later-why-is-c-still-so-popular/ 
> 
> 
> "Despite C++’s downward trend on the TIOBE Programming Community index 
> since 2001, the language’s fall from the coveted top two slots in 2020, 
> vociferous and persistent claims that C++ is “dead like COBOL,” and the 
> inroads the Rust is making in developer circles – C++ is still as 
> viable, vital and relevant as ever."
> 
> Because it just works ?

Because its magnitudes more productive and maintainable than C
with the same performance.

> 
> And I am not impressed with Rust whatsoever.
> 
> Lynn

[toc] | [prev] | [next] | [standalone]

#80752

On Wed, 28 Jul 2021 04:05:08 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 27.07.2021 um 21:59 schrieb Lynn McGuire:
>> "Nearly a quarter-century later, why is C++ still so popular?"
>> 
>>
>https://sdtimes.com/softwaredev/nearly-a-quarter-century-later-why-is-c-still-s
>o-popular/ 
>> 
>> 
>> "Despite C++’s downward trend on the TIOBE Programming Community index 
>> since 2001, the language’s fall from the coveted top two slots in 2020, 
>> vociferous and persistent claims that C++ is “dead like COBOL,” and the 
>> inroads the Rust is making in developer circles – C++ is still as 
>> viable, vital and relevant as ever."
>> 
>> Because it just works ?
>
>Because its magnitudes more productive and maintainable than C
>with the same performance.

That depends who wrote it. Unfortunately a lot of C++ I see seems to be a load
of syntax circle jerking with pointless features being thrown into the code
that bring nothing to the table and simply obfuscate the code path simply 
because the dev wanted to try them out. Eg recently I saw co-routines used 
completely inappropriately when standard class methods and private variables 
would have done the job far better and simpler.

[toc] | [prev] | [next] | [standalone]

#80750

On 2021-07-27 at 21:59, Lynn McGuire wrote:
> "Nearly a quarter-century later, why is C++ still so popular?"
> 
> https://sdtimes.com/softwaredev/nearly-a-quarter-century-later-why-is-c-still-so-popular/ 
> 
> 
> "Despite C++’s downward trend on the TIOBE Programming Community index 
> since 2001, the language’s fall from the coveted top two slots in 2020, 
> vociferous and persistent claims that C++ is “dead like COBOL,” and the 
> inroads the Rust is making in developer circles – C++ is still as 
> viable, vital and relevant as ever."
> 
> Because it just works ?
> 
> And I am not impressed with Rust whatsoever.
> 
> Lynn

Here "dead like COBOL" could mean "used a lot, but after 25+ years the 
developers don't need to ask lots of questions on the internet".

So doesn't show up on TIOBE.

[toc] | [prev] | [next] | [standalone]

#80772

On 7/27/2021 12:59 PM, Lynn McGuire wrote:
> "Nearly a quarter-century later, why is C++ still so popular?"
> 
> https://sdtimes.com/softwaredev/nearly-a-quarter-century-later-why-is-c-still-so-popular/ 
> 
> 
> "Despite C++’s downward trend on the TIOBE Programming Community index 
> since 2001, the language’s fall from the coveted top two slots in 2020, 
> vociferous and persistent claims that C++ is “dead like COBOL,” and the 
> inroads the Rust is making in developer circles – C++ is still as 
> viable, vital and relevant as ever."
> 
> Because it just works ?
> 
> And I am not impressed with Rust whatsoever.
> 

Never used Rust, humm. Perhaps I will give it a go, maybe start with 
some online compilers:

https://play.rust-lang.org

Humm, it should be fun for me to try to port some of my existing 
programs into Rust.

C++ is an excellent language that can be used to create many awesome 
things. Want to write a low level subsystem, or a runtime for your own 
language, C++ is there. Want to create really fast low level server 
code, C++ is there. Are you looking for low level, fairly fine grain 
access to std threads and atomics/membars, C++ is there!

C++ is there for a lot of things. Want to create an OS? C++ can come in 
handy. Keep in mind that nobody has to use all of the "fancy" features. 
Wrt the OS case, one can use "just" enough C++ to get the job done.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web