Il faut regarder comment la mémoire virtuelle est gérée. Et côté CPU, regarder ce qu'est le TLB.
En fait, l'OS présente un espace mémoire à chaque appli. Cet espace mémoire semble contigu, mais l'OS le découpe en morceaux de 4k (lié à ce que le CPU sait gérer). Chaque fois que l'application veut lire en mémoire, il faut vérifier dans quel morceaux de 4k cela tombe, si ce morceaux est en mémoire ou sur le disque, si l'application a le droit d'y lire, écrire, ...
Donc quand on parcourt un tableaux, tous les 4k l'appli est interrompue pour que l'OS vérifie tout cela, fasse en sorte que la mémoire soit là, ...
Quand on fait du traitement de données et qu'on tape partout dans la RAM, on est interrompu plein de fois, mais heureusement le CPU a des mécanismes pour que les pages les plus récentes soient plus rapides à accéder.
C'est normalement transparent pour une appli lambda.
Le problème, c'est que 4ko, c'est trop juste maintenant. On a des mécanismes pour avoir des pages plus grandes, mais c'est très spécifique à certaines applis et ça demande de taper dans l'OS: on est moins portable.
Une solution serait de passer à des pages de 16ko, 64ko. C'est possible sur certains ARM, à ma connaissance pas sur PC, et c'est déjà un boost pour le traitement (y compris pour le javascript).
Par contre, quand on fait de l'émulation, certaines fonctionnalités pointues sont liées à ces pages, et les limites sont souvent compilées dans le code, impossibles à retrouver. Donc un soft très optimisé comme un jeu, une BDD, risque de ne pas fonctionner sur un OS dont les pages sont de taille différente. Emuler la détection de ces limites est extrêmement coûteux (cela revient à checker logiciellement chaque accès mémoire...)
Pour résumer: * Un passage du x86 à l'ARM avec la même taille de page: on peut émuler sans trop se poser de questions * Un passage du x86 à l'ARM avec un taille de page inférieure: on peut émuler sans trop se poser de questions, mais on perd en perfs * Un passage du x86 à l'ARM avec un taille de page supérieure: on peut émuler des trucs simples ... mais il y a des limites, des risques, mieux vaut se focaliser sur le natif et les runtimes type Java/C#
Après lecture des commentaires, et bien, j'ai pas compris. Quelqu'un a une ou des vidéos qui vulgarise bien l'interaction cpu, os, pages, mémoire, (et un peu compilation, mais sur ce dernier, je commence à être en terrain connu) ? Siouplé :)
Dans la page des titres, cette petite troncature qui fait plaisir :
Encrypted File System (EFS) : explorons les possibilités du système de chiffrement des fichiers sous Windows La sécurité au prix du sang Dans notre quête (sans fin) pour la protection de nos petites données personnelles, de nombreuses pistes s’offrent à nous, plus ou moins con... (3 commentaires - Lire)
Je suis dev Java et je dois de temps en temps faire un peu de Typescript avec Angular.
C’est moi ou ce language (Javascript y compris) est super compliqué ? Entre la lib rxjs asynchrone et toutes les tournures syntaxiques moderne du language, je trouve que la courbe d’apprentissage est assez rude au début.
C’était mon ressenti aussi, grosse claque au début pour un projet serverless partant de rien. Agréablement surpris des différentes possibilités offertes par la techno et le language. Après 6 mois, retour dans du vieux Java, et j’avoue que le retour arrière est un peu rude.
Je partage ce raisonnement hélas. Même s’il n’y a pas de petite écologie, il faut faire le cycle complet du carbone de ce système qui ne sera que très peu rentable énergétiquement en regard de l’énergie nécessaire à produire le panneau et toute l’électronique qui va avec. Le calcul de Fred42 est fait avec des approximations optimum de rendement et déjà comme ça, le gain effectif d’autonomie est très faible donnant la tendance quant à l’utilité de cette mesure. Tout ceci n’empêche par contre pas de continuer la recherche sur de meilleurs batteries et panneaux PV
Je ne peux qu’appuyer vos dires hélas :-( Avec un système de recrutement (en imaginant qu’il y ait des postes hein) complétement b(i)aisé Raisons pour lesquelles je suis parti en courant aussi
Ca a commencé avec les LIDD, puis je me suis rendu compte qu’il y avait aussi des gens qui travaillaient aussi sur pcINpact puis nextinpact et qu’accessoirement, le travail effectué est sympa et de qualité. Bref, tout ça explique le suivi de ce journal :)
25 commentaires
Le 29/06/2024 à 20h29
Cette chute
Le 27/04/2024 à 12h57
Le 26/04/2024 à 06h49
Quelqu'un a une ou des vidéos qui vulgarise bien l'interaction cpu, os, pages, mémoire, (et un peu compilation, mais sur ce dernier, je commence à être en terrain connu) ? Siouplé :)
Le 13/02/2024 à 09h53
Le 10/08/2023 à 18h30
(Open)ZFS -> OZFS -> OZEF ?
(L’heure du jeu de mot pourri)
Le 26/07/2023 à 07h43
Le 05/06/2023 à 13h42
Dans la page des titres, cette petite troncature qui fait plaisir :
Le 21/03/2023 à 08h04
C’était mon ressenti aussi, grosse claque au début pour un projet serverless partant de rien. Agréablement surpris des différentes possibilités offertes par la techno et le language. Après 6 mois, retour dans du vieux Java, et j’avoue que le retour arrière est un peu rude.
Le 17/02/2023 à 06h20
C’est le sous-titre qu’il faut pour l’article
Le 09/11/2022 à 13h20
Je partage ce raisonnement hélas.
Même s’il n’y a pas de petite écologie, il faut faire le cycle complet du carbone de ce système qui ne sera que très peu rentable énergétiquement en regard de l’énergie nécessaire à produire le panneau et toute l’électronique qui va avec.
Le calcul de Fred42 est fait avec des approximations optimum de rendement et déjà comme ça, le gain effectif d’autonomie est très faible donnant la tendance quant à l’utilité de cette mesure.
Tout ceci n’empêche par contre pas de continuer la recherche sur de meilleurs batteries et panneaux PV
Le 01/11/2022 à 07h34
Je ne peux qu’appuyer vos dires hélas :-(
Avec un système de recrutement (en imaginant qu’il y ait des postes hein) complétement b(i)aisé
Raisons pour lesquelles je suis parti en courant aussi
Le 12/05/2022 à 07h23
pffffiouuuuuu, j’ai eu peur de gagner ce concours et d’épuiser mon quota de chance pour les 20 ans
A + dans un an ^^
Le 05/05/2022 à 17h21
Packs en mai ?? Ah oui, il y aura des packs en juin aussi ?
Bon anniv ! :)
Le 21/09/2021 à 20h46
Merci pour ces précisions :)
Le 16/09/2021 à 07h08
Oh ben ça se refuse pas :)
Le 06/09/2021 à 16h10
“pas moins de 140 000 lignes de code rédigées en assembleur pour ce projet”
Engagez-vous qu’ils disaient, rengagez-vous !
Le 06/09/2021 à 12h48
un commentaire sous cet article
Le 01/09/2021 à 10h45
Eh ben le brief d’aujourd’hui, c’est plutôt le breach
Le 08/03/2021 à 15h37
Vers l’infini et au plumard
Le 03/03/2021 à 08h50
Depuis 6 mois avec l’offre de base, ça marche plutôt bien leur système, j’espère qu’ils arriveront à rester
Le 12/10/2020 à 08h00
Trop mangé, mais elle était bonne cette raclette :)
J’ai raté un truc ?
Le 06/07/2018 à 08h49
Ca a commencé avec les LIDD, puis je me suis rendu compte qu’il y avait aussi des gens qui travaillaient aussi sur pcINpact puis nextinpact et qu’accessoirement, le travail effectué est sympa et de qualité. Bref, tout ça explique le suivi de ce journal :)
Le 06/04/2017 à 13h58
A la vue de la qualité du travail que fournit cette équipe (DaTaGueule, 2° avant la fin du monde) :
Hop, projet soutenu sans hésiter !
Le 07/07/2015 à 13h41
J’aurais plutôt dit le Guetta PAN !
Le 27/01/2015 à 11h09
Une question bête, mais, le salaire de base est de combien ??