Tuesday, October 11, 2016

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

legalize+jeeves@mail.xmission.com (Richard): Oct 11 02:19AM

[Please do not mail me a copy of your followup]
 
mark <mark@invalid.invalid> spake the secret code
>terms of restrictions. If its a constexpr value, it can be used as
>template parameter (or array bounds or whatever). I have very
>specifically said constexpr and not const.
 
My point is that we're hung up on one very specific details here that
can't be avoided due to the nature of reinterpret_cast<>. However, if
you stated the goal instead of the task, we might be able to come up
with an alternative solution.
 
There is no solution on this path. We can't suggest another path,
because we don't know where you're trying to go.
--
"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>
mark <mark@invalid.invalid>: Oct 11 07:31PM +0200

On 2016-10-11 04:19, Richard wrote:
>> specifically said constexpr and not const.
 
> My point is that we're hung up on one very specific details here
> that can't be avoided due to the nature of reinterpret_cast<>.
 
I want to avoid the constant expression reinterpret_cast in the first
place. That's why this thread is titled 'Stripping cast from macro'.
 
> However, if you stated the goal instead of the task, we might be able
> to come up with an alternative solution.
 
The goal is:
#define REGISTER (*(volatile uint32_t *)0x42424242)
constexpr uintptr_t register_addr = SOME_MAGIC(REGISTER);
 
REGISTER has to end up as constant expression. These integers are used
for compile time calculations, array sizes, identities for static
template classes, initialization lists, for construction of parameter
packs, ...
 
> There is no solution on this path.
 
There is an ugly workaround. I can use a macro to turn REGISTER into a
string literal "(*(volatile uint32_t *)0x42424242)", which can be parsed
at compile time with a constexpr function. With C++11 it's a bit nasty,
with C++14 no problem. What makes this kludge somewhat viable is that it
is possible to get good error messages if the string has an unexpected
format and is not parsable.
legalize+jeeves@mail.xmission.com (Richard): Oct 11 09:30PM

[Please do not mail me a copy of your followup]
 
mark <mark@invalid.invalid> spake the secret code
 
>The goal is:
>#define REGISTER (*(volatile uint32_t *)0x42424242)
>constexpr uintptr_t register_addr = SOME_MAGIC(REGISTER);
 
Sorry, but this is what I'm calling "the task". We're stuck on some
low-level details that aren't yielding fruit because we don't have
visibility into the scope of the larger problem.
 
The goal might be something like "I want to model this set of
hardware registers with the following structure...".
 
Just look at what you've written above. 0x42424242 is a magical,
made-up number, not a real-world example of what you're trying to do.
SOME_MAGIC is also some made-up thing that isn't contextualized into
the larger problem.
 
Help us to help you. Please don't just repeat the above snippet
because that isn't the end-game; it's a low-level detail that isn't
workable as it stands.
--
"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>
Paavo Helde <myfirstname@osa.pri.ee>: Oct 12 02:05AM +0300

On 11.10.2016 20:31, mark wrote:
> for compile time calculations, array sizes, identities for static
> template classes, initialization lists, for construction of parameter
> packs, ...
 
Not sure how you like this, but this is able to strip away the cast:
 
#include <stdint.h>
 
#define REGISTER (*(volatile uint32_t *)0x42424242)
 
#define EAT(x)
#define volatile ))EAT(
#define SOME_MAGIC(x) (EAT x
 
constexpr uintptr_t register_addr = SOME_MAGIC(REGISTER);
Ike Naar <ike@iceland.freeshell.org>: Oct 11 06:38PM

>> getting a job and being content with what the Lord gives you.
 
> Writing software is work, damn it. Selling many copies is not a sin,
> damn it! What the heck is wrong with you man?!
 
If it's not a sin, why do you damn it?
"Chris M. Thomasson" <invalid@invalid.invalid>: Oct 11 03:21PM -0700

On 10/10/2016 1:18 PM, Rick C. Hodgin wrote:
>> ... Now I can't make a lot of money and I can't get married because its
>> too much of a temptation? LOL!!!!
 
> You are misreading I'm writing, either intentionally or unintentionally.
[...]
 
moron!
"Chris M. Thomasson" <invalid@invalid.invalid>: Oct 11 03:22PM -0700

On 10/10/2016 7:02 PM, Melzzzzz wrote:
 
>>> Chris, please don't swear here.
 
>> Ummm, the word _damn_ actually offends you? Wow. Just, wow.
 
> God does not like such ;)
 
All praise be to Jesus, in Rick holey name.
"Chris M. Thomasson" <invalid@invalid.invalid>: Oct 11 03:23PM -0700

On 10/11/2016 5:03 AM, Rick C. Hodgin wrote:
[...]
 
GOD is nicer than you think it is!
lol. wow, you retarded nice person!
 
moron.
"Öö Tiib" <ootiib@hot.ee>: Oct 11 03:33PM -0700

On Tuesday, 11 October 2016 21:38:39 UTC+3, Ike Naar wrote:
 
> > Writing software is work, damn it. Selling many copies is not a sin,
> > damn it! What the heck is wrong with you man?!
 
> If it's not a sin, why do you damn it?
 
Can someone explain how to figure out what was damned there ... writing
software plus selling many copies or work plus sin?
"Chris M. Thomasson" <invalid@invalid.invalid>: Oct 11 03:34PM -0700

On 10/10/2016 1:16 PM, Melzzzzz wrote:
> What Romans (especially Byzantine) did to this is that wealthy man and
> man of questionable morality became saints. Even brother killers.
 
>> BTW, Rick is insane.
 
I would like to be a Christian that is not totally insane... DAMN IT!
 
People like the infinite moron, anti-god:Rick, makes this damn near
impossible.
 
;^I
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 11 03:42PM -0700

How old are you, Chris?
 
Best regards,
Rick C. Hodgin
"Chris M. Thomasson" <invalid@invalid.invalid>: Oct 11 03:49PM -0700

On 10/11/2016 3:42 PM, Rick C. Hodgin wrote:
> How old are you, Chris?
Born in late 77.
Jerry Stuckle <jstucklex@attglobal.net>: Oct 11 12:31PM -0400

On 10/11/2016 11:24 AM, Wouter van Ooijen wrote:
 
> Yuk! I am not a static constexpr, I am a run-time object with limited
> lifetime and a well-defined a destructor.
 
> W
 
One thing about it. There may or may not be eternal life. But having
to put up with Rick's continued proselytizing makes life seem eternal!
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
"Chris M. Thomasson" <invalid@invalid.invalid>: Oct 11 03:18PM -0700

On 10/11/2016 9:31 AM, Jerry Stuckle wrote:
 
>> W
 
> One thing about it. There may or may not be eternal life. But having
> to put up with Rick's continued proselytizing makes life seem eternal!
 
Damn it!!!!
Ramine <ramine@1.1>: Oct 11 01:19PM -0400

Hello..........
 
 
Universal Scalability Law program
 
 
Author: Amine Moulay Ramdane.
 
Email: aminer@videotron.ca
 
 
Description:
 
This program analyzes system performance data with the Universal
Scalability Law.
 
 
You can download it from and read about it from here
 
https://sites.google.com/site/aminer68/universal-scalability-law-for-delphi-and-freepascal
 
 
 
Thank you,
Amine Moulay Ramdane.
bleachbot <bleachbot@httrack.com>: Oct 11 07:08PM +0200

bleachbot <bleachbot@httrack.com>: Oct 11 07:10PM +0200

bleachbot <bleachbot@httrack.com>: Oct 11 07:19PM +0200

Ramine <ramine@1.1>: Oct 11 01:10PM -0400

Hello......
 
 
C++ synchronization objects library
 
 
Author: Amine Moulay Ramdane
 
Email: aminer@videotron.ca
 
Description:
 
This library contains 9 synchronization objects, first one is my
scalable SeqlockX that is a variant of Seqlock that eliminates the
weakness of Seqlock that is "livelock"of the readers when there is more
writers, and second is my scalable MLock that is a scalable
lock , and third is my SemaMonitor that combines all characteristics
of a semaphore and an eventcount and also a windows
Manual-reset event and also a windows Auto-reset event, and fourth
is my scalable DRWLock that is a scalable reader-writer lock that is
starvation-free and it does spin-wait, and five is is my scalable
DRWLockX that is a scalable reader-writer lock that is
starvation-free and it doesn't spin-wait, but it waits on the Event
objects and my SemaMonitor, so it is energy efficient, and six one is
my scalable asymmetric DRWLock that doesn't use any atomic operations
and/or StoreLoad style memory barriers on the
reader side, so it look like RCU, and it is fast. This scalable
Asymmetric Distributed Reader-Writer Mutex is FIFO fair on the
writer side and FIFO fair on the reader side and of course it is
starvation-free and it does spin-wait, and seven one is my scalable
asymmetric DRWLockX that doesn't use any atomic operations
and/or StoreLoad style memory barriers on the reader side, so it
look like RCU, and it is fast. This scalable Asymmetric Distributed
Reader-Writer Mutex is FIFO fair on the writer side and FIFO fair on the
reader side and of course it is starvation-free, and it does not
spin-wait, but it waits on Event objects and my SemaMonitor, so it
is energy efficient, and eight is my LW_Asym_RWLockX that is a
lightweight scalable Asymmetric Reader-Writer Mutex that uses a technic
that looks like Seqlock without looping on the reader side
like Seqlock, and this has permited the reader side to be costless,
it is FIFO fair on the writer side and FIFO fair on the reader side and
it is of course Starvation-free and it does spin-wait, and nine is my
Asym_RWLockX, a lightweight scalable Asymmetric Reader-Writer Mutex that
uses a technic that looks like Seqlock without looping
on the reader side like Seqlock, and this has permited the reader
side to be costless, it is FIFO fair on the writer side and FIFO fair on
the reader side and it is of course Starvation-free and it does not
spin-wait, but waits on my SemaMonitor, so it is energy efficient.
 
My scalable Asymmetric Reader-Writer Mutex calls the windows
FlushProcessWriteBuffers() just one time, but my scalable
Asymmetric Distributed Reader-Writer Mutex calls
FlushProcessWriteBuffers() many times.
 
 
You can download it from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
I have implemented my inventions with FreePascal and Delphi compilers
that don't reorder loads and stores even with compiler optimization, and
this is less error prone than C++ that follows a relaxed memory model
when compiled with optimization, so i have finally compiled my
algorithms implementations with FreePascal into Dynamic Link Libraries
that are used by C++ in a form of my C++ Object Synchronization Library.
 
If you take a look at the zip file , you will notice that it contains
the DLLs Object pascal source codes, to compile those dynamic link
libraries source codes you will have to download my SemaMonitor Object
pascal source code and my SeqlockX Object pascal source code and my
scalable MLock Object pascal source code and my scalable DRWLock Object
pascal source code from here:
 
https://sites.google.com/site/aminer68/
 
I have compiled and included the 32 bit and 64 bit windows Dynamic Link
libraries inside the zip file, if you want to compile the dynamic link
libraries for Unix and Linux and OSX on (x86) , please download the
source codes of my SemaMonitor and my scalable SeqlockX and my scalable
MLock and my scalable DRWLock and compile them yourself.
 
My SemaMonitor of my C++ synchronization objects library is
easy to use, it combines all characteristics of a semaphore and an
eventcount and also a windows Manual-reset event and also a windows
Auto-reset event, here is its C++ interface:
 
class SemaMonitor{
SemaMonitor(bool state, long1 InitialCount1=0,long1
MaximumCount1=INFINITE);
~SemaMonitor();
 
void wait(signed long mstime=INFINITE);
void signal();
void signal_all();
void signal(long1 nbr);
void setSignal();
void resetSignal();
long2 WaitersBlocked();
};
 
So when you set the first parameter that is state of the constructor to
true. it will add the characteristic of a Semaphore to the to the
Eventcount, so the signal will not be lost if the threads are not
waiting for the SemaMonitor objects, but when you set the first
parameter of the construtor to false, it will not behave like a
Semaphore because if the threads are not waiting for the SemaCondvar or
SemaMonitor the signal will be lost..
 
the parameters InitialCount1 and MaximumCount1 is the semaphore
InitialCount and MaximumCount.
 
The wait() method is for the threads to wait on the SemaMonitor
object for the signal to be signaled.
 
and the signal() method will signal one time a waiting thread on the
SemaMonitor object.
 
the signal_all() method will signal all the waiting threads on the
SemaMonitor object.
 
the signal(long2 nbr) method will signal nbr number of waiting threads
 
the setSignal() and resetSignal() methods behave like the windows Event
object's methods that are setEvent() and resetEvent().
 
and WaitersBlocked() will return the number of waiting threads on
the SemaMonitor object.
 
As you have noticed my SemaMonitor is a powerful synchronization object.
 
Please read the readme files inside the zip file to know more about them..
 
Here is my new invention that is my new algorithm:
 
I have invented a new algorithm of my scalable Asymmetric Distributed
Reader-Writer Mutex, and this one is costless on the reader side, this
one doesn't use any atomic operations and/or StoreLoad style memory
barriers on the reader side, my new algorithm has
added a technic that looks like Seqlock, but this technic doesn't
loop as Seqlock. Here is my algorithm:
 
On the reader side we have this:
 
--
procedure TRWLOCK.RLock(var myid:integer);
 
var myid1:integer;
id:long;
begin
 
 
myid1:=0;
id:=FCount5^.fcount5;
if (id mod 2)=0
then FCount1^[myid1].fcount1:=1
else FCount1^[myid1].fcount1:=2;
if ((FCount3^.fcount3=0) and (id=FCount5^.fcount5) and
(FCount1^[myid1].fcount1=1))
then
else
begin
LockedExchangeAdd(nbr^.nbr,1);
if FCount1^[myid1].fcount1=2
then LockedExchangeAdd(FCount1^[myid1].fcount1,-2)
else if FCount1^[myid1].fcount1=1
then LockedExchangeAdd(FCount1^[myid1].fcount1,-1);
event2.wait;
LockedExchangeAdd(FCount1^[myid1].fcount1,1);
LockedExchangeAdd(nbr^.nbr,-1);
end;
end;
--
 
The writer side will increment FCount5^.fcount5 like does
a Seqlock, and the reader side will grap a copy of FCount5^.fcount5
and copy it on the id variable, if (id modula 2) is equal to zero
that means the writer side has not modified yet Fcount3^.fcount3,
and the reader side will test again if FCount3^.fcount3 equal 0, and
if id=FCount5^.fcount5 didn't change and if FCount1^[myid1].fcount1 that
we have assigned before didn't change and that means that we are sure
that the writer side will block on FCount1^[myid1].fcount1 equal 1.
 
And notice with me that i am not looping like in Seqlock.
 
And the rest of my algorithm is easy to understand.
 
This technic that looks like Seqlock without looping like Seqlock
will allow us to be sure that although the x86 architecture will reorder
the loads of the inside reader critical section , the loads
inside the reader critical section will not go beyond the load of
FCount5^.fcount5 and this will allow my algorithm to work correctly.
 
My algorithm is FIFO fair on the writer side and FIFO fair on the
Reader side , and of course it is Starvation-free, and it is
suitable for realtime critical systems.
 
My Asym_RWLockX and LW_Asym_RWLockX algorithms work the same.
 
You will find the source code of my new algorithm here:
 
https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex
 
It is the version 2 that is my own algorithm.
 
and you can download the source code of my Asym_RWLockX and
LW_Asym_RWLockX algorithms that work the same from here:
 
https://sites.google.com/site/aminer68/scalable-rwlock
 
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.
Ramine <ramine@1.1>: Oct 11 01:08PM -0400

Hello...
 
 
Scalable Parallel C++ Conjugate Gradient Linear System Solver
Library version 1.53
 
 
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.
 
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
 
 
You can download it from:
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
 
Thank you,
Amine Moulay Ramdane.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 11 07:09PM +0100

On 11/10/2016 07:08, Juha Nieminen wrote:
 
> From the beginning sure, of course. But from the middle? It requires as
> many operations as with std::vector. If there are differences, I don't
> think they are so big.
 
I have timings for this made when benchmarking my segmented_array
container; they are:
 
std::vector random erase: 7.4317 seconds
std::deque random erase: 13.9245 seconds
std::list random erase: 24.8124 seconds
mkr::avl_array random erase: 0.1288 seconds
neolib::segmented_array (1) random erase: 0.2581 seconds
neolib::segmented_array (2) random erase: 0.1250 seconds
neolib::segmented_array (3) random erase: 0.0961 seconds
neolib::segmented_array (4) random erase: 0.0813 seconds
std::vector random insert: 56.7711 seconds
std::deque random insert: 19.2342 seconds
std::list random insert: 55.3831 seconds
mkr::avl_array random insert: 0.1560 seconds
neolib::segmented_array (1) random insert: 0.3113 seconds
neolib::segmented_array (2) random insert: 0.1489 seconds
neolib::segmented_array (3) random insert: 0.1355 seconds
neolib::segmented_array (4) random insert: 0.1741 seconds
 
Interestingly std::vector and std::deque swap places for erase() vs
insert().
 
http://i42.co.uk/stuff/segmented_array.htm
 
/Flibble
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)