Wednesday, December 21, 2016

Digest for comp.lang.c++@googlegroups.com - 15 updates in 5 topics

Bo Persson <bop@gmb.dk>: Dec 21 10:06PM +0100

On 2016-12-21 19:43, Bonita Montero wrote:
>> bill alone means millions of dollars, it is worth it.
 
> You don't know this. It's just your assumption.
> Homo oeconomicus is just an illusion.
 
I do know actually, because it is a quote from Andrei Alexandrescu from
the time when he worked at Facebook.
 
Starts at 02:55 in https://www.youtube.com/watch?v=MvFj8qo1iuA
 
 
 
Bo Persson
Marcel Mueller <news.5.maazl@spamgourmet.org>: Dec 22 12:07AM +0100

> If you included links to your projects it would be
> more interesting.
 
Hmm, most of them should be used in the PM123 audio player for OS/2.
https://github.com/maazl/pm123/tree/master/src/utils/cpp
xstring.h, smartptr.h:int_ptr<>, container/btree.h and
container/vector.h:vector_int<> are the classes I mentioned.
 
No source code to be very proud of. Most of it is designed for the old
IBM VACPP compiler which did not support STL anyway. But it should be
functional, reasonable fast and memory conserving. Unfortunately this
application was never intended to be portable. I have ports of some
classes to other platforms and languages, but sorry, they are not open
source.
 
 
>> general purpose with as less as possible pitfalls. Performance is not
>> the only criterion.
 
> The containers are the weakest part of the STL in my opinion.
 
You forgot about iostreams, probably. They are even worse. ;-)
 
Compared to some other languages/class libraries the STL containers are
quite orthogonal. The .NET container classes and first of all the
interfaces are higgledy-piggledy.
 
 
Marcel
ruben safir <ruben@mrbrklyn.com>: Dec 21 02:24PM -0500

On 12/21/2016 06:50 AM, Paavo Helde wrote:
> canvas_index is initialized before canvas, because it is declared before
> canvas in the class definition. Thus, it is initialized with garbage.
 
 
thanks.
"Öö Tiib" <ootiib@hot.ee>: Dec 21 01:40PM -0800

On Wednesday, 21 December 2016 14:51:32 UTC+2, F.Zwarts wrote:
 
> Probably, my reaction was too fast. I now see that canvas is not initialized
> in the initialization list, so that the compiler cannot detect the
> non-matching order easily.
 
clang still warns there about uninitialized canvas used to
initialize canvas_index.
Popping mad <rainbow@colition.gov>: Dec 21 08:48PM

:(
 
I don't know. I'm very confused about the behavior of this test program I've been right.
I'm trying to move date by worker threads from one blob of memory to another and the debugger
is saying that the pointers beg and canvas_index is jumping 10 bytes between this two lines
 
for(int i = 0; i < 10;i++)
{
t[i] = std::thread([this]{ readin(beg, canvas_index); });
 
and I'm not sure why. I lost the concurrency somewhere, but can't seem to figure out what I did wrong
 
 
#include <iostream>
#include <thread>
#include <mutex>
std::mutex medco;
std::mutex master;
 
namespace testing{
std::thread t[10];
class PIC
{
public:
PIC():beg{&source[0]}
{
canvas_index = canvas;
std::cout << "Testing Source" << std::endl;
for(int i = 0; i<100; i++)
{
std::cout << i << " " << source[i] << std::endl ;
}
for(int i = 0; i < 10;i++)
{
t[i] = std::thread([this]{ readin(beg, canvas_index); });
std::cerr << i << ": Making a thread" << std::endl;
sync_canvas_and_input();
}
};
 
void sync_canvas_and_input()
{
std::cout << "**LOCKING**" << std::endl;
std::lock_guard<std::mutex> turn(medco);
beg += 10;
canvas_index += 10;
}

~PIC()
{
std::cerr << "In the destructor" << std::endl;
for(int i=0; i<10; i++)
{
t[i].join();
std::cerr << i << ": Joining a thread" << std::endl;
}
 
};
void readin(char * start, char * loc_canvas_index)
{
for( int i = 9; i>=0; i-- )
{
*loc_canvas_index = start[i];
std::cerr << i << ": Copy " << start[i] << std::endl;
std::cerr << i << ": Copied to loc_canvas_index " << reinterpret_cast<char>(*loc_canvas_index) << std::endl;
loc_canvas_index++;
}
Paavo Helde <myfirstname@osa.pri.ee>: Dec 21 11:39PM +0200

On 21.12.2016 22:48, Popping mad wrote:
> {
> t[i] = std::thread([this]{ readin(beg, canvas_index); });
 
> and I'm not sure why. I lost the concurrency somewhere, but can't seem to figure out what I did wrong
 
Who knows. Debuggers sometimes also get confused and display wrong data.
 
Your example is incomplete (truncated?), cannot be compiled and even the
types of beg and canvas_index are not known. So not much can be said
about the code.
 
From the visible code I can only infer that you have not understood why
and how to protect data with mutexes (mutex lock is in one thread only,
and the data apparently protected by the lock (beg, canvas_index) is
not even accessed in the other threads.
 
Also, access to the shared data buffer (canvas) is creating a lot of
false sharing as the slicing size 10 is most probably not divisible by
the cache line size, thus causing potentially significant performance
penalties (probably not important for your toy example, but worth to
mention).
 
Juha Nieminen <nospam@thanks.invalid>: Dec 21 07:08AM

> just that worst case complexity was more likely.
 
No, he didn't claim that.
Gareth Owen <gwowen@gmail.com>: Dec 21 07:28PM

> to poor pivot choice.
 
> Again Mr Flibble didn't claim the former was worse in asymptotic
> complexity just that worst case complexity was more likely.
 
 
"AFAIK quicksort will not work with linked lists;"
"If by "works" you mean "works slowly, O(n)".
"By "O(n)" I actually meant "worse than O(n)*O(lg N)".
 
*******************************************************
***** 'I actually meant "worse than O(n)*O(lg N)"' ****
*******************************************************

I look forward to you Stuckling out of that.
 
[Incidentally, you *actually* meant 'worse than O(N * lg N)']
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 21 07:39PM

On 21/12/2016 07:08, Juha Nieminen wrote:
> leigh.v.johnston@googlemail.com wrote:
>> just that worst case complexity was more likely.
 
> No, he didn't claim that.
 
Yes, he did.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 21 07:43PM

On 21/12/2016 19:28, Gareth Owen wrote:
> ***** 'I actually meant "worse than O(n)*O(lg N)"' ****
> *******************************************************
 
> I look forward to you Stuckling out of that.
 
"Due to poor pivot choice worst case performance will manifest more
often and that is quadratic complexity."
 
So fuck off; I am right and you are wrong.
 
 
> [Incidentally, you *actually* meant 'worse than O(N * lg N)']
 
O(N)*O(lg N) is the same as O(N * lg N) (the latter being a simplification)
 
/Flibble
Ben Bacarisse <ben.usenet@bsb.me.uk>: Dec 21 08:34PM


>> I look forward to you Stuckling out of that.
 
> "Due to poor pivot choice worst case performance will manifest more
> often and that is quadratic complexity."
 
Is this a sociological claim rather than a technical one? There's no
technical reason why the choice of pivot should be a poor one in a
linked list implementation, but the last time that was pointed out your
reply was simply "Nah", so maybe you do still think you are raising a
technical issue about algorithms.
 
<snip>
--
Ben.
Gareth Owen <gwowen@gmail.com>: Dec 21 08:53PM


> "Due to poor pivot choice worst case performance will manifest more
> often and that is quadratic complexity."
 
Not true - Quicksort is O(N log(N)) on average even with the simplest
choice of pivot (the last element).
 
If you believe otherwise, please explain why.
 
> So fuck off; I am right and you are wrong.
 
Not true. Maths isn't a strong point, is it?
Gareth Owen <gwowen@gmail.com>: Dec 21 08:54PM

>>> just that worst case complexity was more likely.
 
>> No, he didn't claim that.
 
> Yes, he did.
 
He claimed both. They're equally wrong.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 21 08:58PM

On 21/12/2016 20:53, Gareth Owen wrote:
 
> Not true - Quicksort is O(N log(N)) on average even with the simplest
> choice of pivot (the last element).
 
> If you believe otherwise, please explain why.
 
From Wikipedia:
 
"Although quicksort can be implemented as a stable sort using linked
lists, it will often suffer from poor pivot choices without random access."
 
https://en.wikipedia.org/wiki/Quicksort
 
 
>> So fuck off; I am right and you are wrong.
 
> Not true. Maths isn't a strong point, is it?
 
This has nothing to do with maths; this is to do with analysing
algorithmic complexity. See Wikipedia above.
 
/Flibble
ram@zedat.fu-berlin.de (Stefan Ram): Dec 21 07:22PM

>For the rest of us "efficient" most often means "getting the app out
>*this* year". Not running 1% faster next year.
 
This is called »productivity«. For productivity, one uses
»Coffee languages«, Java, Python, you name it.
 
»Apps« are also rarely written in C++. There are iOS apps,
Android apps, Web apps, and Windows Store apps. They use
Objective C, Swift, JavaScript, and C#, or - sometimes, but
more rarely - C++.
 
C++ is used when efficiency is more important than productivity.
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)