Thursday, May 17, 2018

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

Sky89 <Sky89@sky68.com>: May 17 07:12PM -0400

Hello,
 
 
To Java or not to Java or to C++ or not to C++ ?
 
You will think that i am Delphi or that i am C++, but
i am not Delphi or C++, i am "inventing" scalable algorithms
and many other tools like my Parallel Compression Library and my
Parallel archiver in Delphi and FreePascal and many others and i am
porting them to C++ or to Java, and this has given my
new library called: C++ synchronization objects library here:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
And my Delphi and FreePascal Parallel Compression Library and my
Parallel archiver do work with C++Builder, and i will try
to port them to GCC and to Visual C++.
 
This is how i am doing it for Delphi and FreePascal and for C++..
 
I have also implemented my Scalable Parallel C++ Conjugate Gradient
Linear System Solver Library, read about it:
 
Sparse linear system solvers are ubiquitous in high performance
computing (HPC) and often are the most computational intensive parts in
scientific computing codes. A few of the many applications relying on
sparse linear solvers include fusion energy simulation, space weather
simulation, climate modeling, and environmental modeling, and
finite element method, and large-scale reservoir simulations to enhance
oil recovery by the oil and gas industry. .
 
My Scalable Parallel C++ Conjugate Gradient Linear System Solver
Library for Windows and Linux was updated to version 1.70,
it was more optimized, and this version is much more stable
and scalable and very fast:
 
Author: Amine Moulay Ramdane
 
Description:
 
This 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.
 
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.
 
 
You can download it from:
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
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)
 
 
 
 
Thank you,
Amine Moulay Ramdane.
Sky89 <Sky89@sky68.com>: May 17 06:37PM -0400

Hello..
 
More precision about my Scalable Parallel C++ Conjugate Gradient Linear
System Solver Library:
 
Sparse linear system solvers are ubiquitous in high performance
computing (HPC) and often are the most computational intensive parts in
scientific computing codes. A few of the many applications relying on
sparse linear solvers include fusion energy simulation, space weather
simulation, climate modeling, and environmental modeling, and
finite element method, and large-scale reservoir simulations to enhance
oil recovery by the oil and gas industry. .
 
My Scalable Parallel C++ Conjugate Gradient Linear System Solver
Library for Windows and Linux was updated to version 1.70,
it was more optimized, and this version is much more stable
and scalable and very fast:
 
Author: Amine Moulay Ramdane
 
Description:
 
This 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.
 
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.
 
 
You can download it from:
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
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)
 
 
 
 
Thank you,
Amine Moulay Ramdane.
boltar@cylonHQ.com: May 17 08:55AM

On Wed, 16 May 2018 21:07:28 +0300
>> input or stuck in a write() waiting to output, the pipe or socket descriptor
>> would be multiplexed in select() or poll().
 
>So the process would sit in select() indefinitely. This would be the
 
Not really, you just wait for something to happen. You may have multiplexed
50 file descriptors and if one is blocking then you can service the others.
Plus select() has a timeout so the program can go do something else if
there's nothing coming down the pipes or sockets.
 
>would be less prone to deadlocks in general (at the expense of
>duplicating all mutable data structures and needing more tedious ways to
>keep them synchronized).
 
Yes, there is more work with multiprocess with data sharing. Obviously if
you need to split up huge amounts of data to pass through some processing
then join it all back together you're better off with threads.
 
 
>C++ is certainly a language where one can mess up in horrific ways and
>lots of things which can be done should be not done. That's nothing new,
>except that multithreading bugs are often harder to catch and fix.
 
Not just C++, I've seen pthread nightmares in plain C too.
 
>is pretty much expected. The software expands to fill all the available
>memory and cores, that's just economics. And to fill all the cores the
 
No, thats just lazy programming. The amount of extra functionality brought
by faster CPUs has no way increased with the amount of extra horsepower and
memory required by applications. I'll make an exception for things like
video editing and other maths intensive systems, but when you look at a dog
like MS Word and what it can do compared to what it could do 20 years ago
then look at the minimum spec required to run it now, its just farcical.
Christian Gollwitzer <auriocus@gmx.de>: May 17 10:38PM +0200


> Really? How do you think all the various GUI events were run in the background
> then while your application ran its main thread? Or do you remember having
> to - for example - explicitely program the cursor to flash in a text box?
 
It worked by cooperative multitasking. Even today, GUI libraries do not
use threads to make the widgets run seemingly in parallel. All that I
know of use event loops for that, i.e. in the core it is a big select()
loop (with timeouts to handle regular tasks like updating the display of
a clock).
 
Windows 3.11 supported preemptive multitasking (IIRC it was a
configurable option even), before that ALL programs shared a single big
event loop, with the consequences that a single stalled program would
halt the whole machine, including the blinking cursor.
 
Christian
boltar@cylonHQ.com: May 17 08:57AM

On Wed, 16 May 2018 15:49:46 -0400
>Hello...
 
>Here is how to use my Delphi projects with C++Builder:
 
Is Delphi still used much?
Real Troll <Real.Troll@Trolls.com>: May 17 04:25PM -0400

>> Hello...
 
>> Here is how to use my Delphi projects with C++Builder:
> Is Delphi still used much?
 
Yes by that Moroccon nutter (some call him Moroccon terrorist) called
Sky89, Amine Moulay Ramdane, Ramine Moulay Ramdane, and some other nyms
he feels necessary to hide his identity.
 
Are you thinking of using it?
 
That Moroccon idiot spends all time releasing bug fixes for his toy
project. The fixes are released every 1 hour when he has stopped taking
his meds!!. Sometimes he is the only one on these newsgroups posting
his crap. Prolific trolls (like yours truly) haven't got a chance to
compete with him.
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)