Monday, August 2, 2021

Digest for comp.lang.c++@googlegroups.com - 10 updates in 2 topics

Bonita Montero <Bonita.Montero@gmail.com>: Jul 28 04:05AM +0200

Am 27.07.2021 um 21:59 schrieb Lynn McGuire:
> 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.
 
Cholo Lennon <chololennon@hotmail.com>: Jul 27 09:01PM -0300

On 7/27/21 5:48 PM, Siri Cruise wrote:
 
>> Because it just works ?
 
> Because too many people still think garbage collection is
> inefficient, and they can do better.
 
It's not just what people think, there are a lot scenarios where garbage
collection is not a problem. I worked many years in the telecom industry
using C++ and Java... when the hardware got cheap and powerful, we
started to move a lot of services, protocol stacks, applications and
code base to Java. Why? Because the development and maintenance over
several platforms (Windows 32/64 bits, Solaris Intel/Sparc, Linux
32/64/RHEL 4-8) was ways more simple. How about the performance? Not a
problem, our application servers were still able to deal with thousands
of transactions per second without burning the CPUs. Of course, C++ was
still used, for legacy applications, or for low level layers in some,
not all, protocol stacks.
 
Regards
 
--
Cholo Lennon
Bs.As.
ARG
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jul 27 02:23PM -0700

>> eternally broken finalisers.
 
> But C++ doesn't have finalisers. That's a feature of GC languages.
 
> Did you mean C#?
 
C++ has destructors. I suspect that's what Siri Cruise was referring to.
 
Saying that garbage collection is a substitute for destructors suggests
that memory is the only resource that needs to be managed.
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
Siri Cruise <chine.bleu@yahoo.com>: Jul 28 07:53AM -0700

> > 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?
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed
Vir Campestris <vir.campestris@invalid.invalid>: Jul 27 10:05PM +0100

On 27/07/2021 21:48, Siri Cruise wrote:
 
> Object oriented programming and closures without mark/sweep
> collection is a bloody pain in the nethers. Hence C++ and its
> eternally broken finalisers.
 
But C++ doesn't have finalisers. That's a feature of GC languages.
 
Did you mean C#?
 
Andy
Siri Cruise <chine.bleu@yahoo.com>: Jul 28 02:16PM -0700

In article <sdsaru$emf$1@dont-email.me>,
> >>> every conditional jump was equally slow regardless of anything.
 
> > So C++ but no OOP?
 
> Multi-paradigm. :)
 
My sql interface returns effectively arrays of unions. I also
have no deallocation interface. I do have explicit begin/end
because sql tables really need to have transactions ended or
aborted in a clear and definite manner.
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed
Juha Nieminen <nospam@thanks.invalid>: Aug 02 10:23AM

> 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.)
MrSpud_rLY23@_h_.co.uk: Aug 02 03:05PM

On Mon, 2 Aug 2021 10:23:27 -0000 (UTC)
>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.
Bonita Montero <Bonita.Montero@gmail.com>: Jul 27 03:58AM +0200

Am 11.06.2021 um 05:03 schrieb Lynn McGuire:
 
> I found "C++ Concurrency in Action, 2nd Edition" by Williams, Anthony.
> Has anyone read this and found it to be a good education on threads ?
 
> https://www.amazon.com/C-Concurrency-Action-Anthony-Williams/dp/1617294691/
 
Google for: "c++ concurrency in action doctype:pdf"
And you find the PDF of the 1st ed.
legalize+jeeves@mail.xmission.com (Richard): Jul 27 01:21AM

[Please do not mail me a copy of your followup]
 
Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code
 
>>> https://www.amazon.com/C-Concurrency-Action-Anthony-Williams/dp/1617294691/
 
>> I used to converse with Anthony way back. He knows his threads! :^)
 
>I bought the book. It looks intense. Not a very big font either.
 
It's organized in such a way that you can dig as deep (or as shallow)
as you like and still come away with a good understanding of what you
need to know. All my opinion, of course.
 
Anthony Williams is one of the primary authors of Boost.Threads, from
which we got std::thread. He also participates heavily in the ISO
standards process. It is *the* go to book for C++ multithreading and
concurrency.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
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: