Créez un code source court dans votre langue compilée préférée qui se compile en un gros fichier exécutable (pas moins de 104857600 octets). Le programme doit être exécutable (en supposant 1 Go de mémoire libre) et peut tout faire (de préférence quelque chose de simple comme un bonjour).
L'utilisation d'astuces non évidentes est encouragée.
Exemple ennuyeux en C:
int a[1024*1024*25] = { 1 };
int main(){}
Points bonus s'il peut être "expliqué" pourquoi la taille de l'exécutable ne peut pas être réduite (c'est-à-dire que tous les ballonnements sont en fait utilisés d'une manière ou d'une autre).
Réponses:
OK, voici un autre en C, pour les points bonus vaguement définis:
Fondamentalement, au moment de la compilation, il crée une séquence ascendante d'entiers de 0 à 2 25 - 1. Au moment de l'exécution, il vérifie que la séquence contient bien les valeurs attendues, et sinon, renvoie un code d'erreur non nul.
Ps. Si j'ai bien fait mes calculs, l'exécutable devrait dépasser 100 Mo. Je vous ferai connaître la taille exacte une fois la compilation terminée ...
la source
virtual memory exhausted: Cannot allocate memory
. o_O va essayer de modifier les options pour voir si je peux le faire compiler d'une manière ou d'une autre.clang
(ICE) ettcc
.-O0
) pour minimiser les demandes du compilateur, et l'activation de pipes (-pipe
) peut ou peut ne pas aider.C #
Je ne sais pas si cela peut être considéré comme court, car le code source a fini par être> 30k :)
C'est à dire - trop gros pour citer. En voici une version légèrement raccourcie
Le code que j'ai compilé se trouve ici: http://pastebin.com/R5T3e3J0
Cela créera un fichier .EXE de ~ 45 Ko lorsqu'il est compilé sans optimisation. Compilez-le à nouveau avec Ngen.exe (Native Image Generator) et cela devient un énorme 104 Mo!
Cela fonctionne en raison du fonctionnement du système de type générique CLR. Chaque liste <> dans le code ci-dessus générera une nouvelle déclaration de type (normalement via la compilation JIT, mais Ngen effectue la compilation AOT). Donc, un type pour List <int>, un autre pour List <List <int>>, etc. Ainsi, pour ce code, un total de 5160 listes génériques différentes seront créées.
la source
COBOL
Un peu de connaissances peut être dangereux.
Il peut être plus rapide de faire une grande comparaison que de nombreuses petites comparaisons; Enterprise COBOL d'IBM (jusqu'à la version 4.2) peut avoir un STOCKAGE DE TRAVAIL maximum de 128 Mo (la version 5.0 peut avoir 2 Go); LOCAL-STORAGE offre 128 Mo supplémentaires si vous avez besoin de plus d'espace.
La tâche consiste à confirmer qu'un élément de stockage de 1 584 octets a la valeur "BONJOUR MONDE!" quelque part, et le reste est l'espace.
Le programmeur fictif décide d'écrire un sous-programme pour cela (juste au cas où cela serait nécessaire ailleurs) et d'inclure sa technique performante (bonus).
Le programmeur calcule que 11584 * 11584 est de 128 Mo. Il utilise donc WORKING-STORAGE pour une énorme table et LOCAL-STORAGE pour tout le reste.
Le programmeur le code et se sourit sciemment lorsque la compilation est propre. Ils avaient raison sur les 128 Mo.
Teste le code. Ça marche. Peut-être un peu lent, mais il y a une lourde charge sur la machine. Sourit à nouveau, pensant à quel point ce serait lent s'il était codé sans leur niveau de connaissance experte.
Le WORKING-STORAGE est de 134 189 056 octets, et il y a aussi quelques octets d'autres choses. Devrait être assez grand.
La réalité est que faire une comparaison longue au lieu d'une comparaison courte, comme mis en œuvre ici, est un moyen très lent de le faire.
Encore plus lent, le LOCAL-STORAGE, qui est initialisé par des routines d'exécution à chaque appel d'un sous-programme, entraîne la configuration de 128 Mo pour chaque CALL.
Le programmeur avait tout simplement tort sur la taille de la table, il y a assez de place sans utiliser LOCAL-STORAGE. Les comparaisons longues peuvent battre les comparaisons courtes, mais uniquement lorsque le nombre réel de comparaisons est réduit.
J'ai envisagé d'échanger LOCAL-STORAGE et WORKING-STORAGE, il est beaucoup moins probable que quelqu'un le coderait de cette façon, donc je ne l'ai pas fait. Mettre un ESPACE DE VALEUR sur la table (s'il avait été en LOCAL-STORAGE) aurait initié la table deux fois à chaque APPEL, donc encore plus lentement.
Le Bloat ne peut pas être supprimé sans réécrire le programme. La plupart du code est mauvais, bien qu'il existe une technique utile.
Ce n'est pas un exemple réel, mais je peux imaginer quelqu'un le faire, si cette personne est assez intelligente :-)
La compilation n'est pas un problème du tout. L'exécuter avec toutes les possibilités s'avère rapidement inutile.
Bien sûr, il y a aussi un vieux bug. Très courant dans les tâches de "recherche".
la source
PowerBASIC
la source
Scala
L'annotation spécialisée crée une nouvelle classe pour chaque type afin d'empêcher la boxe lorsque les types finissent tous par être transformés en objets. Il créera 10 ^ 8 ((se
Everything
compose de 10 types) ^ (8 paramètres de type sur la classe)) des fichiers de classe, chacun 300-500 octets, s'il ne plante pas en premier.Cela pourrait s'expliquer en disant que les performances sont importantes, surtout si la classe a fait plus que d'avoir une méthode à imprimer. L'utilisation de méthodes génériques spécialisées au lieu de tout mettre dans la déclaration rendrait également plus difficile de remarquer
la source
Javascript
Exécutez ce code dans la console du navigateur sur cette page et, une fois terminé, enregistrez la page. cela devrait entraîner une taille de fichier supérieure à 100 Mo. Toujours en test. Publiera la taille réelle une fois terminée.
update-
la page enregistrée est le résultat exécutable. Le moteur v8 de chrome est le compilateur. Et le code que j'ai affiché est le programme. j'avoue que cela prend un peu de temps à compiler. :RÉ
la source