Sunday, January 20, 2019

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

David Brown <david.brown@hesbynett.no>: Jan 21 12:13AM +0100

On 20/01/2019 22:30, Vir Campestris wrote:
>> I've wondered
>> if 2011 C++ is the new C.
 
> You can't run any reasonable subset of C++ without an RTL.
 
Of course you can - depending on how you define "reasonable". Usually
on small or bare metal systems you disable exceptions and RTTI. You
might not be able to use the container libraries, algorithms, and some
of the other "higher level" libraries, but you can use a great deal just
fine.
 
> I've run C bare metal. No RTL at all, and a few lines of assembler to
> start it up.
 
I've done that too. I've even run C with no ram (to be fair, the
program was not very big!). But even cheap and tiny embedded systems
these days have enough flash and ram for some basic parts of the library.
gazelle@shell.xmission.com (Kenny McCormack): Jan 14 10:41AM

In article <q1honj$1up$1@dont-email.me>,
David Brown <david.brown@hesbynett.no> wrote:
...
>discussion about it, I am happy to contribute - but I am not going to
>bother more with someone who alternates between insults and flooding the
>group with gobbledegook.
 
Physician, heal thyself.
 
--
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy of the church so decides."
 
- Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 15 05:24PM

On 15/01/2019 17:06, Rick C. Hodgin wrote:
>> a couple of sentences of it.
 
> There will come a day when you will realize it's actually the
> reverse of what you've said here.
 
Never going to happen.
 
> My prayer for you is that happens on this side of the grave.
 
Instead of praying why don't you jerk off? I recommend gay porn.
 
/Flibble
 
--
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 15 05:35PM

On 15/01/2019 17:31, Rick C. Hodgin wrote:
>>> reverse of what you've said here.
>> Never going to happen.
 
> I certainly hope that's not true.
[snip tl;dr]
 
Fuck off you obtuse egregious fucktarded cockwomble.
 
/Flibble
 
--
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Horizon68 <horizon@horizon.com>: Jan 20 10:59AM -0800

Hello,
 
Read this:
 
 
A conference is coming..
 
Read more here:
 
https://dsconf.in/
 
 
Neil Gunther is a computer information systems researcher best known
internationally for developing the open-source performance modeling
software Pretty Damn Quick and developing the Guerrilla approach to
computer capacity planning and performance analysis. He has also been
cited for his contributions to the theory of large transients in
computer systems and packet networks, and his universal law of
computational scalability.
 
And read more here:
 
Applying The Universal Scalability Law to Distributed Systems
 
http://www.perfdynamics.com/Test/dsconf-abst.html
 
 
About Universal Scalability Law..
 
As you have noticed i have implemented some enhanced programs
of Universal Scalability Law using "mathematics" and "programming" and i
have included the binary executables for x86 64 bit and 32 bit inside
the zip file, it is a "powerful" tool that i want to share with you,
please read about it in the following:
 
My Universal Scalability Law for Delphi and FreePascal was updated to
version 3.21
 
Now i have specified that:
 
Coefficient Alpha is: the contention
 
And
 
Coefficient Beta is: the coherency.
 
Contention and coherency are measured as the fraction of the sequential
execution time. A value of 0 means that there is no effect on
performance. A contention factor of 0.2, for instance, means that 20% of
the sequential execution time cannot be parallelized. A coherency factor
of 0.01 means that the time spent in the synchronization between each
pair of processes is 1% of the sequential execution time.
 
And i have included a 32 bit and 64 bit windows and linux executables
called usl.exe and usl_graph.exe inside the zip, please read the readme
file to know how to use it, it is a very powerful tool.
 
You can download and read about my Universal Scalability Law for Delphi
and FreePascal version 3.21 from:
 
https://sites.google.com/site/scalable68/universal-scalability-law-for-delphi-and-freepascal
 
 
 
Thank you,
Amine Moulay Ramdane.
Horizon68 <horizon@horizon.com>: Jan 20 10:23AM -0800

Hello...
 
 
My Parallel C++ Conjugate Gradient Linear System Solver Library that
scales very well was updated to version 1.74
 
Here is what i have enhanced:
 
The Solve() method is now thread-safe, so you can call it from multiple
threads, everything else is thread-safe except for the constructor , you
have to call the constructor one time from a process and use the object
from multiple threads.
 
I think that my library is much more stable and fast and it works
on both Windows and Linux.
 
You can read about it and download it from my website here:
 
https://sites.google.com/site/scalable68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
 
Thank you,
Amine Moulay Ramdane.
Horizon68 <horizon@horizon.com>: Jan 20 10:22AM -0800

Hello,
 
 
About my C++ synchronization objects library for Windows and Linux..
 
Here is what i have enhanced:
 
- My Scalable Asymmetric Reader-Writer Mutex was enhanced, now you can
pass the number of reader threads to the constructor.
 
- And my SemaMonitor was enhanced, the wait() method returns true if it
is signaled and false if it is not.
 
- And also i have added a Mutex that works correctly.
 
Please read more about my C++ synchronization objects library on
my following website:
 
You can download my C++ synchronization objects library that i have
just updated from:
 
https://sites.google.com/site/scalable68/c-synchronization-objects-library
 
 
Thank you,
Amine Moulay Ramdane.
Horizon68 <horizon@horizon.com>: Jan 20 10:18AM -0800

Hello...
 
 
About memory models and sequential consistency:
 
As you have noticed i am working with x86 architecture..
 
Even though x86 gives up on sequential consistency, it's among the most
well-behaved architectures in terms of the crazy behaviors it allows.
Most other architectures implement even weaker memory models.
 
ARM memory model is notoriously underspecified, but is essentially a
form of weak ordering, which provides very few guarantees. Weak ordering
allows almost any operation to be reordered, which enables a variety of
hardware optimizations but is also a nightmare to program at the lowest
levels.
 
Read more here:
 
https://homes.cs.washington.edu/~bornholt/post/memory-models.html
 
 
Memory Models: x86 is TSO, TSO is Good
 
Essentially, the conclusion is that x86 in practice implements the old
SPARC TSO memory model.
 
The big take-away from the talk for me is that it confirms the
observation made may times before that SPARC TSO seems to be the optimal
memory model. It is sufficiently understandable that programmers can
write correct code without having barriers everywhere. It is
sufficiently weak that you can build fast hardware implementation that
can scale to big machines.
 
Read more here:
 
https://jakob.engbloms.se/archives/1435
 
 
Thank you,
Amine Moulay Ramdane.
Horizon68 <horizon@horizon.com>: Jan 20 10:18AM -0800

Hello...
 
 
Read this:
 
 
About C++ memory model and about Delphi and Freepascal..
 
The abstract machine in the C++98/C++03 specification is fundamentally
single-threaded. So it is not possible to write multi-threaded C++ code
that is "fully portable" with respect to the spec. The spec does not
even say anything about the atomicity of memory loads and stores or the
order in which loads and stores might happen.
 
Of course, you can write multi-threaded code in practice for particular
concrete systems – like pthreads or Windows. But there is no standard
way to write multi-threaded code for C++98/C++03.
 
The abstract machine in C++11 and above is multi-threaded by design. It
also has a well-defined memory model; that is, it says what the compiler
may and may not do when it comes to accessing memory.
 
The default mode for atomic loads/stores in C++11 and above is to
enforce sequential consistency. This just means all loads and stores
must be "as if" they happened in the order you wrote them within each
thread, while operations among threads can be interleaved however the
system likes. So the default behavior of atomics provides both atomicity
and ordering for loads and stores.
 
Now, on a modern CPU, ensuring sequential consistency can be expensive.
In particular, the compiler is likely to emit full-blown memory barriers
between every access here. But if your algorithm can tolerate
out-of-order loads and stores, you can use memory_order_relaxed.
 
So, bottom line. Mutexes are great, and C++11 standardizes them. But
sometimes for performance reasons you want lower-level primitives (e.g.,
the classic double-checked locking pattern). The new standard provides
high-level gadgets like mutexes and condition variables, and it also
provides low-level gadgets like atomic types and the various flavors of
memory barrier. So now you can write sophisticated, high-performance
concurrent routines entirely within the language specified by the
standard, and you can be certain your code will compile and run
unchanged on both today's systems and tomorrow's.
 
Although, unless you are an expert and working on some serious low-level
code, you should probably stick to mutexes and condition variables.
 
And now about Delphi and Freepascal(because as you have noticed i am
working with C++ and with Delphi and Freepascal)
 
As you have noticed i have invented many scalable algorithms and
there implementations, and they are now working on x86 architecture,
and even if Delphi and Freepascal have no memory model as the one of
C++11, i will soon make my scalable algorithms implementations in Delphi
and Freepascal and all my Delphi and Freepascal softwares "portable" by
first using a portable CLH lock that i will write in C and using it from
Delphi and Freepascal and second by using the functions of TInterlocked
class of Delphi and correspondent functions in Freepascal, and after
that all my Delphi and Freepascal projects will become portable on other
architectures than x86, and thus my Delphi and Freepascal scalable
algorithms implementations and all my Delphi and Freepascal softwares
will permit Delphi and Freepascal to become really much more capable and
powerful.
 
Here is my scalable algorithms that i have invented that i will make
portable:
 
- Scalable MLock
- Scalable AMLock
- Scalable SeqlockX
- Many kind of Scalable RWLocks that are starvation-free
- Scalable Asymmetric Reader-Writer Mutex that is starvation-free
- Scalable Rwlocks that are starvation-free using scalable counting networks
- Scalable Hashtable
- Scalable Parallel Varfiler
- Fully scalable Threadpool
- Scalable reference counting with efficient support for weak references
- Scalable FIFO queues both node-based and array-based
- ParallelFor() that scales very well.
 
You can find many of my scalable algorithms and there implementations
in C++ and Delphi and Freepascal on my following website:
 
https://sites.google.com/site/scalable68/
 
 
 
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)