Monday, April 23, 2018

Digest for comp.lang.c++@googlegroups.com - 13 updates in 8 topics

Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 23 08:32PM

On Mon, 2018-04-23, Lynn McGuire wrote:
 
>>> Interesting only if C++ can generate faster code.
 
>> Why? Fast code is important, but it's not the only characteristic of
>> a language.
...
 
> Because I want to convert my calculation engine from F77 to C++. I need
> all the speed that I can get as we are still computationally intensive
> and threading our calculation engine is a no-go.
 
So you mean "interesting to me only if it means future C++ code will
be able to beat Fortran for certain use cases"? Fair enough, I
suppose.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 23 10:57PM


> So you mean "interesting to me only if it means future C++ code will
> be able to beat Fortran for certain use cases"? Fair enough, I
> suppose.
 
Question is why he wants to convert calculation engine to C++...
 
 
--
press any key to continue or any other to quit...
Paavo Helde <myfirstname@osa.pri.ee>: Apr 24 12:12AM +0300

> are the only standard containers for which that is true - std::vector<>
> has no such requirement. Even for a contiguous container such as std::basic_string<>, you need to use addressof(), not &, to obtain a
> pointer value for which the requirements of 27.2.1p6 apply.
 
23.3.6.1p2: A vector satisfies [...] requirements [...] for an element
type other than bool, of a contiguous container (23.2.1).
 
For type char, addressof() is the same as &.
 
I agree that &s[0] is a bit ugly, but it did work in all known
implementations AFAIK even before C++11 officially forced the strings to
use contiguous storage.
 
For vector there is the non-const data() overload, which was missing for
some reason for string. This was probably an oversight as in C++17 the
non-const data() is added also to strings:
http://en.cppreference.com/w/cpp/string/basic_string/data
 
So in the future one can just use s.data() instead of &s[0].
legalize+jeeves@mail.xmission.com (Richard): Apr 23 09:41PM

[Please do not mail me a copy of your followup]
 
"The elements of a basic_string are stored contiguously, that is,
for a basic_string s, &*(s.begin() + n) == &*s.begin() + n for any n
in [0, s.size()), or, equivalently, a pointer to s[0] can be passed
to functions that expect a pointer to the first element of a CharT[]
array. (since C++11)"
 
So, guaranteed since C++11, but in practice was always true before
that. If you were really paranoid, e.g. because you needed a
variable-length buffer to be passed to a C-style function, then you
used std::vector<char>, as I have done in the past, and possibly
copied to/from std::string from there. If the copy was unacceptable,
then you brew your own string type as is typical of code bases where
high-performance string processing was normal, e.g. clang/llvm.
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Apr 23 09:42PM

[Please do not mail me a copy of your followup]
 
(Richard) legalize+jeeves@mail.xmission.com spake the secret code
> in [0, s.size()), or, equivalently, a pointer to s[0] can be passed
> to functions that expect a pointer to the first element of a CharT[]
> array. (since C++11)"
 
Oops, forgot the url, but you probably guessed where it was from
<http://en.cppreference.com/w/cpp/string/basic_string>
--
"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>
Tim Rentsch <txr@alumni.caltech.edu>: Apr 23 01:12PM -0700

> given.
 
> The question is:
> a) is this code valid (should this code compile)?
 
Not counting the two extraneous semicolons and the question
regarding converting a pointer-to-function to a (void *), the
code is valid. That is, a C++ compiler must accept it as a
single translation unit.
 
Beyond that, I am not sure. Please read on.
 
> diagnostics required?
> My reasoning goes this way:
> Main question: Are f1, f2, f3 ODR used?
 
That is indeed the key question. If they are ODR-used, and not
defined, then there is undefined behavior and all bets are off.
 
If they are not ODR-used, then it's a question about templates
that is beyond my current level of understanding.
 
I looked briefly (ie, at the C++ standard) to see if I could
figure out whether these functions are ODR-used. About the
only conclusion I reached is that finding out would take
longer than I wanted to spend. :(
 
> If yes, the code sould not compile.
 
As a single TU, it /should/ compile. The functions may be
defined in another translation unit.
 
As a whole program, compiling is allowed because of the undefined
behavior that results from not defining an identifier that is
ODR-used.
 
> If not, fid instances are different objects, so they should
> have different addresses.
 
I believe that's right. I'm not sure of the exact rules for
template instantiation but that's what I would expect in the
absence of information to the contrary. Also I'm not sure if
the presence of 'inline' in the definition of fid() might
influence that. As it compiles without 'inline', I might be
inclined to leave it off.
Tim Rentsch <txr@alumni.caltech.edu>: Apr 23 01:17PM -0700


> Note 1: "%p" requires a void* argument. On many systems, all pointers
> are interchangeable, so it doesn't matter, but the C++ standard
> doesn't require this.
 
Do you think the argument value is not of type (void*)? Did you
miss the () after the template invocation?
 
>> Main question: Are f1, f2, f3 ODR used?
>> If yes, the code sould not compile.
 
> I think it should compile - but what it should not do is link.
 
I believe it may link, because not defining the functions
results in undefined behavior.
jameskuyper@verizon.net: Apr 23 01:42PM -0700

On Monday, April 23, 2018 at 4:18:03 PM UTC-4, Tim Rentsch wrote:
> > doesn't require this.
 
> Do you think the argument value is not of type (void*)? Did you
> miss the () after the template invocation?
 
I missed the explicit cast to void*, which is pretty dumb. My comments about that conversion having undefined behavior remain valid.
 
 
> > I think it should compile - but what it should not do is link.
 
> I believe it may link, because not defining the functions
> results in undefined behavior.
 
True, undefined behavior allows for the possibility of it linking - but
as a matter of QoI, I think it shouldn't link. What I know about linking
doesn't suggest any reason why that should be difficult to achieve - but
I'm not by any means an expert on real world linkers.
Sky89 <Sky89@sky68.com>: Apr 23 08:17PM -0400

Hello..
 
Read this:
 
 
More precision about my new scalable algorithm..
 
As you have noticed i have implemented a new scalable algorithm
for Scalable Parallel C++ and Delphi Conjugate Gradient Linear System
Solver Library, why i have choosen Conjugate Gradient ? here is also
why:
 
For instance, Conjugate Gradient is known to converge to the exact
solution in n steps for a matrix of size n, and was historically first
seen as a direct method because of this. However, after a while people
figured out that it works really well if you just stop the iteration
much earlier - often you will get a very good approximation after much
fewer than n steps. In fact, we can analyze how fast Conjugate gradient
converges. The end result is that Conjugate gradient is used as an
iterative method for large linear systems today.
 
Hope you will be happy with my new scalable algorithm of my following
Scalable Parallel C++ Conjugate Gradient Linear System Solver Library,
my Scalable Parallel C++ Conjugate Gradient Linear System Solver Library
is especially designed for large scale industrial engineering problems
that you find on industrial Finite element problems and such, this
scalable Parallel library was ported to FreePascal and all the Delphi
versions and even to Delphi 7 and also to C++, hope you will find it
really good, and it works on Linux and Windows.
 
The Windows version of my Library for both Delphi and C++ supports
processors groups so that it can use more than 64 logical processors ,
and it is NUMA-aware and cache-aware, please look at the source code
to notice it.
 
I have just read and understood the following paper about
Preconditioning Techniques Analysis for CG Method:
 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.592.1575&rep=rep1&type=pdf
 
 
As you have noticed that i have implemented my following Scalable
Parallel C++ Conjugate Gradient Linear System Solver Library ,
it doesn't implement preconditionning techniques because it is
fully "scalable" on multicore and NUMA systems, my library contains a
Scalable Parallel implementation of Conjugate Gradient Dense Linear
System Solver library that is NUMA-aware and cache-aware, and it
contains also a Scalable Parallel implementation of Conjugate Gradient
Sparse Linear System Solver library that is cache-aware.
 
Please download the zip file and read the readme file inside the
zip to know how to use it.
 
Language: GNU C++ and Visual C++ and C++Builder
 
Operating Systems: Windows, Linux, Unix and Mac OS X on (x86)
 
 
You can download my Scalable Parallel C++ Conjugate Gradient Linear
System Solver Library from:
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: Apr 23 07:50PM -0400

Hello..
 
Read this:
 
Hope you will be happy with my new scalable algorithm of my following
Scalable Parallel C++ Conjugate Gradient Linear System Solver Library,
my Scalable Parallel C++ Conjugate Gradient Linear System Solver Library
is especially designed for large scale industrial engineering problems
that you find on industrial Finite element problems and such, this
scalable Parallel library was ported to FreePascal and all the Delphi
versions and even to Delphi 7 and also to C++, hope you will find it
really good, and it works on Linux and Windows.
 
The Windows version of my Library for both Delphi and C++ supports
processors groups so that it can use more than 64 logical processors ,
and it is NUMA-aware and cache-aware, please look at the source code
to notice it.
 
I have just read and understood the following paper about
Preconditioning Techniques Analysis for CG Method:
 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.592.1575&rep=rep1&type=pdf
 
 
As you have noticed that i have implemented my following Scalable
Parallel C++ Conjugate Gradient Linear System Solver Library ,
it doesn't implement preconditionning techniques because it is
fully "scalable" on multicore and NUMA systems, my library contains a
Scalable Parallel implementation of Conjugate Gradient Dense Linear
System Solver library that is NUMA-aware and cache-aware, and it
contains also a Scalable Parallel implementation of Conjugate Gradient
Sparse Linear System Solver library that is cache-aware.
 
Please download the zip file and read the readme file inside the
zip to know how to use it.
 
Language: GNU C++ and Visual C++ and C++Builder
 
Operating Systems: Windows, Linux, Unix and Mac OS X on (x86)
 
 
You can download my Scalable Parallel C++ Conjugate Gradient Linear
System Solver Library from:
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
 
Thank you,
Amine Moulay Ramdane.
Tim Rentsch <txr@alumni.caltech.edu>: Apr 23 12:40PM -0700

> operator Coords() const;
 
> It's giving the operator Coords() function as a candidate function, but
> doesn't explain why it's rejecting it.
 
I must admit I find the rules for implicit conversions in C++ to
be confusing. So what I have to offer is just some observations
that may be helpful.
 
(1) I tried with g++, it gave a different message.
 
(2) You can do what you want with one of these (some may not
work with older C++'s):
 
const Foo foo( Bar() );
const Foo foo{ Bar() };
const Foo foo = { Bar() };
 
(3) If we had declared foo as 'Foo foo;' then
 
foo = Bar();
 
doesn't work, but
 
foo = Foo( Bar() );
 
or
 
foo = { Bar() };
 
 
does. This behavior matches my (ancient and perhaps now outdated)
understanding that only one implicit conversion is allowed.
Tim Rentsch <txr@alumni.caltech.edu>: Apr 23 12:08PM -0700

>> you to think it might be bad grammar?
 
> *shrug* It felt like mixing metaphors, but I'm not sure. Sorry for
> bringing it up --
 
No worries! I always like getting feedback on my grammar and
language, even in cases where something just seems off or
sounds odd for no readily identifiable reason.
 
> my point was really that I found it very illuminating.
 
I thank you for that. It's a subjective metric I have used for a
long time. It's nice to hear other people find it helpful.
Sky89 <Sky89@sky68.com>: Apr 23 06:26PM -0400

Hello,
 
Read this:
 
 
I have just read and understood the following paper about
Preconditioning Techniques Analysis for CG Method:
 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.592.1575&rep=rep1&type=pdf
 
 
As you have noticed that i have implemented my following Scalable
Parallel C++ Conjugate Gradient Linear System Solver Library ,
it doesn't implement preconditionning techniques because it is
fully "scalable" on multicore and NUMA systems, my library contains a
Scalable Parallel implementation of Conjugate Gradient Dense Linear
System Solver library that is NUMA-aware and cache-aware, and it
contains also a Scalable Parallel implementation of Conjugate Gradient
Sparse Linear System Solver library that is cache-aware.
 
Please download the zip file and read the readme file inside the
zip to know how to use it.
 
Language: GNU C++ and Visual C++ and C++Builder
 
Operating Systems: Windows, Linux, Unix and Mac OS X on (x86)
 
 
You can download my Scalable Parallel C++ Conjugate Gradient Linear
System Solver Library from:
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
 
Thank you,
Amine Moulay Ramdane.
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)