Monday, October 4, 2021

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

Bonita Montero <Bonita.Montero@gmail.com>: Oct 04 06:55PM +0200

Am 04.10.2021 um 18:36 schrieb Branimir Maksimovic:
>> }
 
> Talking about efficiency :P
> Who will pay you for overcomplicating simple things?
 
Why should this be overcomplicated ? Im repeatedly copy a
file into a buffer until it is full; maybe not even once
fully if the file doesn't fit in the buffer's maximum size.
That's the most direct way.
Marcel Mueller <news.5.maazl@spamgourmet.org>: Oct 04 09:59PM +0200

Am 03.10.21 um 16:00 schrieb Bonita Montero:
>> I did several tests with __builtin_prefetch to reduce the collision
>> rate in lock free algorithms. ...
 
> Why should a lockfree algorithm employ prefechting ?
 
Prefetch can access invalid memory. So prefetching a shared memory area
behind a pointer can significantly decrease the probability of failed
CAS when implementing strong thread safety. But on some platforms I
observed excessive cachline hopping with this strategy.
 
 
Marcel
Branimir Maksimovic <branimir.maksimovic@icloud.com>: Oct 04 08:22PM

> file into a buffer until it is full; maybe not even once
> fully if the file doesn't fit in the buffer's maximum size.
> That's the most direct way.
take a look at this simple and professionaly done
program that does all that :P
(Ian Collins I think is AUTHOR :P
#include <map>
#include <unordered_map>
#include <iostream>
#include <fstream>
#include <algorithm>
#include <iomanip>
using namespace std;
using Pairs = unordered_map<string,int>;
 
void fill( Pairs& pairs, char c )
{
static string word;
 
if( ispunct(c) ) return;
 
if( isspace(c) )
{
if( word.size() )
{
pairs[word]++;
word.clear();
}
}
else
{
word += tolower(c);
}
}
 
int main()
{
ifstream bible {"bible.txt"};
 
using citerator = istreambuf_iterator<char>;
 
Pairs pairs;
 
for_each( citerator(bible.rdbuf()), citerator(),
[&pairs]( char c ){ fill( pairs, c ); } );
 
multimap<unsigned,string> sorted;
 
// Sort the {word, count} pairs.
//
for_each( pairs.begin(), pairs.end(),
[&sorted]( const Pairs::value_type& p )
{ sorted.insert(make_pair(p.second,p.first)); } );
 
// Print the top 20.
//
auto item = sorted.rbegin();
 
for( auto n = 0; n < 20; ++n, ++item )
{
cout << "Position " << setw(2) << n+1
<< ": count = " << setw(6) << item->first
<< " " << item->second << '\n';
}
 
return 0;
}
 
--
 
7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp
scott@slp53.sl.home (Scott Lurndal): Oct 04 05:08PM

>>system - it gives you 128-bit quad double, but it is likely to be
>>implemented in software rather than hardware.
 
>ARMv8 has 128-bit floating point, in hardware.
^ registers
 
It does not support 128-bit float point types.
David Brown <david.brown@hesbynett.no>: Oct 04 08:04PM +0200

On 04/10/2021 13:50, Bonita Montero wrote:
 
> Most compilers map long double to IEEE-754 double precision and not
> extended precision. Even with Intel C++ you must supply a compiler
> -switch that you have double as a extended precision.
 
No, you don't.
 
>> same size as "double".  That's true for most 32-bit (and smaller)
>> targets.  Most 64-bit targets support larger "long double".
 
> No, most don't.
 
Yes, they do.
 
Again, you are confusing "Windows" with "everything".
 
MS, for reasons known only to them, seem to have decided that "long
double" should be 64-bit in the Windows ABI (noting that there never was
a real ABI for 32-bit Windows). So Intel's compiler /on windows/ will
use 64-bit "long double" by default. It uses 80-bit "long double" on
other x86-64 targets (they are actually 16 bytes in size, for alignment
purposes, but 80 bits of data).
 
MSVC for ARM has 64-bit "long doubles" even on 64-bit ARM, other 64-bit
ARM targets have 128-bit (I don't know off-hand if they are IEEE quad
precision). For RISC-V, even 32-bit targets have 128-bit "long double".
Bart <bc@freeuk.com>: Oct 04 08:22PM +0100

On 04/10/2021 18:08, Scott Lurndal wrote:
 
>> ARMv8 has 128-bit floating point, in hardware.
> ^ registers
 
> It does not support 128-bit float point types.
 
So it doesn't support float512 to float2048 in hardware? I thought that
sounded far-fetched.
 
But if it's just a matter of registers of 128+ bits (which can store a
vector of smaller float types), then that's old hat with x86/x64.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 04 10:07AM -0700

On 10/4/2021 8:50 AM, Öö Tiib wrote:
 
>> Have you posted the entire code for your dual_monitor algorihtm?
 
> BMs threads are busily spinning when nothing to do so
> it is hard to find utilization to it (besides of as bad example).
 
I am interested in look at her full code for dual_monitor. Also, this
thread has a lot of interesting information in it. Well, imvho...
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 04 10:08AM -0700

On 10/4/2021 4:50 AM, Bonita Montero wrote:
 
>>> Because the code is simple.
 
>> Have you posted the entire code for your dual_monitor algorihtm?
 
> You won't understand it.
 
Why not? I need to see the whole thing instead of just
dual_monitor::wait... See?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Oct 04 11:31AM -0700

On 10/2/2021 1:27 AM, Bonita Montero wrote:
 
>> I am talking about the nice fast-path being totally lock/wait-free. It
>> can! Think about it some more.
 
> Lock-free is when you only have a fast path - and no slow path.
 
Why not combine the two? Ahhh, the futex, or eventcount.
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)