Google affirme qu'il est facile de remplacer C/C++ par Rust dans les firmwares

Envoy� par fdecode

...

Reste qu'apparemment, il n'est pas possible de tout faire en Rust et certain projet comme construire une librairie Rust semble carr�ment impossible, l'algorithme de la racine carr�-inverse rapide ne semble pas non plus pouvoir �tre tol�r�e par le compilateur (sp�culatif, je n'ai pas essay� ; mais �tant donn� qu'il faille jouer avec les diff�rents motifs m�moire fonction du types des nombres, en Rust �a doit �tre un enfer) ; la compilation est affreusement lente quand il faut r�cup�rer tous les paquets Cargo pour un gros projet. Franchement pass� la hype, je ne vois pas comment Rust pourrait avoir une trajectoire diff�rente d'Ocaml ou Haskell, c'est un truc d'universit�/laboratoire qui ne semble pas pouvoir s'adapter � la r�alit� des entreprises.

Envoy� par 23JFK

Reste qu'apparemment, il n'est pas possible de tout faire en Rust et certain projet comme construire une librairie Rust semble carr�ment impossible, l'algorithme de la racine carr�-inverse rapide ne semble pas non plus pouvoir �tre tol�r�e par le compilateur (sp�culatif, je n'ai pas essay� ; mais �tant donn� qu'il faille jouer avec les diff�rents motifs m�moire fonction du types des nombres, en Rust �a doit �tre un enfer) ; la compilation est affreusement lente quand il faut r�cup�rer tous les paquets Cargo pour un gros projet. Franchement pass� la hype, je ne vois pas comment Rust pourrait avoir une trajectoire diff�rente d'Ocaml ou Haskell, c'est un truc d'universit�/laboratoire qui ne semble pas pouvoir s'adapter � la r�alit� des entreprises.

Cela a l'air tr�s personnels et �motionnels comme griefs. Je vais simplement r�pondre � la demande concr�te de votre message: "algorithme de la racine carr�-inverse rapide" (de quake, je suppose).
Dans la mesure o� c'est un algorithme de calcul tr�s approximatif, et que l'instruction SSE RSQRT existe d�sormais, il me para�t assez peu int�ressant, mais il a quand m�me �t� facile de trouver un exemple d'impl�mentation [playground]:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
fn inv_sqrt(x: f32) -> f32 {
    let i = x.to_bits();
    let i = 0x5f3759df - (i >> 1);
    let y = f32::from_bits(i);
 
    y * (1.5 - 0.5 * x * y * y)
}
 
 
fn print_both(v: f32) {
    println!("quake: {}", inv_sqrt(v));
    println!("real:  {}", 1.0 / v.sqrt());
    println!();
}
 
fn main() {
    print_both(4.0);
    print_both(10.0);
    print_both(3.1415);
}

Ceci-dit, le code de quake n'est pas tr�s int�ressant puisque le calcul exact tient en 3 instructions machine.

Envoy� par 23JFK

Reste qu'apparemment, il n'est pas possible de tout faire en Rust et certain projet comme construire une librairie Rust semble carr�ment impossible

Je vais supposer que tu t'es mal expliqu� parce qu'il est �vident que Rust peut faire des biblioth�ques. Le d�p�t standard de Rust contient plus de 150 000 crates dont la plupart sont des biblioth�ques.
Si tu voulais parler de biblioth�que qui s'interface avec d'autre langages, c'est aussi possible, � condition d'avoir une interface qui respecte l'ABI C. C'est en effet limitant, mais c'est pareil pour tout les langages qui veulent s'interfacer avec d'autres.

Envoy� par 23JFK

l'algorithme de la racine carr�-inverse rapide ne semble pas non plus pouvoir �tre tol�r�e par le compilateur (sp�culatif, je n'ai pas essay� ; mais �tant donn� qu'il faille jouer avec les diff�rents motifs m�moire fonction du types des nombres, en Rust �a doit �tre un enfer) ;

C'est un peu le probl�me, beaucoup de gens ont un avis tr�s tranch� sur Rust, bas� sur des sp�culations fausses. Rust peut tout � fait faire des manipulations de bit basiques, c'est juste que les hacks comme les conversions douteuses ou les d�passement volontaires, sont remplac�s par des fonctions explicites pour �tre sur qu'ils sont fait � dessein et que ce n'est pas des erreurs.

Envoy� par 23JFK

la compilation est affreusement lente quand il faut r�cup�rer tous les paquets Cargo pour un gros projet.

�a c'est vrai, mais pour le coup on ne compile pas un gros projet de z�ro si souvent que �a. Quand on recompile un projet sur lequel on travaille, �a va beaucoup plus vite. �a reste plus lent que le C mais pas vraiment plus lent que des langages plus complexes comme le C++.

Envoy� par fdecode

Ceci-dit, le code de quake n'est pas tr�s int�ressant puisque le calcul exact tient en 3 instructions machine.

Il me semble que la racine inverse rapide est encore pas mal utilis�e dans la 3D, l�approximation �tant relativement bonne et le gain sensible. Toutes les instructions machines ne se valent pas, 3 instructions complexes, peuvent prendre plus de cycles qu'une dizaine d'instructions plus simples.

Apr�s v�rification, la racine inverse rapide est environ 2,5 fois plus rapide sur ma machine.

Envoy� par Uther

Apr�s v�rification, la racine inverse rapide est environ 2,5 fois plus rapide sur ma machine.

Je n'ai pas fait de tests de performance pour ma part.
Le r�sultat de la compilation (en release) aboutit � �a:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
.LCPI4_0:
	.long	0xbf000000
 
.LCPI4_1:
	.long	0x3fc00000
 
inv_sqrt_quake:
	movd	%xmm0, %eax
	shrl	%eax
	movl	$1597463007, %ecx
	subl	%eax, %ecx
	movd	%ecx, %xmm1
	mulss	.LCPI4_0(%rip), %xmm0
	mulss	%xmm1, %xmm0
	mulss	%xmm1, %xmm0
	addss	.LCPI4_1(%rip), %xmm0
	mulss	%xmm1, %xmm0
	retq
 
.LCPI5_0:
	.long	0x3f800000
 
inv_sqrt:
	sqrtss	%xmm0, %xmm1
	movss	.LCPI5_0(%rip), %xmm0
	divss	%xmm1, %xmm0
	retq

Donc 10 instructions pour la m�thode rapide contre 3 instructions pour la m�thode exacte.
Toutefois, la m�thode rapide n'utilise pas de division ni d'op�ration racine carr�e.

Ceci-dit, si je devais vraiment l'impl�menter pour ma part, j'inlinerais l'instruction rsqrtss.

C'est pour �a que le nombre d'instruction machine n'est pas une m�trique suffisante pour mesurer la performance. Il faut aussi avoir une bonne id�e de l'efficacit� des instructions. Et encore le nombre de cycle d'une instruction peut varier en fonction du contexte.

Les instructions de division et de racines carr�e sont connues pour �tre lentes. Toute l'int�r�t de l�algorithme de Quake, c'est qu'il n'utilise rien de plus complexe que la multiplications.

Envoy� par Uther

C'est pour �a que le nombre d'instruction machine n'est pas une bonne m�trique pour mesurer la performance. Il faut aussi avoir une bonne id�e de l'efficacit� des instruction. Et encore le nombre de cycle d'une instruction peut varier en fonction du contexte.

Les instructions de division et de racines carr�e sont connues pour �tre lentes. Toute l'int�r�t de l�algorithme de quake, c'est qu'il n'utilise rien de plus complexe que la multiplications.

Bon, pour compl�ter ma r�ponse, voici une variante qui utilise l'instruction sse rsqrt.
C'�tait plus facile que je ne le pensais. Je n'ai pas eu besoin d'inliner de l'assembleur (Playground) :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
 
mod inner {
    #![allow(unused)]
    #[cfg(target_arch = "x86")]
    use std::arch::x86::*;
    #[cfg(target_arch = "x86_64")]
    use std::arch::x86_64::*;
    #[target_feature(enable = "sse")]
    pub unsafe fn inv_sqrt_sse(four_floats: [f32;4]) -> [f32;4] {
        let reg: __m128 = bytemuck::cast(four_floats);
        let inv_sqrt4 = _mm_rsqrt_ps(reg);
        bytemuck::cast(inv_sqrt4)
    }
}
 
#[no_mangle]
fn inv_sqrt_sse(four_floats: [f32;4]) -> [f32;4] {
    unsafe { inner::inv_sqrt_sse(four_floats) }
}
 
#[no_mangle]
fn inv_sqrt_quake(x: f32) -> f32 {
    let i = x.to_bits();
    let i = 0x5f3759df - (i >> 1);
    let y = f32::from_bits(i);
 
    y * (1.5 - 0.5 * x * y * y)
}
 
#[no_mangle]
fn inv_sqrt(x: f32) -> f32 {
    1.0 / x.sqrt()
}
 
 
fn print_both(v: f32) {
    println!("quake: {}", inv_sqrt_quake(v));
    println!("real:  {}", inv_sqrt(v));
    println!();
}
 
fn main() {
    print_both(4.0);
    print_both(10.0);
    print_both(3.1415);
 
    println!("sse features");    
    if is_x86_feature_detected!("sse") {
        let f_4 = [4.0, 10.0, 3.1415, 2.0];
        let sf_4 = inv_sqrt_sse(f_4);
        for (f,sf) in f_4.into_iter().zip(sf_4) {
            println!("rsqrt({f}) = {sf}");
        }
    }
}

J'utilise des fonctions du core Rust pour l'architecture x86 (par cons�quent, non compilable sur d'autres architectures). Cela se programme en unsafe : l� on touche � des choses plut�t nightly pour l'instant. Bien s�r, ces quelques lignes unsafe ne sont pas UB.
Dans quelques ann�es (ou mois), ces fonctions de calcul SIMD seront pleinement accessibles en safe et en stable.
Voici le code compil� de la fonction bas�e sur l'architecture sse:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
 
inv_sqrt_sse:
	movq	%rdi, %rax
	movups	(%rsi), %xmm0
	rsqrtps	%xmm0, %xmm0
	movups	%xmm0, (%rdi)
	retq

Mais m�me apr�s cet exemple, il va encore y avoir quelqu'un qui va m'�crire que 'Rust ne permet pas de faire de l'optimisation de code', 'parce qu'on ne peut pas travailler bit � bit', 'qu'on n'acc�de pas aux subtilit�s du code machine', ♫♫♫♬ etc.

Envoy� par fdecode

...

Ou que l'on oblig� de faire de l'unsafe et l'unstable.

Envoy� par 23JFK

Ou que l'on oblig� de faire de l'unsafe et l'unstable.

Et bien non! Il ne vous a pas �chapp� si vous �tes all�s sur le Playground, que le code en question fonctionne dans une version stable de Rust:

Ce qui est nighty, c'est la librairie SIMD, pas les instructions machines r�pliqu�es dans le core Rust.

Pour ce qui est de l'unsafe, il est tout naturellement utilis� ici pour inclure du code machine, donc ext�rieur � Rust, tout comme on utilise de l'unsafe pour inclure une librairie C : cela sert � isoler les parties du code non contr�l�es par la s�mantique de s�curisation de Rust. Il s'agit pour le coup du contexte d'utilisation le plus simple de l'unsafe: d�limiter le code externe. Pas de risque d'UB. Vous ne risqueriez donc pas d'y perdre des dents.

Envoy� par fdecode

...

D�sol�, mais dans le code d'en haut, from_bits() semble tagu� unstable.

Envoy� par 23JFK

D�sol�, mais dans le code d'en haut, from_bits() semble tagu� unstable.

f32::from_bits est stable depuis Rust 1.20.0. C'est le fait que cette fonction soit const (l'�quivalent de constexpr en C++) qui n'est pas encore stable.

Envoy� par 23JFK

D�sol�, mais dans le code d'en haut, from_bits() semble tagu� unstable.

En compl�ment de la r�ponse de Pyramidev:

https://doc.rust-lang.org/book/appen...htly-rust.html

Unstable Features

There�s one more catch with this release model: unstable features. Rust uses a technique called �feature flags� to determine what features are enabled in a given release. If a new feature is under active development, it lands on master, and therefore, in nightly, but behind a feature flag. If you, as a user, wish to try out the work-in-progress feature, you can, but you must be using a nightly release of Rust and annotate your source code with the appropriate flag to opt in.

If you�re using a beta or stable release of Rust, you can�t use any feature flags. This is the key that allows us to get practical use with new features before we declare them stable forever. Those who wish to opt into the bleeding edge can do so, and those who want a rock-solid experience can stick with stable and know that their code won�t break. Stability without stagnation.

This book only contains information about stable features, as in-progress features are still changing, and surely they�ll be different between when this book was written and when they get enabled in stable builds. You can find documentation for nightly-only features online.

Autrement dit, il n'est pas possible d'utiliser des composants nightly dans une configuration stable de Rust. Le fait que le playground soit ex�cut� en mode stable impose donc que tout le code utilis� soit stable.

Il existe des moyens de contourner cette r�gle, mais un tel crime est tout � fait d�conseill� :

https://crates.io/crates/nightly-crimes

J'ai test� cette macro de Mara Bos et elle semble toujours fonctionner (mais pas son exemple, puisque la syntaxe exp�rimentale box value a �t� abandonn�e).

Marrant, je savais qu'on pouvait contourner l'interdiction d'utiliser les fonctionnalit�s nightly, mais je pensais que le seul moyen �tait d'utiliser une variable d�environnement non document�e.
Je savais pas que c'�tait possible avec une simple macro m�me si elle est tordue, pour le coup �a ressemble plut�t a un bug.

Envoy� par Uther

pour le coup �a ressemble plut�t a un bug.

Un bug qui date de 3 ans, sachant qui est Mara Bos?

https://www.rust-lang.org/governance...ership-council

Non, je ne pense pas que ce soit un bug, ou alors, c'est consid�r� comme mineur. Peut-�tre une tol�rance qu'ils rendront inutilisable un jour.

Bonus:

https://marabos.nl/atomics/

https://cppcast.com/rust_lt_eq_gt_cpp/

Je sais qui est Mara Bos, mais il y a des bugs bien plus vieux et plus impactants que �a dans le compilateur qui ne sont pas encore corrig�s car ils impliqueraient une refonte technique complexe et qu'on consid�re improbable de les d�clencher sans faire expr�s.
Le plus connu �tant le bug https://github.com/rust-lang/rust/issues/57893 qui permet de faire un transmute sans bloc unsafe. En th�orie il casse compl�tement la s�curit� de Rust mais vu que le code qui peut d�clencher le probl�me n'a pas vraiment de sens dans du code normal, il n'est pas consid�r� urgent et attend la refonte du borrow checker � venir.

Au vu du code tordu de la crate de Mairia Bos, j'ai l'impression qu'on est bien dans cette cat�gorie.

Envoy� par Uther

Je sais qui est Mara Bos, mais il y a des bugs bien plus vieux et plus impactants que �a dans le compilateur qui ne sont pas encore corrig�s car ils impliqueraient une refonte technique complexe et qu'il sont consid�r�s impossible � d�clencher sans faire expr�s.
Le plus connu �tant le bug https://github.com/rust-lang/rust/issues/57893 qui permet de faire un transmute sans bloc unsafe. En th�orie il casse compl�tement la s�curit� de Rust mais vu les condition improbables pour le d�clencher, il n'est pas consid�r� urgent et attend la refonte du borrow checker a venir.

Excellent! Je ne connaissais pas!

En relisant plus attentivement, ce n'est en effet pas un bug mais une exploitation particuli�rement gore des macro proc�durales et de la variable d�environnement non document�e dont je parlais.

En gros le code du projet qui contient la macro est transform� en un sous projet et le projet en cours deviens un script de compilation qui va compiler le sous-projet avec la variable d�environnement secr�te qui permet d'ignorer l�interdiction. Bref une horreur a �viter.

Envoy� par Uther

En relisant plus attentivement, ce n'est en effet pas un bug mais une exploitation particuli�rement gore des macro proc�durales et de la variable d�environnement non document�e dont je parlais.

En gros le code du projet qui contient la macro est transform� en un sous projet et le projet en cours deviens un script de compilation qui va compiler le sous-projet avec la variable d�environnement secr�te qui permet d'ignorer l�interdiction. Bref une horreur a �viter.

Je n'ai pas eu le temps de lire le code, mais je me doutais d'un truc comme �a.
Les macros proc�durales permettent des choses vraiment tordues, et il faut s'astreindre � ne pas c�der � la tentation.
Moi il m'�tait arriv� de m'�garer � associer une macro proc�durale avec un serveur pour certaines historisations et contr�les de m�tadonn�es (e.g. g�rer certaines constantes associ�es � des types) lors des compilations. C'�tait une vraie machine � gaz, surtout quand on utilisait en plus l'analyseur syntaxique de l'IDE.