Saturday, November 21, 2015

Digest for comp.lang.c++@googlegroups.com - 20 updates in 9 topics

bleachbot <bleachbot@httrack.com>: Nov 21 09:23PM +0100

bleachbot <bleachbot@httrack.com>: Nov 21 09:40PM +0100

bleachbot <bleachbot@httrack.com>: Nov 21 11:50PM +0100

Ramine <ramine@1.1>: Nov 21 05:53PM -0800

Hello.....
 
 
Now , ladies and gentlemen, you can be confident with all my projects
that are freewares, because i have thoroughly tested them and i think
they are stable and fast now , and i think i have corrected all the bugs
in them.
 
One last note, if you want to compile my projects on 64 bit compilers
and run them, you have to use the DLL called msvcr100.dll that you can
download from here:
 
https://sites.google.com/site/aminer68/needed-files
 
On 32 bit compilers you need msvcr110.dll that you will find inside the
zip files......
 
You need msvcr110.dll and msvcr100.dll because under Delphi XE versions
i am using the scalable tbbmalloc memory manager from Intel that is very
fast and efficient and that needs them...
 
You can download all my projects that are freewares from:
 
https://sites.google.com/site/aminer68/
 
 
So be happy with all my projects !
 
And feel free to port them to other programming languages !
 
 
Thank you,
Amine Moulay Ramdane.
"Öö Tiib" <ootiib@hot.ee>: Nov 20 06:05PM -0800

On Saturday, 21 November 2015 00:33:07 UTC+2, gwowen wrote:
> this is a rule of thumb -- and certainly the most common usage -- its
> not a hard and fast rule and you're free - if not necessarily advised -
> to use it as just-another-form-of-flow-control.
 
It is true that we should never say "never". However it has to be some
perceivable or measurable advantage when we use something in
non-idiomatic way. Breaking out of range based for is not such
a case.
 
Usage of exceptions instead of usual flow control within function is
possible but it looks worse and also works less efficiently. Choose a
compiler and show a case when it does not.
 
> So, so sorry, but if you're just going to make assertions about
> "what <x> is for", I'm going to take the inventor of the language's word
> over yours.
 
You perhaps misunderstood the book that you read. Its author clearly
always thinks and never does pointless things. Try that as well? What
can be a reason to construct a pointless empty object, throw it out
of loop to catch and to ignore and discard? Is it really better
way to jump out of loop than 'break' or 'goto'?
Gareth Owen <gwowen@gmail.com>: Nov 21 12:40PM

Öö Tiib <ootiib@hot.ee> writes:
 
[snip weapons-grade assholery]
 
> What can be a reason to construct a pointless empty object, throw it
> out of loop to catch and to ignore and discard?
 
To express clearly the intent -- "Jump from here to the matching catch"
 
> Is it really better way to jump out of loop than 'break' or 'goto'?
 
Its better than break, because break doesn't work over multiple leves.
It's not better than goto, (which is why I said that I prefer the goto).
But some people simply won't / aren't allowed to use gotos. Usually
people who prefer hard-and-fast rules to thought.
 
Except where performance is critical, clarity should trump performance.
So unless the throw/catch time dominates the search time (which it
almost never will) *and* the timing of this section determines the
program efficiency, its an irrelevance.
Luca Risolia <luca.risolia@linux-projects.org>: Nov 21 08:17PM +0100

Il 20/11/2015 23:32, Gareth Owen ha scritto:
> this is a rule of thumb -- and certainly the most common usage -- its
> not a hard and fast rule and you're free - if not necessarily advised -
> to use it as just-another-form-of-flow-control.
 
I remember that example in TC++PL 3rd edition. If I remember well, there
was also an exercise at the end of the corresponding chapter proposing
to measure the difference between exiting the recursive iterations by
throwing vs using goto or return. I did that exercise with my compiler
and discovered there was not appreciable difference in the timings (I
did not look at any generated code though).
"Öö Tiib" <ootiib@hot.ee>: Nov 21 02:30PM -0800

On Saturday, 21 November 2015 14:40:44 UTC+2, gwowen wrote:
> Öö Tiib <ootiib@hot.ee> writes:
 
> [snip weapons-grade assholery]
 
You are pointlessly vulgar there.
 
 
> > What can be a reason to construct a pointless empty object, throw it
> > out of loop to catch and to ignore and discard?
 
> To express clearly the intent -- "Jump from here to the matching catch"
 
How can doing those odd things express that intent more clearly than
the jump itself?
 
 
> > Is it really better way to jump out of loop than 'break' or 'goto'?
 
> Its better than break, because break doesn't work over multiple leves.
 
You are correct that 'break' does not work there but the actual issue
may be the deeply nested loops themselves.
 
> It's not better than goto, (which is why I said that I prefer the goto).
> But some people simply won't / aren't allowed to use gotos. Usually
> people who prefer hard-and-fast rules to thought.
 
I do not care about those people, they are robots and can not be good
engineers. Rules like "avoid goto" but "do whatever with exceptions"
feel rather contradicting and not from this world even for such robots.
 
Here is link to isocpp FAQ for your robot:
https://isocpp.org/wiki/faq/exceptions#why-not-exceptions
 
Particular quote:
"In particular, do not use exceptions for control flow. throw is not
simply an alternative way of returning a value from a function (similar
to return). Doing so will be slow and will confuse most C++ programmers
who are rightly used to seeing exceptions used only for error
handling. Similarly, throw is not a good way of getting out of a
loop."
 
> So unless the throw/catch time dominates the search time (which it
> almost never will) *and* the timing of this section determines the
> program efficiency, its an irrelevance.
 
That was my first point. Where is your clarity? Lose-lose-lose situation.
Multiple nested loops can't be over large data sets otherwise such nesting
itself is potential performance bottle-neck.
Victor Bazarov <v.bazarov@comcast.invalid>: Nov 20 08:24PM -0500

On 11/18/2015 3:23 PM, Lynn McGuire wrote:
 
>> There is no standardised way. Depends on your compiler.
 
> Yup, bummer. One would think that the C++ standards committee would
> have this now.
 
Why do you think you need this?
 
V
--
I do not respond to top-posted replies, please don't ask
"Öö Tiib" <ootiib@hot.ee>: Nov 20 06:24PM -0800

On Saturday, 21 November 2015 03:24:53 UTC+2, Victor Bazarov wrote:
 
> > Yup, bummer. One would think that the C++ standards committee would
> > have this now.
 
> Why do you think you need this?
 
Typically such things are used for testing, debugging, mocking,
synthesizing new types or for compile-time verifying that some
parallel class hierarchies match.
Victor Bazarov <v.bazarov@comcast.invalid>: Nov 21 07:21AM -0500

On 11/20/2015 9:24 PM, Öö Tiib wrote:
 
> Typically such things are used for testing, debugging, mocking,
> synthesizing new types or for compile-time verifying that some
> parallel class hierarchies match.
 
Well, yes, thank you. I wanted to know the actual reason for grievance
in Lynn McGuire's case, not start a general discussion on development tools.
 
V
--
I do not respond to top-posted replies, please don't ask
"Öö Tiib" <ootiib@hot.ee>: Nov 21 12:50PM -0800

On Saturday, 21 November 2015 14:21:35 UTC+2, Victor Bazarov wrote:
> > parallel class hierarchies match.
 
> Well, yes, thank you. I wanted to know the actual reason for grievance
> in Lynn McGuire's case, not start a general discussion on development tools.
 
Ah, she likely was disappointed that basically all C++ implementations
have had such information available for more than decade but it is so
badly standardized. I myself have found Boost.TypeIndex library to be
most helpful for use-cases that I listed. However lot of people are
afraid of Boost ... so it is hard to suggest.
Ramine <ramine@1.1>: Nov 21 03:25PM -0800

Hello.....
 
 
Today, ladies and gentlemen, i will talk a little bit about my scalable
conjugate gradient system solver library..
 
The important thing to understand is that it it is NUMA-aware and
scalable on NUMA architecture, because i am using two functions that
multiply a matrix by vector, so i have used a mechanism to distributed
equally the memory allocation of the rows of the matrix on different
NUMA nodes, and i have made my algorithm cache-aware, other than that i
have used a probabilistic mechanism to make it scalable on NUMA
architecture , this probabilistic mechanism does minimize at best the
contention points and it render my algorithm fully scalable on NUMA
architecture.
 
Hope you will be happy with my new scalable algorithm and my scalable
parallel library, frankly i think i have to write something like a PhD
paper to explain more my new scalable algorithm , but i will let it as
it is at this moment... perhaps i will do it in the near future.
 
This scalable Parallel 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 XE versions and even to Delphi 7, hope you
will find it really good.
 
Here is the simulation program that uses the probabilistic mechanism
that i have talked about and that prove to you that my algorithm is
scalable:
 
If you look at my scalable parallel algorithm, it is dividing the each
array of the matrix by 250 elements, and if you look carefully i am
using two functions that consumes the greater part of all the CPU, it is
the atsub() and asub(), and inside those functions i am using a
probabilistic mechanism so that to render my algorithm scalable on NUMA
architecture, what i am doing is scrambling the array parts using a
probabilistic function and what i have noticed that this probabilistic
mechanism is very efficient, to prove to you what i am saying , please
look at the following simulation that i have done using a variable that
contains the number of NUMA nodes, and what i have noticed that my
simulation is giving almost a perfect scalability on NUMA architecture,
for example let us give to the "NUMA_nodes" variable a value of 4, and
to our array a value of 250, the simulation bellow will give a number of
contention points of a quarter of the array, so if i am using 16 cores ,
in the the worst case it will scale 4X throughput on NUMA architecture,
because since i am using an array of 250 and there is a quarter of the
array of contention points , so from the Amdahl's law this will give a
scalability of almost 4X throughput on four NUMA nodes, and this will
give almost a perfect scalability on more and more NUMA nodes, so my
parallel algorithm is scalable on NUMA architecture,
 
Here is the simulation that i have done, please run it and you will
notice yourself that my parallel algorithm is scalable on NUMA architecture.
 
Here it is:
 
---
program test;
 
uses math;
 
var tab,tab1,tab2,tab3:array of integer;
a,n1,k,i,n2,tmp,j,numa_nodes:integer;
begin
 
a:=250;
Numa_nodes:=4;
 
setlength(tab2,a);
 
for i:=0 to a-1
do
begin
 
tab2[i]:=i mod numa_nodes;
 
end;
 
setlength(tab,a);
 
randomize;
 
for k:=0 to a-1
do tab[k]:=k;
 
n2:=a-1;
 
for k:=0 to a-1
do
begin
n1:=random(n2);
tmp:=tab[k];
tab[k]:=tab[n1];
tab[n1]:=tmp;
end;
 
setlength(tab1,a);
 
randomize;
 
for k:=0 to a-1
do tab1[k]:=k;
 
n2:=a-1;
 
for k:=0 to a-1
do
begin
n1:=random(n2);
tmp:=tab1[k];
tab1[k]:=tab1[n1];
tab1[n1]:=tmp;
end;
 
for i:=0 to a-1
do
if tab2[tab[i]]=tab2[tab1[i]] then
begin
inc(j);
writeln('A contention at: ',i);
 
end;
 
writeln('Number of contention points: ',j);
setlength(tab,0);
setlength(tab1,0);
setlength(tab2,0);
end.
---
 
You can download my Scalable Parallel Conjugate gradient solver library
from:
 
https://sites.google.com/site/aminer68/scalable-parallel-implementation-...
 
 
 
Feel free to port my algorithm to ADA...
 
 
 
Thank you for your time.
 
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Nov 21 03:43PM -0800

Hello...
 
 
Feel free to port my algorithm to C++...
 
 
Thank you,
Amine Moulay Ramdane.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 21 02:56PM

On Mon, 2015-11-16, Christian Gollwitzer wrote:
>> do is only read titles of questions.:)
 
>> Usually bubbies also are able to read only titles.:)
 
> ... and this is why you got banned from the "fascist" web site.
 
Yeah. Here on USENET we think for a while, see where things are
going, and then use our killfiles. Mine just got one new entry.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 21 01:25PM

On Wed, 2015-11-18, Alf P. Steinbach wrote:
>> Pointers in C++ are much more complex. This confusion is compounded
>> by the lack of a proper array type in C++. So pointers are used much
>> more extensively than in the Wirthian languages.
 
I don't remember much of Modula-2 (last touched it 25 years ago) but
check out std::vector and the idea behind iterators.
 
>> #include <sys/param.h>
 
> All the above are system specific, non-portable. Avoid that by using
> Boost file system library.
 
On the other hand, if you're on Unix, have no plans to support
Windows, check the manual pages for e.g. Linux-specific behavior --
then using them means using well-understood and documented interfaces.
 
One drawback is that those interfaces are expressed in terms of C, not
C++ -- that's surely one reason to use Boost instead, even if you can
assume POSIX.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Marcel Mueller <news.5.maazl@spamgourmet.org>: Nov 21 12:54AM +0100

On 19.11.15 01.45, Alf P. Steinbach wrote:
> things. Most numerical libraries started out as Fortran libraries. I
> don't know how that is today, but I think going from Fortran to C++ is
> not likely to /improve/ the speed significantly.
 
This is not my experience. The Fortran restriction to pass everything by
reference can be quite expensive at small functions. Of course, you
should not expect a factor two.
 
 
Marcel
Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 21 01:08PM

On Wed, 2015-11-18, Noob wrote:
> On 18/11/2015 20:17, Ian Collins wrote:
...
> }
 
> return partial;
 
> }
 
I haven't been paying attention, but the 'i < nvars-1' triggers a
small alarm. You're ignoring the last element (and fun stuff would
happen if 'nvars' is zero, but your assertion says users aren't
supposed to feed in empty vectors).
 
The normal pattern in C and (when there's no better alternative)
C++ is
 
for(unsigned i=0; i < size; i++)
 
Whenever a piece of code deviates from that, I spend a few seconds to
check it for correctness.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
legalize+jeeves@mail.xmission.com (Richard): Nov 21 04:29AM

[Please do not mail me a copy of your followup]
 
slp53@pacbell.net spake the secret code
 
>I'd write it as
 
OK, so a minor tweak to what I was thinking.
 
> int f(void);
 
Aside: why the C-ism?
 
(void) is for C prototypes because no argument list in C means "declare
this function with an unknown number of arguments of unknown type"
and "(void)" explicitly means "takes no arguments". In C++ the (void)
is totally unnecessary.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 21 12:41PM

On Wed, 2015-11-18, Chris Vine wrote:
>> > On 16 Nov 2015 21:03:20 GMT
>> > Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>> >> On Mon, 2015-11-16, Daniel wrote:
...
 
>> > It doesn't mean that. It means "I can't use foo to modify the
>> > object foo points to".
 
>> Sorry; I can't see the difference, unless [...]
 
[Snip more, later text by us both.]
 
Ok, now I see the difference. Yes, I meant "the object foo points
to". Of course const doesn't turn C++ into a purely functional
programming language.
 
I was sloppy with the "modify anything". I was focused more on the
aliasing aspect -- that the object const Foo* foo points to may be
involved a second time via a plain Foo* somewhere.
 
All that never gave me any problems, except for a while I believed
const was more important for optimization than it actually is. That
misconception didn't hurt anyone, and it made me generate fewer bugs.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
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)