Saturday, March 24, 2018

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

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 24 11:59AM -0700

On Friday, March 23, 2018 at 2:43:49 PM UTC-4, Rick C. Hodgin wrote:
> speed is slow enough I'm looking for another tool. If I can
> correct my setup here so it goes faster, I'll be happy to try
> these tools.
 
I was able to switch back to Visual Studio 2010 and it is working
as I would expect.
 
For some reason on this project (which has one source file that's
around 25K lines of code) it is slow single-stepping. But in
VS2010 it is normal speed.
 
I will also try VS2008, and I may switch back to those dev tools
for daily development, and then use VS2015 only at the end when
I want a modern compile.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 24 04:13PM -0700

What alternatives are there to MSVC, and GCC and CLang?
 
Are there any free compilers that are distinct and unique from
those code bases? The only one I am aware of is Intel's C++
compiler, and it's $1600 for the professional version per year,
which I also think is outrageous. Intel should give away their
compilers because it would encourage people to use their CPUs
instead of other manufacturer CPUs.
 
Does anybody have a free compiler that's of its own source code
base, not deriving from GCC or CLang?
 
--
Rick C. Hodgin
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Mar 24 04:17PM -0700

On 3/24/2018 4:13 PM, Rick C. Hodgin wrote:
> instead of other manufacturer CPUs.
 
> Does anybody have a free compiler that's of its own source code
> base, not deriving from GCC or CLang?
 
You can try:
 
http://www.smorgasbordet.com/pellesc
 
It is fairly nice.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Mar 24 04:19PM -0700

On 3/24/2018 4:17 PM, Chris M. Thomasson wrote:
 
> You can try:
 
> http://www.smorgasbordet.com/pellesc
 
> It is fairly nice.
 
One little quirk I found:
 
https://forum.pellesc.de/index.php?topic=7167.0
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 23 11:39PM

On 23/03/2018 04:15, computer45 wrote:
 
> And i have also invented a fully scalable reference counting with
> efficient support for weak references, here it is:
 
> https://sites.google.com/site/aminer68/scalable-reference-counting-with-efficient-support-for-weak-references
 
a) you have yet to show that you have invented anything original;
b) you are quite delusional suffering from delusions of grandeur.
 
/Flibble
 
--
"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."
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Mar 23 05:52PM -0700

On 3/22/2018 5:31 PM, computer45 wrote:
> So i think my scalable FIFO queue is useful and i think i will try to
> sell it, because we have to provide with mine, since it is not an
> "ideal" world.
 
Where is the code for your:
 
CountingNetworks_UInt32_32-bit_n1.dll
CountingNetworks_UInt32_64-bit_n1.dll
 
?
computer45 <computer45@cyber.com>: Mar 23 10:57PM -0400

On 3/23/2018 8:52 PM, Chris M. Thomasson wrote:
 
> CountingNetworks_UInt32_32-bit_n1.dll
> CountingNetworks_UInt32_64-bit_n1.dll
 
> ?
 
I have also modified and optimized the scalable counting network
algorithm, this is why i am not giving the source code, and i think the
DLLs are working correctly, because i have debugged and tested them a lot.
 
Have you another question to ask ?
 
 
Thank you,
Amine Moulay Ramdane.
computer45 <computer45@cyber.com>: Mar 23 10:58PM -0400

On 3/23/2018 8:52 PM, Chris M. Thomasson wrote:
 
> CountingNetworks_UInt32_32-bit_n1.dll
> CountingNetworks_UInt32_64-bit_n1.dll
 
> ?
 
Read again:
 
I have also enhanced and optimized the scalable counting network
algorithm, this is why i am not giving the source code, and i think the
DLLs are working correctly, because i have debugged and tested them a lot.
 
Have you another question to ask ?
 
 
Thank you,
Amine Moulay Ramdane.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Mar 23 10:26PM -0700

On 3/23/2018 7:58 PM, computer45 wrote:
> algorithm, this is why i am not giving the source code, and i think the
> DLLs are working correctly, because i have debugged and tested them a lot.
 
> Have you another question to ask ?
 
If you are not going to release the source code, then how can we inspect
your work? Btw, you did mention the phrase "enhanced and optimized".
This makes me want to think that you got the original scalable counting
network from somewhere else? If I am correct, where did you get it from
in the first place? Thanks.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Mar 24 02:51AM -0700

On 3/23/2018 9:35 AM, Bo Persson wrote:
>> lockfree or blocking.
 
> So it might improve our understanding if you included a link to *your*
> thesis, where all this is thoroughly explained.
 
I tried to take a look, however, his code is secret.
computer45 <computer45@cyber.com>: Mar 24 10:51AM -0400

On 3/24/2018 1:26 AM, Chris M. Thomasson wrote:
> This makes me want to think that you got the original scalable counting
> network from somewhere else? If I am correct, where did you get it from
> in the first place? Thanks.
 
 
 
You will find it in the book: "The art of multiprocessor programming"
 
Here it is:
 
https://www.amazon.ca/Art-Multiprocessor-Programming-Revised-Reprint/dp/0123973376
 
But i have enhance it and optimized more the algorithm.
 
 
Thank you,
Amine Moulay Ramdane.
computer45 <computer45@cyber.com>: Mar 24 12:02PM -0400

On 3/24/2018 1:26 AM, Chris M. Thomasson wrote:
> This makes me want to think that you got the original scalable counting
> network from somewhere else? If I am correct, where did you get it from
> in the first place? Thanks.
 
Read gain, i correct:
 
 
You will find it in the book: "The art of multiprocessor programming"
 
Here it is:
 
https://www.amazon.ca/Art-Multiprocessor-Programming-Revised-Reprint/dp/0123973376
 
But i have enhanced and optimized more the algorithm.
 
 
Thank you,
Amine Moulay Ramdane.
computer45 <computer45@cyber.com>: Mar 24 02:55PM -0400

On 3/24/2018 1:26 AM, Chris M. Thomasson wrote:
> This makes me want to think that you got the original scalable counting
> network from somewhere else? If I am correct, where did you get it from
> in the first place? Thanks.
 
 
 
The DLLs are just the counting network algorithm inplementation,
You will find the algorithm implementation it in the book: "The art of
multiprocessor programming"
 
Here it is:
 
https://www.amazon.ca/Art-Multiprocessor-Programming-Revised-Reprint/dp/0123973376
 
But i have enhanced and optimized more the algorithm.
 
Now my scalable reference counting algorithm implementation is inside
the zip file and named AMInterfacedObject.pas , you can compile
the demo file called test.pas or the demo file called example.dpr with
the following version of Freepascal:
ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/
 
it is FPC version 3.1.1, it must be 3.1.0 or up to compile
my project or you can use also Delphi XE and up or Delphi tokyo.
 
 
 
 
Thank you,
Amine Moulay Ramdane.
cross@spitfire.i.gajendra.net (Dan Cross): Mar 24 08:11PM

In article <p966vc$jks$1@dont-email.me>,
>ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/
 
>it is FPC version 3.1.1, it must be 3.1.0 or up to compile
>my project or you can use also Delphi XE and up or Delphi tokyo.
 
I know better than to engage with a known troll, but....
 
Why is was this posted to comp.lang.c++ if it's about
some random algorithm implemented in Pascal?
 
- Dan C.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Mar 24 01:37PM -0700

On 3/24/2018 7:51 AM, computer45 wrote:
 
> You will find it in the book: "The art of multiprocessor programming"
 
> Here it is:
 
> https://www.amazon.ca/Art-Multiprocessor-Programming-Revised-Reprint/dp/0123973376
 
Okay. Fwiw, I think Maurice has a brother named Greg:
 
https://www.linkedin.com/in/gregherlihy
 
I have conversed with him in the past over on comp.programming.threads
 
 
> But i have enhance it and optimized more the algorithm.
 
That's fine. Can you explain how you enhanced it?
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Mar 24 01:40PM -0700

On 3/24/2018 1:37 PM, Chris M. Thomasson wrote:
 
> Okay. Fwiw, I think Maurice has a brother named Greg:
 
> https://www.linkedin.com/in/gregherlihy
 
> I have conversed with him in the past over on comp.programming.threads
 
Fwiw, here is where Greg mentioned his brother:
 
https://groups.google.com/forum/#!original/comp.programming.threads/xQsUhQwPoOU/v9She5qqpA4J
 
 
computer45 <computer45@cyber.com>: Mar 24 04:45PM -0400

On 3/24/2018 4:40 PM, Chris M. Thomasson wrote:
 
>> Okay. Fwiw, I think Maurice has a brother named Greg:
 
>> https://www.linkedin.com/in/gregherlihy
 
>> I have conversed with him in the past over on comp.programming.threa
ds
 
>>> But i have enhance it and optimized more the algorithm.
 
>> That's fine. Can you explain how you enhanced it?
 
Other than the strict FIFO order that can be broken, here is another
problem with the distributed network of SPSC queues, here it is:
 
 
--
 
5. finally, SPSC may not be a good point for massive ITC(inter-thread
communication):.
 
Because the space complexity goes in O(N^2), N is the number of threads.
It is not rare to see a server with 1k or 2k hardware threads. And "many
core" is the final destination of CPU from current sight.
 
---
 
 
Read all the following webpage and the responses to it to understand:
 
https://www.infoq.com/articles/High-Performance-Java-Inter-Thread-Communications
 
 
 
So then my scalable FIFO queue algorithm and its implementation is still
useful.
 
 
Thank you,
Amine Moulay Ramdane.
computer45 <computer45@cyber.com>: Mar 24 04:47PM -0400

On 3/24/2018 4:40 PM, Chris M. Thomasson wrote:
 
>>> But i have enhance it and optimized more the algorithm.
 
>> That's fine. Can you explain how you enhanced it?
 
Read again, i correct:
 
 
Other than the strict FIFO order that can be broken, here is another
problem with the distributed network of SPSC queues, here it is:
 
 
--
 
5. finally, SPSC may not be a good point for massive ITC(inter-thread
communications):.
 
Because the space complexity goes in O(N^2), N is the number of threads.
It is not rare to see a server with 1k or 2k hardware threads. And "many
core" is the final destination of CPU from current sight.
 
---
 
 
Read all the following webpage and the responses to it to understand:
 
https://www.infoq.com/articles/High-Performance-Java-Inter-Thread-Communications
 
 
 
So then my scalable FIFO queue algorithm and its implementation is still
useful.
 
 
Thank you,
Amine Moulay Ramdane.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Mar 24 02:21PM -0700

On 3/24/2018 1:45 PM, computer45 wrote:
 
> --
 
> 5. finally, SPSC may not be a good point for massive ITC(inter-thread
> communication):.
 
My scheme uses layers of all the queue types. Imvvho, it is good to have
at least a MPSC queue on each thread. It allows multiple threads to send
messages to a "target" single thread. Btw, check this out:
 
https://groups.google.com/d/msg/comp.lang.c++/V0s__czQwa0/DgobuK9xAwAJ
 
It is not bounded, uses CAS for the push (arg!), but it does get around
having to use any deferred reclamation! The pop function retrieves all
the nodes at once using a single atomic swap. Think of multiplexing
these things.
 
Afaict, and imvho, fractals are abundant wrt all the different queue
types. Also, for each queue type we have the bounded or unbounded
qualifier, there is quite a bit of diversity. Think of a high level view
where we can only see MPMC queues, say we have mediocre eyesight for the
moment... We zoom in, and find out that they are actually comprised of
different types of queues that in and of themselves, do not offer MPMC.
 
 
 
> ---
 
> Read all the following webpage and the responses to it to understand:
 
> https://www.infoq.com/articles/High-Performance-Java-Inter-Thread-Communications
 
Will do.
 
 
> So then my scalable FIFO queue algorithm and its implementation is still
> useful.
 
I am not saying it is not useful. I just want to see your improvements,
in code. For some reason I like reading code more than a paper. ;^)
 
Btw, have you filed for a patent?
 
My advise to you... Go ahead and try to implement your work in C++11.
This group can help you out along the way. The more languages you can
implement your work in, the better... Fwiw, I think I remember a long
time ago when you used some of my assembly code in AppCore:
 
http://webpages.charter.net/appcore
 
Fwiw, here is a little JavaScript vector field plotter I made:
 
http://webpages.charter.net/appcore/fractal/field
 
Actually, this can be used to map out a network...
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Mar 24 03:36PM -0700

On 3/24/2018 2:21 PM, Chris M. Thomasson wrote:
> having to use any deferred reclamation! The pop function retrieves all
> the nodes at once using a single atomic swap. Think of multiplexing
> these things.
[...]
 
It is MPMC in nature, and to get FIFO one can reverse the LIFO node list
returned from pop. These are fun to distribute.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 24 07:52AM

On Fri, 2018-03-23, Vir Campestris wrote:
 
> Changing a few functions to a different syntax would mean breaking the
> house style, and would require a slight interruption in my chain of
> thought every time I met one.
 
Also, I've seen no sign that C++ programmers are switching to this
syntax en masse.
 
Perhaps what happened that some people saw C++11 as a chance to start
from scratch, break free from the C legacy and so on. Others (like
me) saw it as just a welcome incremental improvement.
 
> I also avoid auto. If I see this variable auto foo I have to move the
> mouse onto it to let the IDE have a think and tell me what it really is.
> Which is slower than just declaring it properly.
 
I thought I was more sceptical to auto than most, but I wouldn't say I
/avoid/ it. I agree that if you have to ask your IDE, then you have
overused it:
 
- I don't use an IDE.
- If I did I wouldn't want to force my readers to use one.
- git diff isn't an IDE.
- Gerrit (the code review tool) isn't an IDE.
- etc
 
But there are plenty of local variables where it's obvious from close
context what the type is. Or you just pass the value on without
caring what it is. There I happily use auto (or const auto, or const
auto&).
 
I was in one project the other year where one of the goals was to go
all-in with C++11 and later. Auto didn't become a problem there. In
fact, the only C++11 feature we perhaps overdid was messing with move
semantics.
 
> Sometimes of course (type of a lambda for example) auto is
> unavoidable.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 24 07:16AM


>> What textbook are you using that does not discuss them?
 
> It's not the textbook does not discuss virtual functions. I just
> don't seem to be able to apply it in practical code.
 
I have trouble applying them in practical code, too, after 15 years
with C++. In the sense that run-time polymorphism (a better word for
the language feature as a whole, IMHO) is not needed in every program.
 
For me, that tends to happen when:
- My design has several classes which are similar, from some
point of view.
- I want to do similar things with a mix of objects from
these classes.
- And, I can see that I cannot know until runtime which class
I'm processing.
 
(If this doesn't make sense, see other, longer responses by others.)
 
/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.

No comments: