Tuesday, August 3, 2021

Digest for comp.lang.c++@googlegroups.com - 6 updates in 3 topics

Real Troll <real.troll@trolls.com>: Aug 03 11:25PM +0100

On 03/08/2021 23:07, Jason Evans wrote:
 
> I know. That group is pretty much defunct. One of my goals this week is to
> try to get a hold of the most recent moderators and see what the status is.
 
> Jason
 
Can you please also look into these two moderated newsgroups:
 
comp.lang.c++.moderated
comp.lang.c.moderated
 
If necessary we should have two new moderators and I recommend two guys
who are quite experienced in C and C++. They are:
 
Keith Thompson <Keith.S.Thompson+u@gmail.com>
James Kuyper <jameskuyper@alumni.caltech.edu>
 
Both of then are very active in " comp.lang.c " and " comp.lang.c++ "
and they can be contacted on those newsgroups.
 
Of course, I don't have the their authority to put their name forward
but if an election is necessary then it should be conducted by C and C++
users only. Jason, you can be the returning officer for all this.
 
Kind regards,
 
PS: I have cross posted this to the two newsgroups of relevance here.
"Öö Tiib" <ootiib@hot.ee>: Aug 03 04:57AM -0700

On Monday, 2 August 2021 at 13:23:45 UTC+3, Juha Nieminen wrote:
> 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...
};
 
> 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.
Juha Nieminen <nospam@thanks.invalid>: Aug 03 12:16PM

> 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.
"Öö Tiib" <ootiib@hot.ee>: Aug 03 06:01AM -0700

On Tuesday, 3 August 2021 at 15:17:10 UTC+3, Juha Nieminen wrote:
> 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.
 
> 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.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 03 01:10PM -0700

On 7/27/2021 12:59 PM, Lynn McGuire wrote:
> 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.
legalize+jeeves@mail.xmission.com (Richard): Jul 27 01:19AM

[Please do not mail me a copy of your followup]
 
Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code
 
>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/
 
I have read this and it's what I was going to recommend :)
--
"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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)