[F] [mOved] Mon langage est mieux que le tien - Page 22

Zerosquare (./630) :
Non mais même, bouffer 1 ~ 2 Go pour un machin en arrière plan, dont la seule fonction est d'avoir des perfs à peu près normales... c'est du délire.

Sur des machines avec au moins 16 GB de ram ils s'en foutent..

Ça reste absurde.

Je ne dit pas le contraire

Je dit juste que les devs de ce truc, doivent avoir des pc de "malade" donc ils s'en foutent

Je pense surtout que comme pour pas mal de softs, ceux qui le développent ne l'utilisent pas

Bonne question, mois j'ai toujours utilise les softs que j'ai fait

Je parie même que pour certains, tu es le seul utilisateur, je me trompe ?

comment tu sais ca toi ?

Sinon non ya au moins 3 softs que j'ai fait "from scratch" qui est utilise, de maniere invisible par quelques dizaines de milliers de gens

Cela me rassure, pareil pour mon dual core a 2 gigas, vaut mieux pas que je lance autre chose derrière, même un player de mp3 s'arrete durant la compilation.

Android studio fait mal, c'est pas lent mais ultra méga lent. Bientot il va falloir une machine de gamer pour dev. Pour info le lancement de l'emulo et sa mise en place tellement lente, que l'envoi sur un telephone reel et lancement de l'application mais moins de temps.

J'ai deja eu des builds de 1 minutes 20 et le source total fait pas 500 lignes (6 classes).


GT Trop lent...

Pour certains environement (et pour des gros projets) ce n'est pas bientot, mais c'est deja le cas, au boulot sans un core i7 muscle certaines choses ne serait meme pas envisageable.. Et le code est 99% de C et un peu d'ASM

Brunni (./626) :
l'impossibilité de stopper le build, car ce démon est lent à relancer et l'arrêt n'est jamais sûr

N'importe quoi, avec un kill -9, l'arrêt est garanti.

C'est un daemon zombie (a ne pas confondre avec un démon zombie)

Godzil (./639) :
Pour certains environement (et pour des gros projets) ce n'est pas bientot, mais c'est deja le cas, au boulot sans un core i7 muscle certaines choses ne serait meme pas envisageable.. Et le code est 99% de C et un peu d'ASM

Ca fait mal, un pauvre Falcon a moins de 100 Mhz atomise tous ces outils, 30 000 lignes de code asm envoyé en 0.8 secondes !!

On avance en marche arrière avec les outils d'aujourd'hui

Dans windows 11 on pourra lire, pour ouvrir le bloc notes un core i7 est obligatoire.

GT Très rapide !!

Oui c'est ça, ils ont probablement des PCs de gamer chez Google (ça m'étonnerait qu'ils radinent sur le matos qu'ils fournissent à leurs employés…). Et même pas forcément de gamer, simplement des PCs fixes décents. Le problème c'est que pas mal de gens ont des portables (c'est pratique et ça se fait de plus en plus, les gens pouvant ainsi travailler depuis n'importe où) et pour eux c'est l'enfer. Mais prenons mon PC fixe qui a 3 ans et qui peut à la louche faire 50% mieux que mon nouveau portable, ben là on transforme 3~4 sec de build en 2 sec et ça vient tout à coup négligeable.

Kevin Kofler (./640) :

Brunni (./626) :
l'impossibilité de stopper le build, car ce démon est lent à relancer et l'arrêt n'est jamais sûr

N'importe quoi, avec un kill -9, l'arrêt est garanti.

Oui en effet. J'aurais dû préciser qu'il n'y a pas de moyen supporté par le tool de faire ça. kill -9 c'est pas pratique, il te faut te rappeler du pid. Et killall java ben le souci c'est que tu killes vraisemblablement ton éditeur (Android Studio) avec en plus après il te faut relancer le démon ce qui te fait perdre 10 sec. Donc globalement c'est pas très pratique

Sinon concernant Android ils ont fait de gros progrès de batterie. Avant ma tablette tenait 15~20 jours en veille jusqu'à être complètement plate si je ne m'en servais pas. Depuis Lollipop elle fait 100% -> 15% en 2 jours, et à 15% t'as le mode battery saver qui prend le relais, qui désactive tout (data & co), du coup si tu prends la tablette après 15~20 jours t'as encore 8% de batterie ! On n'arrête pas le progrès

Brunni (./644) :
N'importe quoi, avec un kill -9, l'arrêt est garanti.

Oui, et tu peux aussi débrancher la prise de courant de ton ordinateur, ou couper le disjoncteur de ta maison, ça marche également. Mais un programme qui ne peut pas être arrêté proprement reste un programme mal conçu.

Hum 30'000 lignes de code? le projet sur lequel je bosse a un peu largement beaucoup plus de ligne de code

• Godzil lance sloccount histoire d'avoir peur...



SLOC Directory SLOC-by-Language (Sorted)
2761771 folder1 asm=1814528,ansic=937970,perl=6192,python=2618,pascal=40
sh=55
882677 folder2 ansic=875763,perl=4368,cpp=1941,python=586,sh=19
424483 folder3 ansic=415325,cpp=5568,perl=1850,exp=1536,csh=112,
sh=44,python=33,asm=15
292151 folder4 ansic=263982,csh=14314,perl=13578,cpp=238,sh=20,
tcl=19
159131 folder5 ansic=71490,cpp=65827,perl=16947,python=4527,sh=222,
asm=118
148084 folder6 ansic=143513,asm=1685,perl=1243,cpp=1186,csh=395,
sh=62
34393 folder7 ansic=25409,perl=4958,java=1845,asm=1144,cpp=918,
csh=119
32448 folder8 ansic=30207,cpp=2166,perl=64,sh=11
18802 folder9 ansic=15969,cpp=2241,asm=544,perl=48
12893 folder10 ansic=12735,cpp=88,asm=70
1579 folder11 ansic=1579
630 folder12 perl=630
174 folder13 ansic=174

Totals grouped by language (dominant language first):
ansic: 2794116 (58.59
asm: 1818104 (38.12
cpp: 80173 (1.68
perl: 49878 (1.05
csh: 14940 (0.31
python: 7764 (0.16
java: 1845 (0.04
exp: 1536 (0.03
sh: 433 (0.01
pascal: 408 (0.01
tcl: 19 (0.00

Total Physical Source Lines of Code (SLOC) = 4,769,216
Development Effort Estimate, Person-Years (Person-Months) = 1,456.80 (17,481.58)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 8.53 (102.36)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 170.79
Total Estimated Cost to Develop = $ 196,793,598
(average salary = $56,286/year, overhead = 2.40).


Il y a 11654 fichier *.c, 16638 fichier *.h, 244 fichier *.cpp, 110 fichier *.s, 3 fichier *.asm.

(et ce n'est qu'une partie du code total...)

Il n'y a que 158x plus de lignes... (et encore il ne compte pas les commentaires , et si ca devais etre fait 100% en ASM je pense qu'on peux facilement multiplier ce nombre par 4 ou 5...)

Brunni: plus le mode noir et blanc ? Non parce qu'il est connu que driver un écran en noir & blanc réduit la consommation batterie !

Zero: moi j'irais carrement éteindre la centrale nuculeaire qui est au bout du fil electrique

Ah non ils n'ont plus le mode noir & blanc (cela dit pour un LCD j'espère que tu blagues non ? )

Godzil (./645) :
Zero: moi j'irais carrement éteindre la centrale nuculeaire qui est au bout du fil electrique

Oui, relativement ça prendrait pas bcp plus longtemps à relancer après.

Brunni: bien sur que je blague, c'est juste que je trouve cette idée stupide d'essayer de faire croire aux crédules que d'afficher en n&b permet de consommer moins.

95% de la conso est dans le backlight, la conso du rafraîchissement est quasiment indépendante de ce qui est affiché.

Ben tu m'aurais dit qu'avoir une UI plus claire consommait moins j'aurais répondu autrement

De toute façon, là où fais le plus d'économie sur ton écran de téléphone c'est en le mettant en 320x200

Godzil on compare pas un devlopement pro et un perso.

Mais comparativement tu regarde les machines sont de plus en plus puissantes, mais les compilations de plus en plus lente, c'est quand même un comble.



GT

De manière générale (a mon avis de padéveloppeur, sauf si on considère que développer des macros Excel pour faire 12367 inserts dans une base de données c'est être dev), le gros souci actuel vient du manque d'optimisation générale, que ça soit les devs de jeux ou d'applis. On se dit qu'on a assez de puissance processeur/GPU, de RAM pour ne pas avoir à s'en soucier...

quand je vois les dimenssionnements des postes utilisateurs pour des professions de bureau ou les serveurs d'application pour de méchants CRUDs...

J'aime Google. J'ai l'impression que c'est vraiment de mieux en mieux. Je veux me loguer sur la console développeur parce que j'ai besoin de tester l'In-app Billing. Bon il tient à associer mon compte Google actuel (celui qui fonctionne pour gmail, calendrier, etc.) comme développeur, du coup si je me logue avec le compte de la boîte, ne pense pas à me déloguer explicitement et regarde une vidéo youtube en parallèle, ça sera sur l'historique du patron, toujours cool mais c'est pas ça qui est embêtant.

Non, ce qui est embêtant c'est que le truc te demande de payer avant de pouvoir afficher la Developer Console. Mais surtout il te demande ton numéro de carte bancaire sans te dire le prix. Ca donne pas exactement envie d'acheter. Je me doute que c'est qqch comme 50€ mais voilà, ce sont quand même des putain de branques, n'ayons pas peur des mots.



[Edit] My bad, en fait c'est écrit sur l'écran précédent. Je dois avoir la tête dans les choux à force de mixer le C++ et le Java

GT Turbo (./642) :
Ca fait mal, un pauvre Falcon a moins de 100 Mhz atomise tous ces outils, 30 000 lignes de code asm envoyé en 0.8 secondes !!

On avance en marche arrière avec les outils d'aujourd'hui

Effectivement, le "creeping bloat" est un problème énorme! C'est fou à quel point les logiciels d'aujourd'hui gaspillent les ressources!

Dans windows 11 on pourra lire, pour ouvrir le bloc notes un core i7 est obligatoire.

Effectivement…

Brunni (./643) :
J'aurais dû préciser qu'il n'y a pas de moyen supporté par le tool de faire ça. kill -9 c'est pas pratique, il te faut te rappeler du pid.

Et tu ne l'as pas? Les APIs de lancement de processus en Java sont totalement merdiques alors. En Qt, si je détruis un QProcess, ça envoie automatiquement un SIGKILL (signal 9). Il y a aussi une méthode kill() appelable explicitement (utile, par exemple, si on travaille avec Qt Jambi en Java).

Zerosquare (./644) :

Brunni (./644) :
N'importe quoi, avec un kill -9, l'arrêt est garanti.

Oui, et tu peux aussi débrancher la prise de courant de ton ordinateur, ou couper le disjoncteur de ta maison, ça marche également. Mais un programme qui ne peut pas être arrêté proprement reste un programme mal conçu.

Bof… Une bonne IDE devrait toujours proposer un moyen d'envoyer SIGKILL. (Dans KTIGCC, il y a un bouton "force-quit compiler".)

Si ton compilateur nécessite régulièrement d'utiliser SIGKILL, c'est qu'il est bugué. SIGKILL est le dernier recours pour arrêter un processus planté, avec potentiellement des pertes de données, pas un moyen d'arrêt normal.

Clairement

KTIGCC envoie d'abord SIGTERM, attend 100 ms, puis envoie SIGKILL.
Et tous les compilateurs sont bogués en pratique, un bon EDI permet de contourner les plantages.

OBO (./650) :
. On se dit qu'on a assez de puissance processeur/GPU, de RAM pour ne pas avoir à s'en soucier...

Tout est dit !!


GT Trop fainéant pour optimisé !

Il faudrait mettre tous les développeurs devant des ordinateurs comme le mien (qui a une douzaine d'années), ça leur apprendrait!

Ras le bol de l'obsolescence programmée! Ils veulent qu'on achète, achète, achète et jette, jette, jette, et la planète dans tout ça? (La montagne de déchets électroniques est un énorme problème environnemental.) Sans parler des coûts inutiles pour chaque utilisateur.

Et dire qu'il y a des gens qui savent faire tenir un jeu d'échecs avec IA dans 487 octets : http://www.pouet.net/prod.php?which=64962

Brunni (./626) :
Toute à l'heure sur mes toilettes, je me suis dit que j'étais quand même un peu trouducuté.

Je ne sais pas si certains d'entre vous ont essayé Android Studio, mais ce truc vient avec gradle, le nouveau système de build de référence pour les applications Android. Il marche plutôt bien mais le temps de build est disproportionné. Il a fallu une minute vingt (1'20) pour builder ma petite application contenant une 30aine de fichiers C++ et 4 classes Java sur une machine récente. Et encore, c'est en l'ayant lancé plusieurs fois avant avec un build failed. Pour comparaison, il faut 12 secondes pour sortir une appli Win32 avec le même code à partir d'un clean build sous Visual Studio depuis une VM que je venais de démarrer.

En fait, en 12 secondes avec Gradle on fait l'équivalent d'un --help :

$ ./gradlew
:help

Welcome to Gradle 2.2.1.

To run a build, run gradlew <task> ...

To see a list of available tasks, run gradlew tasks

To see a list of command-line options, run gradlew --help

BUILD SUCCESSFUL

Total time: 9.726 secs

Dans les 9 secondes il ne compte pas le démarrage et tout. Alors oui en optimisant (Android Studio garde un démon qui prend 1~2 Go en RAM, utilise tous tes cores CPU et retire parfois certaines phases de compilation) on arrive à ramener ça à 3~4 sec pour un build incrémentiel d'un Hello World, ce qui est raisonnable. Mais avec des désavantages comme l'impossibilité de stopper le build, car ce démon est lent à relancer et l'arrêt n'est jamais sûr, donc c'est simplement pas supporté. Sérieux ? Si tu t'es planté, tu perds 1 min et beaucoup d'électricité.

Je me pose des questions. Comment est-ce raisonnablement possible de designer et vouloir utiliser des outils pareils ? Ou pire oser releaser ça (même si on admet que les développeurs Java n'ont pas beaucoup d'amour propre). Oui "ça marche" contrairement à ce qu'on avait avant, donc c'est une grosse amélioration par rapport à Eclipse et ça justifie logiquement un passage sur ce système, mais quand même ? Où va-t-on s'arrêter ? A-t-on idée du nombre de cycles CPU que ça représente 1 min 20 d'un quad core ? Et combien sont réellement utiles dans le lot ?

Ça me rappelle mes aventures avec Scala et SBT