Messages de LastPhe0nix

Le 09 avril 2021 à 22:17:09 :

Le 09 avril 2021 à 22:12:00 :
I use Arch btw

GG, t'es à la phase 3
https://image.noelshack.com/fichiers/2021/14/5/1617999424-average-life-of-a-linux-user.jpg

Bof, j'ai mon setup Arch qui fonctionne bien sur mon laptop vu que je ne fais que travailler sur ce dernier et vu que le développement est plus simple avec à mon sens.
Pour autant, j'utilise Windows principalement, pour jouer sur mon PC etc parce que je suis pas stupide au point de me mentir à moi même en me disant que c'est équivalent, pour autant j'ai mon WSL (Debian) quand le besoin s'en fait sentir et ça fonctionne très bien.
Bref tout est une question de besoin et j'ai déjà largement dépassé l'étape (4) du retour en arrière, je choisi mon environnement en fonction de mes activités c'est tout

I use Arch btw

Le 08 avril 2021 à 23:44:36 :

Le 08 avril 2021 à 23:42:25 :

Le 08 avril 2021 à 23:37:17 :

Le 08 avril 2021 à 23:33:12 :

Le 08 avril 2021 à 23:27:33 :

Le 08 avril 2021 à 23:21:24 :
Tout le monde est d'accord pour dire que c'est baisé comme conclusion mais la cohérence reste tout de même plus importante...
Et puis il doit y avoir un moyen de concilier les deux sans doute (thread-safe et tableau de booléen), certainement qu'utiliser un std::vector<bool> n'était pas ce que tu voulais faire :p

Ca se ferait que la proxy class utilise un vector<atomic<XXX>> et non un vector<XXX> pour que ça soit safe d'écrire de manière concurrente ? Je connais pas trop les détails (jcrois que atomic fait ça ?)

A priori oui mais du coup tu perds l'optimisation en espace mémoire dans ce cas, à ce niveau autant faire un std::vector<std::uint8_t> et tu fais un static_cast<bool> et static_cast<std::uint8_t> à chaque manipulation (ce qui à la compilation n'aura aucun impact sur l'efficacité du code mais te permet de bypass cette spécialisation nulle).

Je suis sûr que des gens ce sont déjà poser la question sur internet nonobstant et peut-être même qu'un jour une dépréciation (puis supprimation sera discutée) en tout cas j'avais un professeur en master qui faisait parti du comité qui avait cette opinion d'envoyer chier cette merde.

Ah ouais ? Ptet j'ai toujours pas compris cette histoire de vector<bool> alors
Pour moi ya un int qui sert pour plusieurs bool, mais du coup si le int est un atomic<int> alors deux threads qui modifie ce même int (et qui pensent modifier 2 bools différents) vont agir bien non ?
(Edit : je viens peut être de capter. Atomic prends plus de place en mémoire ?)
Mais yep sinon ouais ok

Okok sympa, espérons un jour alors

En fait le soucis c'est que d'habitude la manipulation d'éléments dans le vecteur est "élémentaire" donc pas data-race avec plusieurs threads mais avec bool vu que le proxy se charge d'effectivement trouver le bon bit dans le int qui est stocké derrière et bien il y a un la valeur du bit n'est pas "set" "immédiatement" et de même pour quand tu veux récupérer la valeur d'un bit. C'est cette arithmétique binaire qui cause ce problème de data-racing.

Ce paragraphe (certes en anglais) l'explique problablement mieux:

Concurrent writes to vector<bool> are never ok, because the underlying implementation relies on a proxy object of type vector<bool>::reference which acts as if it was a reference to bool, but in reality will fetch and update the bitfield bytes as needed.

When using multiple threads without synchronization, the following might happen: Thread 1 is supposed to update a bit, and reads the byte containing it. Then thread 2 reads the same byte, then thread 1 updates a bit and writes the byte back, and then thread 2 updates another bit and writes the byte back, overwriting the edit of thread 1.

This is just one possible scenario, there are others that would lead to the same kind of data corruption.

Yep yep mais ma tentative c'était que si derrière c'est un vector<atomic<int>> au lieu d'un vector<int> ptet ça rends le truc magiquement thread safe tout en conservant le bonus de mémoire (mais en perdant en perf)

Selon internet atomic est pas garantit d'avoir la même taille que l'élément normal, mais pour int ça a l'air ok donc jsp

Faudrait que je tente de l'écrire

(J'ai lu ce paragraphe ya 3jours jcrois ahah)

Bah si tu utilises std::vector<std::atomic<int>> ou std::vector<int> il faudra réécrire les opérations arithmétiques intermédiaires pour pouvoir gérer les bits à la main et que tu prévois le caractère thread-safe de ces opérations. Dans le cas ou tu souhaites toujours avoir des booléens compactés au maximum.

Le 08 avril 2021 à 23:42:40 :
<code>#include <iostream>

1. include <atomic>

int main()
{
int a;
std::atomic<int> b;
std::cout << sizeof(a) << std::endl;
std::cout << sizeof(b) << std::endl;
}
</code>
Sur http://cpp.sh/

Donne 4 pour int, et 4 pour atomic<int>

Dooooooooooooooooooooooooooooooooooooonc ptet ça a la même taille

Oui sizeof(bool) = sizeof(std::atomic<bool>) et sizeof(int) = sizeof(std::atomic<int>) mais la spécialisation qui permet de compacter tout tes bool dans un seul int pour ton vecteur n'existe pas avec std::vector<std::atomic<bool>>.

Le 08 avril 2021 à 23:37:17 :

Le 08 avril 2021 à 23:33:12 :

Le 08 avril 2021 à 23:27:33 :

Le 08 avril 2021 à 23:21:24 :
Tout le monde est d'accord pour dire que c'est baisé comme conclusion mais la cohérence reste tout de même plus importante...
Et puis il doit y avoir un moyen de concilier les deux sans doute (thread-safe et tableau de booléen), certainement qu'utiliser un std::vector<bool> n'était pas ce que tu voulais faire :p

Ca se ferait que la proxy class utilise un vector<atomic<XXX>> et non un vector<XXX> pour que ça soit safe d'écrire de manière concurrente ? Je connais pas trop les détails (jcrois que atomic fait ça ?)

A priori oui mais du coup tu perds l'optimisation en espace mémoire dans ce cas, à ce niveau autant faire un std::vector<std::uint8_t> et tu fais un static_cast<bool> et static_cast<std::uint8_t> à chaque manipulation (ce qui à la compilation n'aura aucun impact sur l'efficacité du code mais te permet de bypass cette spécialisation nulle).

Je suis sûr que des gens ce sont déjà poser la question sur internet nonobstant et peut-être même qu'un jour une dépréciation (puis supprimation sera discutée) en tout cas j'avais un professeur en master qui faisait parti du comité qui avait cette opinion d'envoyer chier cette merde.

Ah ouais ? Ptet j'ai toujours pas compris cette histoire de vector<bool> alors
Pour moi ya un int qui sert pour plusieurs bool, mais du coup si le int est un atomic<int> alors deux threads qui modifie ce même int (et qui pensent modifier 2 bools différents) vont agir bien non ?
(Edit : je viens peut être de capter. Atomic prends plus de place en mémoire ?)
Mais yep sinon ouais ok

Okok sympa, espérons un jour alors

En fait le soucis c'est que d'habitude la manipulation d'éléments dans le vecteur est "élémentaire" donc pas data-race avec plusieurs threads mais avec bool vu que le proxy se charge d'effectivement trouver le bon bit dans le int qui est stocké derrière et bien la valeur du bit n'est pas "set" "immédiatement" et de même pour quand tu veux récupérer la valeur d'un bit. C'est cette arithmétique binaire qui cause ce problème de data-racing.

Ce paragraphe (certes en anglais) l'explique problablement mieux:

Concurrent writes to vector<bool> are never ok, because the underlying implementation relies on a proxy object of type vector<bool>::reference which acts as if it was a reference to bool, but in reality will fetch and update the bitfield bytes as needed.

When using multiple threads without synchronization, the following might happen: Thread 1 is supposed to update a bit, and reads the byte containing it. Then thread 2 reads the same byte, then thread 1 updates a bit and writes the byte back, and then thread 2 updates another bit and writes the byte back, overwriting the edit of thread 1.

This is just one possible scenario, there are others that would lead to the same kind of data corruption.

Le 08 avril 2021 à 23:34:08 :
Rien compris mais j'ai rigolé

La pêche avec moi est bonne quand il s'agit de C++

Le 08 avril 2021 à 23:27:33 :

Le 08 avril 2021 à 23:21:24 :
Tout le monde est d'accord pour dire que c'est baisé comme conclusion mais la cohérence reste tout de même plus importante...
Et puis il doit y avoir un moyen de concilier les deux sans doute (thread-safe et tableau de booléen), certainement qu'utiliser un std::vector<bool> n'était pas ce que tu voulais faire :p

Ca se ferait que la proxy class utilise un vector<atomic<XXX>> et non un vector<XXX> pour que ça soit safe d'écrire de manière concurrente ? Je connais pas trop les détails (jcrois que atomic fait ça ?)

A priori oui mais du coup tu perds l'optimisation en espace mémoire dans ce cas, à ce niveau (vis à vis de ce que tu veux faire c'est quasi équivalent à) faire un std::vector<std::uint8_t> et tu fais un static_cast<bool> et static_cast<std::uint8_t> à chaque manipulation (ce qui à la compilation n'aura aucun impact sur l'efficacité du code mais te permet de bypass cette spécialisation nulle).

Je suis sûr que des gens ce sont déjà poser la question sur internet nonobstant et peut-être même qu'un jour une dépréciation (puis supprimation sera discutée) en tout cas j'avais un professeur en master qui faisait parti du comité qui avait cette opinion d'envoyer chier cette merde.

Le 08 avril 2021 à 23:24:43 :
Bah oui tu veux mettre ça où?

Le 08 avril 2021 à 23:25:02 :
La terre est naturellement radioactive

Où est le problème ?

Tout le monde est d'accord pour dire que c'est baisé comme conclusion mais la cohérence reste tout de même plus importante...
Et puis il doit y avoir un moyen de concilier les deux sans doute (thread-safe et tableau de booléen), certainement qu'utiliser un std::vector<bool> n'était pas ce que tu voulais faire :p

La raison de la présence d'une classe "proxy", c'est que std::vector<T>operator[] retourne une référence (non constante pour set | constante pour get) sur T, or si le booléen est optimisé de sorte à ce que tout les bit d'un octet soient occupés alors la référence n'est plus possible (il n'est pas possible d'avoir une référence sur un bit précis cela demande une arithmétique binaire supplémentaire) et donc soit tu passes par un setter (donc pas d'opération d'accès mutable avec l'opérateur "subscript" mais plutôt std::vector<bool>::set(std::size_t index, bool value)) et un getter (lui est trivial), soit tu passes par une classe proxy qui permet de garder la même syntaxe bien que la sémantique intermédiaire soit différente.

Super film !

Le 08 avril 2021 à 22:30:24 :
she is married with an ingeneer.

voila l'erreur

Le 19 mars 2021 à 22:56:14 sam_tucker a écrit :
césure sa veux dire quoi bmg ?

par contre go dictionnaire

Le 19 mars 2021 à 22:50:37 arimarobertcam a écrit :

Le 19 mars 2021 à 22:47:50 Figure1 a écrit :
Si tu peux attendre, prends une année de césure entre ton M1 et M2 en école

Ba une fois lancé en ingé je finirais mon école, mais donc ça paraît pas trop possible ?

Si justement ta césure tu la fais entre la 4ème et 5ème année.

réflexion basse

bah post ta question omg

Le 15 mars 2021 à 21:47:14 LastPhe0nix a écrit :
mp

rien reçu

mp

Je fais une dédi avec lui bien évidement !