Discussion :

[gorgonite]

Jon Harrop évoque une façon possible dans ce message et compare avec OCaml : http://groups.google.com/group/fa.ca...a635a4e876f167

pour infos, pour le moment d'après mes tests avec Mono + F# vs OCaml ; les deux en bytecode

• sur un interpréteur très simple : OCaml gagne haut la main presque 5 fois plus rapide (un calcul stupide pour incrémenter un entier)
• sur un pur travail IO (parsage et export de fichiers texte), F# est légèrement meilleur

je n'ai pas pas fait de calcul numérique pur, mais j'ai un doute sur les perfs... à moins que ce ne soit Mono qui ralentisse le tout

[LLB]

Tu as bien compilé fsc avec -O3 et appelé mono avec --aot ?

La dernière fois que j'avais testé, j'avais écris fibonacci (avec 2 récursions) : le temps obtenu avec F# était identique à du C avec gcc -O3.

Et oui, .NET sous Windows est plus rapide que Mono.
Voici quelques benchmarks : http://cs.hubfs.net/forums/thread/3207.aspx

[gorgonite]

Tu as bien compilé fsc avec -O3 et appelé mono avec --aot ?

-O2 et sans --aot pour rester en mode bytecode

mais je ferais les tests en natif en comparant ocamlopt et "mono natif"

[gorgonite]

Tu as bien compilé fsc avec -O3 et appelé mono avec --aot ?

Et oui, .NET sous Windows est plus rapide que Mono.
Voici quelques benchmarks : http://cs.hubfs.net/forums/thread/3207.aspx

pour infos, sur mon exemple de l'interprète (fsc -O3 --standalone), je me retrouve (sur le même machine en dual boot), avec un mono légèrement plus rapide que .net pour windows ... et je n'avais pas fait --aot
avec le --aot, on ne gagne "que" 10%
EDIT : cela serait normal

4. F# programs were built using VS 2005 release mode on Windows XP. Mono version was 1.2.2.1 with flag --optimize=all. The ahead of time compiler was not used because fsc produces .NET 2.0 assemblies for which aot doesn't work (apparently, I'm no Mono expert).

et OCaml bytecode continue de prendre un facteur 5 à F#
et OCaml en natif prend un facteur 4 au OCaml en bytecode

[gorgonite]

Salut,


J'ai toujours un doute au sujet de mes perfs... suis-je un cas pathologique pour F# ?

Après avoir refléchi et demandé autour de moi, il semble qu'il peut y avoir plusieurs hypothèses :

• mon prototype n'étant pas parfait, je suis obligé de ne pas dépasser un certain nombre de récursion dans mes boucles du pseudo-langage... à savoir 6000 en F# (et plus de 60 000 en OCaml).
  
  • temps de chargement de la CLR
  • garbage collector
• sinon n'ayant pas voulu me taper les indices de De Bruijn, et une gestion optimisée de mes environnements, j'ai joué avec une Hashtbl... F# utilise une HashMultiMap .Net ; peut-être OCaml a-t-il des Hashtbl plus performants (ayant moins de fonctionnalités ?)

[LLB]

Le type HashMultiMap correspond au type Hashtbl de Caml, c'est-à-dire une table de hachage où on peut avoir une liste de valeurs correspondant à une clé. A priori, c'est équivalent et je ne vois pas de raison qui justifierait une différence de performances.

Si ton code F# n'a pas besoin d'être compatible Caml et si tu ne veux qu'une valeur par clé, tu peux utiliser le type System.Collections.Generic.Dictionary.

Le temps de chargement de la CLR n'a aucune raison d'être long. Lances-tu fréquemment des exceptions (elles sont vraiment beaucoup plus lentes en F# qu'en Caml) ?

Tu as testé les performances sous Windows ?

[gorgonite]

Si ton code F# n'a pas besoin d'être compatible Caml et si tu ne veux qu'une valeur par clé, tu peux utiliser le type System.Collections.Generic.Dictionary.

je vais justement me refaire mon module environment en me basant là-dessus... ce sera d'ailleurs l'occasion de faire un code un peu plus modulaire qui pourra choisir le type de structure de stockage interne, tant qu'il y a la même interface

va falloir attendre ce soir pour les résultats...

au passage, la Fsharp 1.9.4.17 sortie le 19 Mai est-elle plus déboguée que celle du 1er Mai ? car je n'avais pas pu l'utiliser avec Mono

Le temps de chargement de la CLR n'a aucune raison d'être long. Lances-tu fréquemment des exceptions (elles sont vraiment beaucoup plus lentes en F# qu'en Caml) ?

comparé à OCaml, .Net se charge lentement... dixit mon directeur de thèse (ou alors j'ai pas compris ce qu'il me disait )

j'ai des exceptions à chaque création d'une variable non déclarée (car j'appelle la fonction assign qui tente un replace, capture l'exception et effectue le add)
mais mon exemple est "explicit", et donc mes variables sont prédéclarées

j'utilise aussi une exception pour rattrapper un break dans mes boucles, mais je n'en ai pas dans mon prog de test

donc a priori aucune exception dans mon code...

Tu as testé les performances sous Windows ?

ben oui, et c'est plus lent qu'avec Mono (même machine évidemment )

un mono légèrement plus rapide que .net pour windows

EDIT : au fait, as-tu une explication sur le fait que j'ai 10 fois plus vite un Stack Overflow avec F# qu'avec OCaml bytecode ?

[LLB]

au passage, la Fsharp 1.9.4.17 sortie le 19 Mai est-elle plus déboguée que celle du 1er Mai ? car je n'avais pas pu l'utiliser avec Mono

Non, aucune différence.

J'ai testé et j'ai seulement eu à ajouter le flag "--runtime=v2.0.50727". Pour le mode interactif, j'ai fait un patch qui devrait corriger le problème rencontré.

Installe une version récente de Mono et teste avec fscp10.exe. Tu as quoi comme erreur ?

comparé à OCaml, .Net se charge lentement...

Oui, c'est fort possible. Mais si le temps d'exécution depasse quelques secondes, le temps de chargement devient négligeable. Quand tu fais un benchmark, tu lances bien le programme pendant au moins 5 secondes ?

EDIT : au fait, as-tu une explication sur le fait que j'ai 10 fois plus vite un Stack Overflow avec F# qu'avec OCaml bytecode ?

C'est bizarre, tu mets quoi sur ta pile ?

[gorgonite]

pour FSharp 1.4.9.15 sorti le 1er Mai, j'ai tout essayé et rien à voulu passé sous Mono (version 2.0**** dispo sous Ubuntu Hardy)

Oui, c'est fort possible. Mais si le temps d'exécution depasse quelques secondes, le temps de chargement devient négligeable. Quand tu fais un benchmark, tu lances bien le programme pendant au moins 5 secondes ?

l'exécution avec .net dure

• 6 sec sous windows vista et FSharp 1.4.9.15
• 5 sec sous Mono et FSharp 1.3.????
• 4/4.5 sec sous Mono avec --aot
• 0.8/1 sec sous OCaml bytecode
• 0.2 sec sous OCamlopt

j'aurais préféré augmenté la durée des calculs car pour OCaml s'est trop rapide pour que les tests soient représentatifs... mais F# m'en empêche

C'est bizarre, tu mets quoi sur ta pile ?

j'ai "juste" une fonction non tail-recursive dans mon interprète pour la gestion des boucle while... car j'avais pas trop le temps et que OCaml surpportait bien l'opération de manière efficace

[gorgonite]

je vais justement me refaire mon module environment en me basant là-dessus... ce sera d'ailleurs l'occasion de faire un code un peu plus modulaire qui pourra choisir le type de structure de stockage interne, tant qu'il y a la même interface

va falloir attendre ce soir pour les résultats...

côté généricité, je suis parti me rhabiller... en raison de l'absence de foncteur ^^
je pense qu'il va falloir que je définisse une interface avec des méthodes publiques statiques, et que je tente de simuler un foncteur par ce biais


sinon, j'ai réussi à trouver du temps pour interfacer Dictionary, et avoir la même interface d'utilisation que Hashtbl... et je n'ai pas vraiment gagné en vitesse sous vista (un peu plus rapide que le mono de la version précédente )
et je n'ai rien gagné côté nombre d'itérations possibles

[LLB]

Je viens de tester une bête fonction de Fibonacci (double récursion), sur FreeBSD. Avec Fibonacci 38 :

Ocamlc :
4.51s user 0.01s system 99% cpu 4.547 total
Ocamlopt :
0.89s user 0.00s system 99% cpu 0.888 total
F# 1.9.4.17 et Mono 1.9.1 :
1.16s user 0.02s system 85% cpu 1.378 total


Test de la pile : fonction récursive avec un entier en argument. Le nombre indique le nombre approximatif d'appels récursifs.

Ocamlc : 65000
Ocamlopt : 8283000
F# : 104000

Test de la pile : fonction récursive avec un entier et une fonction en argument.

Ocamlc : 52000
Ocamlopt : 5553000
F# : 74000

Pour la généricité, demande si tu as des problèmes.