[ Dernière mise à jour: programme de référence et résultats préliminaires disponibles, voir ci-dessous]
Je veux donc tester le compromis vitesse / complexité avec une application classique: le tri.
Écrivez une fonction ANSI C qui trie un tableau de nombres à virgule flottante dans l' ordre croissant .
Vous ne pouvez utiliser aucune bibliothèque, appel système, multithreading ou ASM en ligne.
Entrées jugées sur deux composantes: la longueur du code et les performances. Notation comme suit: les entrées seront triées par longueur (journal de # caractères sans espace blanc, afin que vous puissiez conserver une mise en forme) et par performance (journal de # secondes sur une référence), et chaque intervalle [meilleur, pire] normalisé linéairement à [ 0,1]. Le score total d'un programme sera la moyenne des deux scores normalisés. Le score le plus bas l'emporte. Une entrée par utilisateur.
Le tri devra (éventuellement) être en place (c'est-à-dire que le tableau d'entrée devra contenir des valeurs triées au moment du retour), et vous devez utiliser la signature suivante, y compris les noms:
void sort(float* v, int n) {
}
Caractères à compter: ceux de la sort
fonction, signature incluse, plus les fonctions supplémentaires appelées par celle-ci (mais sans inclure le code de test).
Le programme doit gérer toute valeur numérique float
et tableaux de longueur> = 0, jusqu'à 2 ^ 20.
Je vais brancher sort
et ses dépendances dans un programme de test et compiler sur GCC (pas d'options fantaisistes). Je vais y alimenter un tas de tableaux, vérifier l'exactitude des résultats et le temps d'exécution total. Les tests seront exécutés sur un Intel Core i7 740QM (Clarksfield) sous Ubuntu 13.
Les longueurs de baies couvriront toute la plage autorisée, avec une densité plus élevée de baies courtes. Les valeurs seront aléatoires, avec une distribution de queue grasse (à la fois dans les plages positives et négatives). Des éléments dupliqués seront inclus dans certains tests.
Le programme de test est disponible ici: https://gist.github.com/anonymous/82386fa028f6534af263
Il importe la soumission en tant que user.c
. Le nombre de cas de test ( TEST_COUNT
) dans le benchmark réel sera de 3000. Veuillez fournir vos commentaires dans les commentaires de la question.
Délai: 3 semaines (7 avril 2014, 16h00 GMT). Je posterai le benchmark dans 2 semaines.
Il peut être conseillé de publier près de la date limite pour éviter de donner votre code aux concurrents.
Résultats préliminaires, à la date de publication du benchmark:
Voici quelques résultats. La dernière colonne montre le score en pourcentage, le plus élevé sera le mieux, plaçant Johnny Cage à la première place. Les algorithmes qui étaient des ordres de grandeur plus lents que les autres ont été exécutés sur un sous-ensemble de tests et extrapolés dans le temps. Le propre de C qsort
est inclus pour comparaison (celui de Johnny est plus rapide!). Je ferai une comparaison finale à la fermeture.