Saturday, September 29, 2018

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

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Sep 29 03:54PM -0700

An excellent teaching outlining how Jesus has been pushed out of our
lives, society, thinking, and even consideration.
 
We've been duped by an enemy working globally against mankind.
 
https://www.youtube.com/watch?v=zOdpfPmeMIA
 
25 minutes to challenge your thinking.
 
--
Rick C. Hodgin
superduperhengyuan@gmail.com: Sep 29 01:16PM -0700

On Saturday, September 29, 2018 at 12:57:26 PM UTC-7, Marcel Mueller wrote:
> allocations - except for those which do not use dynamic memory at all,
> of course.
 
> Marcel
 
Yes, dealing with static globals can be a major issue and there are no fixed solutions. In fact, it could be no solutions at all unless extensive changes are made.
 
One approach is to trigger the initiation of some globals using system malloc / free. Then switch to memory pool for later uses with no caching. For one open source library I used at work, this approach was quite successful and allowed us to do version upgrades of the library with minimal modifications.
 
With memory pool, at least there can be a solution for certain cases with restrictions. This is the point.
"Öö Tiib" <ootiib@hot.ee>: Sep 29 02:31PM -0700

> > quad core.
 
> Hi, currently I did not add locking code. This can be easily added
> later but not a focus.
 
Then it is unfair to compete with malloc and free that are thread-safe.
Have you benchmarked against malloc and free compiled as single-threaded?
 
> The intention is that each thread should have its memory pool through
> thread local or whatever other means.
 
That approach could be thinkable if there was clear distinction from
malloc and free that are not thread-local. Otherwise how we make
difference between things that are made strictly for thread-local
processing and things that may end their life-time in hands of some
other thread? Having such complications would make it error-prone,
but still useful as performance optimization.
 
> want to release all the memory associated with that thread. Can
> we release all the resources associated with that thread. Using
> this memory pool can do so.
 
This scenario would be only thinkable when threads acted like
separate processes, communicating with each other only
through rather restricted means like sockets or pipes or
memory-mapped files of operating system. It is no way the case
with usual multi-threaded programs and it would be likely better
to use actual multi-processing and the processes compiled as
single-threaded in these scenarios.
 
> Obviously, there are other pieces you need to incorporate this memory pool.
 
I did not manage to follow what you meant.
superduperhengyuan@gmail.com: Sep 29 03:47PM -0700

On Saturday, September 29, 2018 at 2:31:34 PM UTC-7, Öö Tiib wrote:
> Then it is unfair to compete with malloc and free that are thread-safe.
> Have you benchmarked against malloc and free compiled as single-threaded?
 
I used the latest dlmalloc source (the mother of most if not all malloc implementations) which does not have lock enabled by default.
 
> processing and things that may end their life-time in hands of some
> other thread? Having such complications would make it error-prone,
> but still useful as performance optimization.
 
An approach is basically have a thread local variables to keep track of memory pool including system malloc/free is being used. And switch to use specific pool using the flag.
 
> with usual multi-threaded programs and it would be likely better
> to use actual multi-processing and the processes compiled as
> single-threaded in these scenarios.
 
Imagine that you are running lots of threads to do some heavy processing.
Each thread has its own partition of work (which may or may not need to call 3rd party library), with some shared data cache, and thread specific memory. Now, one thread declares there is an error / solution and the job can be terminated early. What do you do at this point?
 
One possible solution is to gather the output info and suspend and kill all the threads and release associated resources. I am not saying that this is the only solution, but it certainly is a choice that pushes certain difficult aspects of task/resource management to specific places, rather than spreading it allover the place.
 
Now, you could argue that this type of work "should" be done in process model. I do not want to get into thread vs process debate. However, threads are typically lighter weight, and lower synchronization costs. Resource managements are also simpler.
 
 
> > Obviously, there are other pieces you need to incorporate this memory pool.
 
> I did not manage to follow what you meant.
 
What I meant that you cannot just drop in memory pool and expect it to magically solve the problem. It requires certain architectural designs such that memory pool provides the benefits. For typical non-server applications, one may never need it.
 
For a long running server process, how to avoid memory leak, fragmentation, etc are challenging issues. CookMem is intended to be a part of solutions, rather than the solution by itself.
 
Heng Yuan
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 29 11:13PM +0100

On Sat, 29 Sep 2018 09:01:25 +0200
Ralf Goertz <me@myprovider.invalid> wrote:
[snip]
> dependeing on whether i is int or char. I never had to use int8_t before
> but as I said I was under the impression, that it would be an integral
> and not a char type.
 
A char type is an integral type. (As are signed char, short int, int,
long int, long long int and their unsigned equivalents and bool,
wchar_t, char16_t and char32_t, together with the fixed/minimum sized
integer types, if they exist in the implementation in question):
according to the standard "bool, char, char16_t, char32_t, wchar_t, and
the signed and unsigned integer types are collectively called integral
types". char can be signed or unsigned but it is also a distinct type
from signed char or unsigned char. It has no special status beyond
that.
 
If all you are concerned about is printing char types with C++ streams'
operator << so they print in the same way that ints print, then cast
them to int in your call to operator << for the stream. Given the
length of this thread though I suspect you must be concerned about
something else.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 29 10:20PM +0100

Possibly most amusing GitHub pull request evar...
 
https://github.com/Microsoft/MS-DOS/pull/1
 
/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."
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: