• [^] # Re: AWK en RUST

    Posté par (site web personnel, Mastodon) . En réponse au lien Performance comparison: counting words in Python, Go, C++, C, AWK, Forth, and Rust. Évalué à 2.

    Je viens d'aller voir la page des performances de frawk et j'ai adoré son disclaimer :

    The abundance of such claims notwithstanding, I've found it is very hard to precisely state the degree to which an entire programming language implementation is or is not efficient. I have no doubt that there are programs in frawk that are slower than equivalent programs in Rust or C, or even mawk or gawk (indeed, see the "Group By Key" benchmark). In some cases this will be due to bugs or differences in the quality of the language implementations, in others it will be due to bugs or differences in the quality of the programs themselves, while in still others it may be due to the fact that in some nontrivial sense one language allows you to write the program more efficiently than another.

    I've found that it can be very hard to distinguish between these three categories of explanations when doing performance analysis. As such, I encourage everyone reading this document to draw at most modest conclusions based on the numbers below. What I do hope this document demonstrates are some of frawk's strengths when it comes to some common scripting tasks on CSV and TSV data

    AWK est un DSL prévu pour les fichiers DSV simples de l'époque (le fichier /etc/passwd en est un exemple) alors qu'aujourd'hui le CSV qui s'utilise de plus en plus en plus est loin de cette simplicité+régularité (non seulement, contrairement au sigle, ce n'est pas la virgule qui est forcément utilisée, mais les différents séparateurs peuvent se retrouver dans les champs qui doivent en plus être entourés etc.) À l'inverse, frawk veut adresser d'entrée cette complexité déjà discutée ici. Il est donc bien vu d'avoir xsv et tsv-tools dans le comparatif puisque ceux-ci sont sur le créneau visé. Ceci dit, le CSV utilisé pour ses tests n'est pas des plus complexes, mais nécessite plus de taf (comme je l'ai mentionné dans un autre commentaire, ce sont dans ces cas que xsv et tsv-utils peuvent sembler intéressant, pour ne pas devoir investir plus de temps et d'énergie en développement supplémentaire)

    Benchmarks for the TREE_GRM_ESTN dataset are not run on CSV input with mawk or gawk, as it contains quoted fields and these utilities do not handle CSV escaping out of the box. We still run them on the TSV versions of these files using \t as a field separator.

    Les awk présentés sont écrits sans hack et donc pourront être utilisés avec d'autres implémentations d'une part, et les performances observées avec les implémentations et versions utilisées n'exploitent pas leurs spécificité (gawk par exemple a quelques ajouts qui font que la réécriture peut donner des résultats plus bluffants mais cela ne sera malheureusement pas portable, contrairement à la forme POSIX) Il y a quand même de petits détails auxquels il faut faire gaffe, comme il est dit

    Note: the +0s ensure we are always performing a numeric comparison. In Awk this is unnecessary if all instances of column 4ドル and column 5ドル are numeric; in frawk this is required: max will perform a lexicographic comparison instead of a numeric one without the explicit conversion.

    La plus grande surprise, pour moi, fut pour le petit test en Python et en Rust

    frawk is a good deal faster than the other options, particularly on the newer hardware, or when run in parallel. Now, the Rust script could of course be optimized substantially (frawk is implemented in Rust, after all). But if you need to do exploratory, ad-hoc computations like this, a frawk script is probably going to be faster than the first few Rust programs you write.

    "It is seldom that liberty of any kind is lost all at once." ― David Hume