Le topic de la programmation: Et envoyez des sioux!

[Garrluk]

Le RAII, le concept c'est que la chose est planquée dans les classes et que dans les codes utilisateurs tu n'a plus à t'en soucier. Mais ça ne veut pas dire que tu ne peux pas construire des classes avec new et delete à l'intérieur si ?

Non bien sûr, la RAII ne permet pas de se passer d'allocation, mais quand tu en as vraiment besoin, plutôt que d'écrire new, tu écris : auto instance = std::make_unique... (comme dit par Kamikaze 2 postes plus haut).
Comme ça pas besoin de t'embêter à gérer les durées de vies des variables, c'est le langage qui le fait pour toi.

Et le but de la RAII, ce n'est pas de cacher des allocations, c'est d'utiliser la pile plutôt que le tas, même si en pratique ça sert aussi à ça.

[Nilsou]

Tu ne peux pas mettre des unique_ptr partout, et les autres types de smart pointeurs ont un cout. ( qui peut être assez embêtant si on va dans les détails, voir ici par exemple : )

edit : (raaaa, le fofo qui continue avec ce bug ou quoi qu'on fasse il interprète les balise URL comme des VIDEO quand c'est du vimeo, allez savoir ...)

De fait, ça reste pas déconnant de faire des classes avec des new et delete dans de nombreux cas je pense.

La question du recruteur est évidemment une question de base, mais elle reste pertinente même aujourd'hui je pense.

[gros_bidule]

Ca me fait rigoler, j'ai l'impression de revoir des évaluations techniques en Java / Spring Boot où l'on te pose des questions hype pointues sur le fonctionnement d'une JVM (genre donner toutes les zones et sous-zones mémoires, pas juste expliquer la heap et non-heap), ou des questions sur Spring... enfin du Spring Framework (pas Boot donc) 3 ou 4 avec de la config de beans en xml. Plus aucun dev ne fait ça, on a bien plus simple et efficace, ça ne te servira pas au boulot et dans le pire des cas (maintenance d'un projet Spring du néolithique) tu passeras 10min sur Google pour te rafraîchir la mémoire. Mais visiblement il y a des gens qui pensent que ça fait de toi un expert. Expert peut être, mais expert en quoi, ça je ne sais pas. Et pendant ce temps, les compétences utiles sur un projet, on n'en parle pas.

[Anonyme20240202]

Expert peut être, mais expert en quoi, ça je ne sais pas. Et pendant ce temps, les compétences utiles sur un projet, on n'en parle pas.

Voilà, exactement.

@Nilsou, nan mais vraiment y'a jamais besoin, la majorité du temps tu manipules la mémoire via des structures qui effectivement font du new delete, mais toi jamais explicitement:

#include <iostream>
#include <vector>

class Mange {
public:
    explicit Mange() { la_sauce.resize(1024ULL*1024ULL*1024ULL); }
    void balance() { std::cout << "dodu: " << la_sauce.size() << std::endl; }
private:
    std::vector<std::byte> la_sauce;
};

int main() {
    Mange vazy{};
    vazy.balance();
    std::cin.ignore();
}

- - - Mise à jour - - -

Ici tas 1 gig alloué, 1 gig libéré et tu touches jamais à new delete, la lib gère la mémoire avec du memset et autre effectivement

[Nilsou]

J'ai vu pas mal de programme avec des structures de données qui virevoltaient dans tout les sens parce que le but était assez complexe (notamment dans les programmes scientifiques) où je pense que ce serait un enfer sans new et delete dans les classes.

Je comprends ton exemple, et je comprends que ça fasse la majorité des usages, surtout quand on se fiche un peu des perfs exactes (quand on ne code pas en embarqué, en scientifique ou sur des trucs comme des moteurs de jeux en JV) mais je maintient qu'il reste plein de cas ou tout bon programmeur doit connaitre l'usage de new et delete...

[gros_bidule]

Mais est-ce que c'est grave s'il est capable de les apprendre plutôt une fois en poste ? Est-ce que le savoir à la base, ça change bcp les choses ?

Parfois en entretien on me reproche (ou je fais l'erreur de reprocher) de ne pas connaître un truc. Mais ce truc c'est un détail qui se maîtrise en 5min, ou une techno que tu apprendras vite. Et on ne peut pas se targuer de tout connaître. Un bon dev, il évolue.
Donc modifier la façon d'allouer la mémoire, n'est-ce pas juste une histoire de convention à appliquer, et donc d'habitude à prendre sur le projet ? Demain tu passes sur un autre projet et on va te dire nan mais allo, nous on fait du Rust, ton C il est inutilement compliqué.

[Cwningen]

En vrai tu pourrais aller aux alentours de plusieurs milliards mais là ça serait une indication que tu dois changer de design (utiliser des threads ou autre).

La limite de threads systèmes est-elle beaucoup plus élevée que la limite de processus ? Si c'est vraiment trop grand il vaut mieux rassembler les taches sur un pool plus limité de threads, non ? Ou tu parlais de threads utilisateurs ?

[Garrluk]

Justement, pour l'avoir vu dans un certain nombre de code scientifiques/HPC, faire des new/delete à tout bout de champs est une super mauvaise idée niveau performance.
Surtout que jusqu'en 2018 (je crois ?), il y avait toujours un mutex global sur la gestion de la mémoire dans la libc standard, donc dès que t'es sur un programme multithreadé, et que tu ne compiles pas avec un compilateur récent, tu le paies super cher en perfs.

D'ailleurs, si vous êtes bloqués sur une vieille version de clang/gcc, n'hésitez pas à utiliser tcmalloc (https://github.com/google/tcmalloc).
C'est un drop-in replacement pour la gestion mémoire de la libc, c'est super simple à compiler et à utiliser et en général ça permet des gains de performances assez important pour un coût de dev nul (il suffit de rajouter tcmalloc.so dans le LD_PRELOAD avant d’appeler son exécutable).
Sur la plupart des codes clients, juste faire ça nous donnait déjà des speed-up débiles, genres x2, avant même qu'on commence à rentrer dans le code.

[vectra]

>gros_bidule.

J'ai reparlé du test qu'on m'avait fait faire en C++ pour mon job actuel. Un test assez bateau, il faut dire.
Ben mes collègues m'ont expliqué que plein de candidats l'ont foiré dans les grandes largeurs, ce qui, dans ce cas précis, montre qu'ils ont raté l'entièreté des chapitres essentiels du langage.
C'était a priori même pas de l'incompétence, mais juste des gens qui ont pris l'habitude d'encadrer et de négocier, et ont vraiment trop perdu le contact avec la technique. Or je suis là en tant que dev: même avec une capacité d'apprentissage et des lacunes, y'a certaines lacunes dures à justifier à un moment.

- - - Mise à jour - - -

using (MyClass* instance = new MyClass())
{
}

De rien.

Il y a une différence par rapport à

{
   MyClass instance;

   // blabla
   // delete
}

?

[Anonyme20240202]

La limite de threads systèmes est-elle beaucoup plus élevée que la limite de processus ? Si c'est vraiment trop grand il vaut mieux rassembler les taches sur un pool plus limité de threads, non ? Ou tu parlais de threads utilisateurs ?

Oui et non c'était mal formulé de ma part, je disais ça dans le cas (hypothétique, je sais pas ce qu'il fait) où il abuse de process.send pour faire des boulots concurrents parce qu'il connait pas encore le multithreading.

- - - Mise à jour - - -

Enfin vu que je connais rien à Node ça se trouve c'est idiot de ma part de parler de multithreading.

Mais en gros je dis ça car j'ai souvent vu des débutants vouloir faire des trucs concurrents, et dans ce cas là ils prennent le premier truc qui fonctionne et qui leur tombe sous la main plutôt que de suivre "la pratique appropriée"

Genre des débutants qui se retrouve à faire de la communication inter process (IPC), gestion de signal, etc. (extrêmement casse gueule) alors qu'ils veulent juste 2 trucs concurrents en gros

- - - Mise à jour - - -

Et effectivement pour node faut voir le scenario car:

Every node.js process is single threaded by design. Therefore to get multiple threads, you have to have multiple processes

Je vois mal ce qui justifierai 100 process, c'est p'têt légitime mais faut voir pourquoi

- - - Mise à jour - - -

Potentiellement ça ressemble aussi à quelqu'un qui connait pas async

[FB74]

P'tite question...

Si vous voulez monter un service en ligne qui est censé attirer, disons 300-500 000 abonnés, avec une utilisation réelle (journalière) de peut-être 50 à 80 000 personnes (visiteurs uniques), est-ce qu'il vaut mieux être propriétaire de son propre hébergement (serveurs) ou est-ce que les prestataires actuels sont suffisants pour la taille visée ?

[Anonyme20240202]

Qu'est ce que t'entends par "prestataires actuels" vs "propre hébergement" ?

1) Solution classique, payer un service de web hosting
100 000 visiteurs par jour tu peux t'attendre à payer entre 10 et 20 euros par mois chez la plupart des société qui font du web hosting grosso merdo. Et ça sera une machine virtuelle sur un serveur physique qui host d'autres machine virtuelles. Si tu payes un peu plus tu auras accès à plus de traffic.

Et souvent t'as plein de trucs préfaits pour avoir un magasin, un forum, un blog wordpress, etc. etc.

2) Web serveur à la maison
Je pense que c'est aussi largement faisable à la maison, il faudra que tu trifouilles ton router, achète un domaine etc. mais ça dépend de ton fournisseur d'accès concernant le traffic possible, là où je suis avec la fibre je suis sûr que ça passerait tranquille. Et ça peut être assez dangereux si tu ne sais pas ce que tu fais (tu rends une machine physique chez toi accessible aux méchants d'internet)

3) Payer un service (de web hosting) pour une machine physique (plutôt cher et overkill)
Sinon tu peux avoir un serveur physique dédié, c'est comme la machine virtuelle en terme d'utilisation mais c'est vraiment une machine pour toi, en gros (et ça coute significativement plus cher). Mais ça me parait overkill

[gros_bidule]

Cela dépend aussi de la fréquentation et ce qu'implique l'activité. A titre d'exemple, un gros site de cashback dont je tairai le nom, ayant 1M d'abonnés, dont 100 000 actifs, générait au total "3 clics par seconde". Donc question : que coûte un clic en moyenne et dans le cas critique ? Clic de navigation, clic de finalisation de commande, etc. Ca conditionne le nombre de serveurs et leur puissance, plus une éventuelle modulation de la puissance si la demande en ressources est variables (soldes...).
Toujours à titre de comparaison, le projet Chèque Energie du gouvernement (6M de foyers fiscaux, + des pros, donc plus de 6M d'utilisateurs actifs sur une courte période chaque année), il se trouve que ça se gère avec autant de ressources que le site plus haut, alors qu'il y a 60x plus d'utilisateurs actifs.

Donc quand je lis XXX users, j'ai envie de dire que l'essentiel c'est de jauger le service sur une petite base utilisateur, puis calculer le passage à l'échelle, + les emmerdes qui vont avec.

[Anonyme20240202]

Ouais c'est une bonne remarque.

Genre si tu fais un site à la youtube. Un seul mec qui regarde une video 4k 60fps coute autant (grosso merdo hein, tu vois l'idée) que 100'000 utilisateurs qui se connectent à une page html "Hello World".

D'ailleurs généralement à chaque fois qu'un mec rafraichit "Hello World" ça va souvent se contenter de recharger depuis le cache donc ça va même pas aller toucher ton serveur.
Genre quand tu vois mon avatar (ou une image quelconque) sur CanardPC souvent c'est stocké localement sur ton PC, ça la charge depuis le PC et pas depuis canardpc.com

Donc si c'est un service "passif" où les gens lisent des trucs ça coute moins, si c'est un service qui prend une requete utilisateur et répond avec du contenu, là c'est plus compliqué

[FB74]

En fait je pensais (juste une idée à la con) un site de rencontre, donc typiquement des profils à regarder et sans doute des tchats/ MP internes entre 2 utilisateurs.

Pas de vidéos, des photos, mais quand même pas mal d'interactions.

[Anonyme20240202]

Ouais là typiquement ça peut grimper extrêmement vite. Si tu autorises les gens à avoir 2/3 photos de profil par exemple, même si tu limites à une taille raisonnable. Tu vas te retrouver avec un grand nombre d'uploads vers ton serveur et de download pour les gens qui visitent les profils.

Le texte des messages pareil, il va falloir que tu le stocke côté serveur et ça va rapidement faire un volume conséquent.

Le truc c'est de calculer tout ça, s'pas trop dur.

Exemple pour commencer:
Tu définis le nombre de photo par utilisateur (3), la taille max d'une photo (100KB). Le nombre d'uploads max par jour (10).

3*100*10*100000 = 300 GB / jour. Maxi (worst case scenario) en upload, on va dire pareil en down

Pour les messages tu dois également définir le volume max de texte par utilisateur par jour et la durée pendant laquelle tu conserves un message (historique).

Disons 1MB (beaucoup pour du texte)/jour, stocké 7 jours, 1*7*100000 ~ 100 GB par jour, 700GB de stockage total à avoir + 300 GB de tof ça fait 1 TB de stockage total, sûrement 2 pour avoir de la redondance.

Donc ces chiffres sont pas trop énormes, mais bien sûr j'ai simplifié et j'oublie p'têt des évidences, mais là on s'orienterait sûrement plus vers des offres business.

De ce que je vois c'est plus vers 30/50 par mois mais j'ai un peu la flemme de lire les offres en détails.

Genre ici: https://www.hostpapa.ca/web-hosting-plan/

Ils disent tout illimité pour 25/mois mais y'a sûrement des asterisk partout avec des limitations à la con

[FB74]

Je te remercie.

C'était juste pour avoir une idée "grossière" de ce qu'il était possible d'avoir.

Je pensais juste à une façon (que je n'ai jamais vue avant) pour rapprocher les profils.

Je n'en parlerai pas ici.

[Robix66]

Ah oui la grande idée qui est tellement bien qu'on ne peut pas en parler, un classique.

[FB74]

Ah oui la grande idée qui est tellement bien qu'on ne peut pas en parler, un classique.

[Cwningen]

1 Mo c'est un très gros roman. Il faut être motivé pour écrire tout ça (et même pour le lire) en une seule journée.

[gros_bidule]

Une photo grandeur nature d'un kiki en ascii-art (ou utf8-art en fait, faut vivre avec son temps), ça chiffre vite

Après y'a des bases qui peuvent stocker le texte en compressé (je pense par ex à MariaDB et Mongodb (WiredTiger) qui ont des moteurs de db qui font ça), et le texte naturel ça se compresse ultra bien, mais je serais curieux de voir les perfs des recherches fulltext, ne serait-ce pour la modération. Pas essayé en tous cas.

[Cwningen]

🍆 c'est 4 octets en UTF-8.

- - - Mise à jour - - -

? c'est 4 octets en UTF-8.

- - - Mise à jour - - -

Merde j'ai tué le forum avec mon aubergine, j'arrive plus à éditer le message.

- - - Mise à jour - - -

Merde j'ai tué le forum avec mon aubergine, j'arrive plus à éditer le message.

[gros_bidule]

(et tu as tué le Reply With Quote sur ton message, ça mouline à l'infini )

[Anonyme20240202]

J'ai dit "c'est beaucoup pour du texte"! Ningen qui fait pas attention§§§ Et en plus il hacke le forum en jouant avec l'encoding, modobell direct!!!

🔥🔥🔥🔥🔥🔥🔥

- - - Mise à jour - - -

J'ai dit "c'est beaucoup pour du texte"! Ningen qui fait pas attention§§§ Et en plus il hacke le forum en jouant avec l'encoding, modobell direct!!!

???????

- - - Mise à jour - - -

Ouais c'est bien l'encoding qui pose problème hahaha, ce grand classique

- - - Mise à jour - - -

Ouais c'est bien l'encoding qui pose problème hahaha, ce grand classique

[Lazyjoe]

Justement, pour l'avoir vu dans un certain nombre de code scientifiques/HPC, faire des new/delete à tout bout de champs est une super mauvaise idée niveau performance.

Je connais quelqu'un qui fait entre autres du consulting pour refactorer du code C++, de son expérience c'est "on passe les premiers jours à virer tous les new/delete du code (et la majorité des constructeurs/destructeurs explicites), ça nous fait souvent un *2 sur la perf, et après on commence à réfléchir sur comment on peut vraiment optimiser".

[Lazyjoe]

De fait, ça reste pas déconnant de faire des classes avec des new et delete dans de nombreux cas je pense.

La question du recruteur est évidemment une question de base, mais elle reste pertinente même aujourd'hui je pense.

Le point c'est aussi de déléguer un maximum la gestion de la mémoire aux classes fournies par le langage plutôt que réinventer la roue, car on peut tabler que la STL fasse mieux le taf que tout ce qu'on pourrait faire à la main.

Jouer avec des new/delete c'est aussi prendre un risque élevé de fuite de mémoire.

Utiliser les pointeurs va aussi très facilement casser les optims du compilateur.

Bref ça n'a essentiellement que des désavantages, et si on est réellement obligé d'utiliser des new/delete ça indique surtout une mauvaise conception architecturale.

[FB74]

Même si je ne connais pas le C++, c'est clair qu'il y a toujours des classes, des routines, bref des tas de choses qui ont déjà été pensées ... et en bien mieux qu'on ne pourra faire !

[Cwningen]

Même si on ne trouve pas ce qu'on veut dans les bibliothèques. Il vaut mieux laisser l'usage de new/delete à un petit nombre de classes et appliquer la Règle de zéro au maximum d'autres classes.

Et c'est valable pour toutes les ressources en fait, pas seulement pour la gestion mémoire (le C++ manque cruellement d'un unique_resource dans sa bibliothèque standard).

[Anonyme20240202]

Haha aujourd'hui c'était le pompon, j'ai eu le droit à 4h de test, avec un sujet hyper soporifique. Pour le coup j'ai rempli le truc sans aucun respect par moment, on verra ce qu'ils en pensent ça va être marrant.

Encore une fois les mecs m'embauchent pour un truc moderne, mais la moitié des questions c'est du C et c'est ennuyeux à mourir.

> Un truc sur la collision de véhicules en mouvement, pourquoi pas, c'était des maths, rien de dingue, le moins débile du lot.
> Ensuite un fabuleux "chunk upload multithreadé" d'un fichier. Va vraiment, mais alors vraiment falloir m'expliquer l'avantage de faire ça de manière multithreadé, je suis à peu près certain qu'un seul thread ira aussi vite mais bon.
Le bottleneck c'est la vitesse de lecture du disque et le réseau, et en plus ils sous entendaient que c'était des petits fichiers, y'a vraiment un truc qui a du m'échapper dans l'intention ou alors c'était une question de merde (je penche pour ça, en input t'as un fichier et un nombre de threads).
Bref, j'ai partitioné les données du fichier en morceaux indépendants et chaque thread upload sa partie en chunk, inintéressant au possible.
> Rentrer un buffer binaire dans une struct et mettre la struct sous forme binaire, j'adore ça, c'est ma joie.
> Ecrire dans un fichier avec un formattage à la con, lire depuis le fichier, vérifier le format, vérifier les dates que t'as parsé (achevez moi).
> Parsing de log (mais oui j'adore ça, allez y), là le respect est mort, j'ai sorti 2 one liner en bash qui font ce qui est demandé, autre chose à faire

Mais ça pas mal coupé l'envie pour cette boite (je suis sûr plusieurs boites en ce moment, intéressant de voir les différents process de recrutement selon la boite)

[gros_bidule]

Upload multithreadé : peut être le type a été traumatisé par ces sites de téléchargement qui limitent le débit par slot, et que tu contournes avec des logiciels qui splittent des DL pour leurrer ces sites. Enfin ça date tout ça quand même. Et en effet, pas besoin de véritables threads pour ça

Les autres questions... J'imagine que ça filtre les gens qui sortent de l'école. C'est déjà pas mal, cela dit. Mais si ça fait fuir les bons... bah ils auront un mec moyen, puis vala. Leurs projets ne nécessitent peut être pas davantage après tout. Ou pas. Mais ils pourraient prévenir avant de coller un test : cherche expert bien payé pour projet d'envergure, ou cherche dev lambda modèle ESN-3291 pour projet lambda de qualité passable. Ca éviterait de perdre du temps avec ces conneries.