64b - Gestion de la mémoire dans nos Smarthpone

[Corematrix]

Bien sûr même si les instructions 64 bits vous semble superficielle, il y a bien un intérêt qui se fera sentir tôt ou tard.

[stipus]

Bien sûr même si les instructions 64 bits vous semble superficielle, il y a bien un intérêt qui se fera sentir tôt ou tard.

Déjà c'est beaucoup plus rapide pour nombre de calculs. Par exemple pour une simple addition, on a en simplifiant:

- Un ordinateur 32 bits est capable en 1 cycle d'horloge d'additionner 2 nombres codés sur 32 bits. Si ces nombres sont des entiers longs (sur 64 bits), l'ordinateur va faire une suite d'opérations (un peu comme on ferait une addition à la main, avec les retenues..etc). Donc un paquet de cycles d'horloge sont nécessaires.

- L'ordinateur 64 bits ajoutera ces deux entiers longs en 1 cycle d'horloge. D'où un gain énorme à fréquence d'horloge équivalente. D'où aussi un gain sur l'autonomie...

Ensuite il est possible simplement d'accéder à plus de 4 Go de mémoire, ce qui sera utile dans quelques temps vu que certains appareils ont déjà 3 Go de RAM. Inutile de mettre en place des mécanismes de pagination, comme ceux de MS-DOS en son temps pour accéder à plus de 1 Mo de mémoire...

Et enfin pour accéder aux gros fichiers par des méthodes modernes (Memory Map), il n'y a plus aucun problème car l'espace d'adressage est immense, et il est donc possible de mapper de nombreux gros fichiers dans l'espace de mémoire virtuelle. Avec un ordinateur 32 bits, si on a 2 Go de RAM, on ne pourra pas accéder à un fichier de plus de 2Go à l'aide de memory maps (et encore on sera limités avant).

[tfpsly]

Déjà c'est beaucoup plus rapide pour nombre de calculs. Par exemple pour une simple addition, on a en simplifiant:

- Un ordinateur 32 bits est capable en 1 cycle d'horloge d'additionner 2 nombres codés sur 32 bits. Si ces nombres sont des entiers longs (sur 64 bits), l'ordinateur va faire une suite d'opérations (un peu comme on ferait une addition à la main, avec les retenues..etc). Donc un paquet de cycles d'horloge sont nécessaires.

- L'ordinateur 64 bits ajoutera ces deux entiers longs en 1 cycle d'horloge. D'où un gain énorme à fréquence d'horloge équivalente. D'où aussi un gain sur l'autonomie...

Non ce n'est pas aussi compliqué sur 32 bits : c'est un ADD32 suivi d'un ADDC32, au lieu d'un ADD64. Une petite instruction de plus. Face au temps gaspillé dans les attentes mémoires et autre LHS, ce n'est RIEN.
Ensuite c'est inutile 99,9999999% du temps : les calculs sur des entiers de plus de quelques milliards sont très rares.

Ensuite il est possible simplement d'accéder à plus de 4 Go de mémoire, ce qui sera utile dans quelques temps vu que certains appareils ont déjà 3 Go de RAM. Inutile de mettre en place des mécanismes de pagination, comme ceux de MS-DOS en son temps pour accéder à plus de 1 Mo de mémoire...

Oui, ce sera utile... Dans quelques années.
Et pour info, la mémoire est toujours paginée, par les tables de descripteurs en mode protégé. Juste que les pages mémoire sont bien plus larges.

Avec un ordinateur 32 bits, si on a 2 Go de RAM, on ne pourra pas accéder à un fichier de plus de 2Go à l'aide de memory maps (et encore on sera limités avant).

Souvent plutôt 4go, pas 2 Mais ça dépend des O/S.

[Gandalflux]

Vous savez je trouve tous ça extrèmement intéressant à t'elle point que ça m’étirerais un Topic à lui seul

[stipus]

Déjà c'est beaucoup plus rapide pour nombre de calculs. Par exemple pour une simple addition, on a en simplifiant:

- Un ordinateur 32 bits est capable en 1 cycle d'horloge d'additionner 2 nombres codés sur 32 bits. Si ces nombres sont des entiers longs (sur 64 bits), l'ordinateur va faire une suite d'opérations (un peu comme on ferait une addition à la main, avec les retenues..etc). Donc un paquet de cycles d'horloge sont nécessaires.

- L'ordinateur 64 bits ajoutera ces deux entiers longs en 1 cycle d'horloge. D'où un gain énorme à fréquence d'horloge équivalente. D'où aussi un gain sur l'autonomie...

Non ce n'est pas aussi compliqué sur 32 bits : c'est un ADD32 suivi d'un ADDC32, au lieu d'un ADD64. Une petite instruction de plus.

Deux instructions au lieu d'une = double de temps. Ce n'est pas rien.

Face au temps gaspillé dans les attentes mémoires et autre LHS, ce n'est RIEN.

Là par contre OK.

Ensuite c'est inutile 99,9999999% du temps : les calculs sur des entiers de plus de quelques milliards sont très rares.

Tout entier stocké stocké sur un int64, et dans les programmes actuels, il y en a de plus en plus, même si ce n'est pas la majorité. Donc tu exagères quand même énormément sur ton pourcentage. Tout dépend du programme.

Ensuite il est possible simplement d'accéder à plus de 4 Go de mémoire, ce qui sera utile dans quelques temps vu que certains appareils ont déjà 3 Go de RAM. Inutile de mettre en place des mécanismes de pagination, comme ceux de MS-DOS en son temps pour accéder à plus de 1 Mo de mémoire...

Oui, ce sera utile... Dans quelques années.
Et pour info, la mémoire est toujours paginée, par les tables de descripteurs en mode protégé. Juste que les pages mémoire sont bien plus larges.

Je ne te parlais pas de la mémoire virtuelle gérée par page, mais de mécanismes de pagination qui permettent d'accéder à de la mémoire non addressable, à l'époque au dessus d'1 Mo, mais c'est transposable à accéder à de la mémoire au dessus de 4Go sur un système 32 bits.... en gros un bloc de mémoire est recopié par le système dans l'espace addressable, dans ce qu'on appelle une fenêtre... On ne peut donc accéder qu'à un bloc à la fois. Heureusement nous n'aurons pas cette galère à gérer grâce à l'adressage sur 64 bits.

Avec un ordinateur 32 bits, si on a 2 Go de RAM, on ne pourra pas accéder à un fichier de plus de 2Go à l'aide de memory maps (et encore on sera limités avant).

Souvent plutôt 4go, pas 2 Mais ça dépend des O/S.

Je dis que la machine a déjà 2 Go de RAM mappés dans son espace virtuel 32 bit de 4 Go maximum. Donc il ne reste que 2 Go pour mapper d'autres trucs.... Mais tu as raison ça dépend des OS... par exemple sur IOS en 32 bits on est limités à 370 Mo environ, car l'espace virtuel est fragmenté, et qu'il ne reste pas de trou de plus de 370 Mo.

[stipus]

Le code de base (en assembleur ARM) est le suivant:

add_64
STMDB sp!,{v1,lr}
LDR v1,[a2,#0]
MOV a4,v1,LSR #31
LDR ip,[a3,#0]
MOV lr,ip,LSR #31
ADD ip,v1,ip
STR ip,[a1,#0]
MOV ip,ip,LSR #31
LDR a2,[a2,#4]
LDR a3,[a3,#4]
ADD a2,a2,a3
TST a4,lr
CMPEQ a4,ip
MOVNE a3,#1
MOVEQ a3,#0
ADD a2,a2,a3
STR a2,[a1,#4]!
LDMIA sp!,{v1,pc}

Une fois optimisé on obtient:

add_64
LDR a4,[a2,#0]
LDR ip,[a3,#0]
ADDS a4,a4,ip
STR a4,[a1,#0]
LDR a2,[a2,#4]
LDR a3,[a3,#4]
ADC a2,a2,a3
STR a2,[a1,#4]
MOV pc,lr

[edit] Message corrigé grâce à la vigilence de tpsfly concernant la retenue !

[stipus]

A partir du 1 Février 2015, Apple n'acceptera plus de nouvelles applications qui ne seraient pas compilées en 64-bit dans l'App Store...

http://appleinsider.com/articles/14/10/20/apple-to-require-64-bit-support-from-all-ios-apps-starting-in-february

[Betekaa]

et à priori aucun changement sur la vitesse

[stipus]

et à priori aucun changement sur la vitesse

Bien sûr que si

[FGO]

FGO

[Betekaa]

bandes de clowns

http://www.tomshardware.fr/articles/app ... 54669.html

Les développeurs ont 3 mois et demi devant eux pour se mettre en règle, ce qui semble assez confortable. Pour les utilisateurs, la migration devrait au mieux se traduire par de légers gains de performance, mais dans la plupart de cas elle devrait rester invisible.

mais bon, on sait, FGO, que chaque ibidule répond instantanément tout en étant plus rapide que le précédent : back to the future

[FGO]

Arrestes tu t'enfonce tout seul

et à priori aucun changement sur la vitesse

Pour les utilisateurs, la migration devrait au mieux se traduire par de légers gains de performance, mais dans la plupart de cas elle devrait rester invisible.[/i]

Quand on utilise pleinement son smartphone/tablette de léger gain se ressentent sur certaines applications gourmandes en ressource mais si tu fais juste des mails la effectivement tu ne remarqueras rien du tout effectivement.
ca permet aussi des gains sur la consommation et en performance de calcul sur les appli en ayant besoin, et aussi ca nécessite moins de mémoire qu'en 32 bits.

FGO

[FGO]

un exemple du passage de 32 à 64, ca ne se remarque pas effectivement ...



FGO

[Betekaa]

de l'encodage sur un smartphone

26%, phénoménal

[stipus]

Si Apple a décidé de tout passer en 64-bit, c'est qu'ils ont une bonne raison .... ça permet effectivement de grappiller quelques % de rapidité, quelques % d'autonomie... et en optimisant ainsi à droite et à gauche pourcent après pourcent, ils finissent par avoir une machine qui avec un processeur à 1.5GHz explose ses concurrents tournant à 2.2GHz, aussi bien en performance qu'en autonomie...