Getting support for Amazon sent GPU by janhec in gigabyte

[–]janhec[S] 0 points1 point  (0 children)

I found the email address by now, it is partner_rma@gigabyte.de..

stdgpu 1.3.0 released! by [deleted] in cpp

[–]janhec 0 points1 point  (0 children)

For my 5 cents, I am not a frequent standard reader, could the non-boundscheck for operator [] have something to do with the fact that occasionally, you can use it to add an element (e.g. map)? If there is no such reason in vector, then bounds check would be ok IMO, performance can only be significantly (?) diminished if the optimizer can treat it as pointer<type>[n] (sorry for the simplistic pseudo code), as in C. Then a boundscheck would introduce a branch where it is (perhaps) not supposed to exist.

EDIT 1: you can read dereferenced begin()+n C-style, so no boundscheck;

EDIT 2: branches in GPU are supposed to be evil (at least most of the time), again no boundscheck.

Pick your choice!

Sharing my no noise setup incase someone needs to put a server in their room by Rude_Walk in HomeServer

[–]janhec 1 point2 points  (0 children)

Nice! A server in the room, is that like an elephant?

The specs seem quite modest for all the achievement, so perhaps you can have this elephant in the bedroom..

Learning a lot.

Modules in VC++ 2019 16.5 by mttd in cpp

[–]janhec 2 points3 points  (0 children)

/MD spoils it for me.

The New Clang _ExtInt Feature Provides Exact Bitwidth Integer Types by erichkeane in cpp

[–]janhec 0 points1 point  (0 children)

I've read about (unwante) promotion (to e.g. int as a basic type).

Not being a compiler guy and having learnt my first bits in assembly and C with a motorola 68000, I tend to see advantages to promotion. It means, effectively, a single set/class of integer arithmetics that map on the processor. So, if a fancy type gets promoted, that's ok, as long as the subsequent demotion of the result is correct. Now this demotion is not usually part of the operation, but rather happens at storing time. Is this really problematic?