Batch Index du Forum
S’enregistrerRechercherFAQMembresGroupesConnexion
Répondre au sujet Page 1 sur 1
Un langage de programmation Batch amélioré...
Auteur Message
Répondre en citant
Message Un langage de programmation Batch amélioré... 
Salut à tous ! Very Happy

Je sais ce n'est qu'une idée mais je pense que ca pourrait vraiment être utile,

Bon, nous savons tous sur ce forum ce qu'est le batch,et nous savons que ce n'est pas "vraiment" un langage mais un script.Et comme le batch est un script qui s'apprend assez vite (en tous cas pour moi) je me disait, pourquoi pas créer un nouveau batch,qui reprendrai toute les fonction et les syntaxes actuelle mais juste rajouter des commande en plus, lui retirer sa dépendance a cmd (c'est l'utilisateur qui choisira si il veut une application console ou pas Wink ), qu'il offre autant de possibilité que le C++,qu'il puisse être utiliser pour le développement de vrai jeu/logiciels 2D/3D !

Je sais que c'est un peu grandiose et que ça ne se fait pas comme ça mais le batch deviendrai quelque chose de beaucoup plus apprécié qu'aujourd'hui et serai réellement utile au développement d'application complexe (comme un vrai anti-virus par exemple).Moi je ne suis pas capable de réaliser une telle choses c'est pour ça que je vous en parle mais si quelqu'un de vous en est capable, pourquoi pas le faire ?

Après c'est juste une idée donc libre à vous de la trouver bonne ou pas Wink


Cordialement, Fokker974 Very Happy




______________________________________________________
Fokker974 The batcher
Message Publicité 
PublicitéSupprimer les publicités ?


Répondre en citant
Message Un langage de programmation Batch amélioré... 
J'y avait réfléchi, mais c'est très (trop) complexe.
Mon idée était un langage de style C qui se converti en batch, des "bindings" existerais pour pouvoir utiliser les commandes externes de façon intégré au langage.

Sinon, le batch se limite de moins en moins à Windows, comme tu peux le voir, je facilite la compatibilité à Windows en améliorant Dos9 (de Darkbatcher) et en faisant des commandes compatibles linux (pTXTCOLOR, AgrafV2 (gtk), SockeT, etc.).




______________________________________________________
Partager permet le savoir. Le savoir permet de partager de nouveau savoirs.
Répondre en citant
Message Hmmmmmmm..... 
TSnake41 a écrit:
J'y avait réfléchi, mais c'est très (trop) complexe.
Mon idée était un langage de style C qui se converti en batch, des "bindings" existerais pour pouvoir utiliser les commandes externes de façon intégré au langage.

Sinon, le batch se limite de moins en moins à Windows, comme tu peux le voir, je facilite la compatibilité à Windows en améliorant Dos9 (de Darkbatcher) et en faisant des commandes compatibles linux (pTXTCOLOR, AgrafV2 (gtk), SockeT, etc.).



Oui je sais bien que c'est dure, ben pk pas créer une équipe spécialement pour créer ce nouveau langage ?




______________________________________________________
Fokker974 The batcher
Répondre en citant
Message Un langage de programmation Batch amélioré... 
A moins d'être très nombreux et de travailler à plein temps sur ce projet, ça risque d'être compliqué à réaliser ton projet ... Pour pouvoir le faire, il faut partir de zéro et créé toutes les commandes, créé le compilateur soi-même ext ...

Tu peux déjà très bien réaliser un programme/jeu en batch 2D très performant si tu optimise très bien (par exemple utiliser plusieurs cœurs et faire du multi-thread).
J'en avait parlé à TS car 2 threads (2 instances cmd, dont l'une ouverte avec 'start /b') ne peuvent pas "écrire" en même temps dans une même console (ce qui est très embêtant pour les performances, mais tu peux faire des calculs en parallèles tout de même).

@ ++ Okay Wink




______________________________________________________
Coucou, tu veux voir mon Site Web ?? Mort de Rire
Visiter le site web du posteur Skype
Répondre en citant
Message Un langage de programmation Batch amélioré... 
Xenoxis a écrit:
A moins d'être très nombreux et de travailler à plein temps sur ce projet, ça risque d'être compliqué à réaliser ton projet ... Pour pouvoir le faire, il faut partir de zéro et créé toutes les commandes, créé le compilateur soi-même ext ...

Tu peux déjà très bien réaliser un programme/jeu en batch 2D très performant si tu optimise très bien (par exemple utiliser plusieurs cœurs et faire du multi-thread).
J'en avait parlé à TS car 2 threads (2 instances cmd, dont l'une ouverte avec 'start /b') ne peuvent pas "écrire" en même temps dans une même console (ce qui est très embêtant pour les performances, mais tu peux faire des calculs en parallèles tout de même).

@ ++ Okay Wink
L'utilisation seule du multi-thread est inutile, à vrai dire, il y a 1 thread/core à la fois, mais comme il y a prés d'une centaine de thread (en fond), en ajouter un pour ton programme ne fait que doubler le temps CPU avec une perte dans la gestion des threads/process, si tu veux gagner en vitesse, ce sera plus intéressant d'augmenter le temps procésseur, tu réduira la charge CPU (le faite que ça monte dis juste que c'est plus lourd !) et tu gagnera considérablement en vitesse.

Le multi-thread est surtout fait pour faire plusieurs actions indépendantes en même temps, pas pour accélérer la vitesse (sauf dans le cas de rares algorithmes).

Je pense qu'il faut faire des tests concret et simple sans utilisation du disque dur, voir qui aura mieux Cool.




______________________________________________________
Partager permet le savoir. Le savoir permet de partager de nouveau savoirs.
Répondre en citant
Message Un langage de programmation Batch amélioré... 
TSnake41 a écrit:
Xenoxis a écrit:
A moins d'être très nombreux et de travailler à plein temps sur ce projet, ça risque d'être compliqué à réaliser ton projet ... Pour pouvoir le faire, il faut partir de zéro et créé toutes les commandes, créé le compilateur soi-même ext ...

Tu peux déjà très bien réaliser un programme/jeu en batch 2D très performant si tu optimise très bien (par exemple utiliser plusieurs cœurs et faire du multi-thread).
J'en avait parlé à TS car 2 threads (2 instances cmd, dont l'une ouverte avec 'start /b') ne peuvent pas "écrire" en même temps dans une même console (ce qui est très embêtant pour les performances, mais tu peux faire des calculs en parallèles tout de même).

@ ++ Okay Wink
L'utilisation seule du multi-thread est inutile, à vrai dire, il y a 1 thread/core à la fois, mais comme il y a prés d'une centaine de thread (en fond), en ajouter un pour ton programme ne fait que doubler le temps CPU avec une perte dans la gestion des threads/process, si tu veux gagner en vitesse, ce sera plus intéressant d'augmenter le temps procésseur, tu réduira la charge CPU (le faite que ça monte dis juste que c'est plus lourd !) et tu gagnera considérablement en vitesse.

Le multi-thread est surtout fait pour faire plusieurs actions indépendantes en même temps, pas pour accélérer la vitesse (sauf dans le cas de rares algorithmes).

Je pense qu'il faut faire des tests concret et simple sans utilisation du disque dur, voir qui aura mieux Cool.


Je suis pas d'accord, l'utilisation du multi-thread est très utile dans le batch sous 2 conditions :

- Exécuter des actions lourdes (comme un jeu vidéo, ou un encodeur en base64 http://batch.xoo.it/t5146-Batch-B64X.htm#B64X ), bien entendu tu va pas créé un thread juste pour un 'echo'
- Ne pas tenter d'afficher des informations à l’écran en même temps sur les threads

Sous B64X tu peux d'ailleurs remarquer que les threads de "compilations" sont en priorités "haute", comme tu l'as suggéré mais j'y avait pensé avant Wink

Faire du multi-thread en batch doit être utilisé pour faire des commandes longues en même temps afin d'éviter l'inconvénient des commandes en séries (commande --> attente de la fin de l’exécution --> commande suivante --> ext ...)




Pour exemple, imagine un jeu type tower défense ou les mobs doivent se déplacer tout en permettant au joueur de se déplacer en même temps également !
En batch, si tu optimise suffisamment le code, tu peux avoir l’impression de te déplacer en même temps que les mobs, mais ce n'est pas le cas car les commandes sont exécuter en série,
avec le multi-thread, il est possible (mais difficilement, hé oui ^^) de faire en sorte qu'un thread s'occupe du déplacements des mobs et des actions (IA) et un autre threads des déplacements du joueur et de réunir les informations du thread qui s'occupe des mobs et de les afficher sur la fenêtre (oui, c'est problématique, mais on peux pas faire autrement ...)

@ ++ Wink Okay




______________________________________________________
Coucou, tu veux voir mon Site Web ?? Mort de Rire
Visiter le site web du posteur Skype
Répondre en citant
Message Un langage de programmation Batch amélioré... 
Xenoxis a écrit:
TSnake41 a écrit:
Xenoxis a écrit:
A moins d'être très nombreux et de travailler à plein temps sur ce projet, ça risque d'être compliqué à réaliser ton projet ... Pour pouvoir le faire, il faut partir de zéro et créé toutes les commandes, créé le compilateur soi-même ext ...

Tu peux déjà très bien réaliser un programme/jeu en batch 2D très performant si tu optimise très bien (par exemple utiliser plusieurs cœurs et faire du multi-thread).
J'en avait parlé à TS car 2 threads (2 instances cmd, dont l'une ouverte avec 'start /b') ne peuvent pas "écrire" en même temps dans une même console (ce qui est très embêtant pour les performances, mais tu peux faire des calculs en parallèles tout de même).

@ ++ Okay Wink
L'utilisation seule du multi-thread est inutile, à vrai dire, il y a 1 thread/core à la fois, mais comme il y a prés d'une centaine de thread (en fond), en ajouter un pour ton programme ne fait que doubler le temps CPU avec une perte dans la gestion des threads/process, si tu veux gagner en vitesse, ce sera plus intéressant d'augmenter le temps procésseur, tu réduira la charge CPU (le faite que ça monte dis juste que c'est plus lourd !) et tu gagnera considérablement en vitesse.

Le multi-thread est surtout fait pour faire plusieurs actions indépendantes en même temps, pas pour accélérer la vitesse (sauf dans le cas de rares algorithmes).

Je pense qu'il faut faire des tests concret et simple sans utilisation du disque dur, voir qui aura mieux Cool.


Je suis pas d'accord, l'utilisation du multi-thread est très utile dans le batch sous 2 conditions :

- Exécuter des actions lourdes (comme un jeu vidéo, ou un encodeur en base64 http://batch.xoo.it/t5146-Batch-B64X.htm#B64X ), bien entendu tu va pas créé un thread juste pour un 'echo'
- Ne pas tenter d'afficher des informations à l’écran en même temps sur les threads

Sous B64X tu peux d'ailleurs remarquer que les threads de "compilations" sont en priorités "haute", comme tu l'as suggéré mais j'y avait pensé avant Wink

Faire du multi-thread en batch doit être utilisé pour faire des commandes longues en même temps afin d'éviter l'inconvénient des commandes en séries (commande --> attente de la fin de l’exécution --> commande suivante --> ext ...)




Pour exemple, imagine un jeu type tower défense ou les mobs doivent se déplacer tout en permettant au joueur de se déplacer en même temps également !
En batch, si tu optimise suffisamment le code, tu peux avoir l’impression de te déplacer en même temps que les mobs, mais ce n'est pas le cas car les commandes sont exécuter en série,
avec le multi-thread, il est possible (mais difficilement, hé oui ^^) de faire en sorte qu'un thread s'occupe du déplacements des mobs et des actions (IA) et un autre threads des déplacements du joueur et de réunir les informations du thread qui s'occupe des mobs et de les afficher sur la fenêtre (oui, c'est problématique, mais on peux pas faire autrement ...)

@ ++ Wink Okay
Est-ce du multi-thread : non, c'est du multi-processing en batch et c'est clairement pas une réussite niveau performance.

Citation:
Faire du multi-thread en batch doit être utilisé pour faire des commandes longues en même temps afin d'éviter l'inconvénient des commandes en séries (commande --> attente de la fin de l’exécution --> commande suivante --> ext ...)

Pour ça : OK, c'est ce que l'on appelle plus précisément des actions asynchrones.

Citation:
- Exécuter des actions lourdes (comme un jeu vidéo, ou un encodeur en base64 http://batch.xoo.it/t5146-Batch-B64X.htm#B64X ), bien entendu tu va pas créé un thread juste pour un 'echo'
On ne peut pas gagner en performance car le disque dur va pas plus vite avec plusieurs accès spontannées, aussi, on double la charge du processeur et augmente le nombre de boucle du noyau requises : au final, on gagne rien.




______________________________________________________
Partager permet le savoir. Le savoir permet de partager de nouveau savoirs.
Répondre en citant
Message Un langage de programmation Batch amélioré... 
TSnake41 a écrit:
Est-ce du multi-thread : non, c'est du multi-processing en batch et c'est clairement pas une réussite niveau performance.


J'espère que tu plaisante ? "Pas une réussite niveau performance" ? J'ai gagné jusqu’à 78% de temps en moins grâce à la version mutli-thread de B64X (et encore les threads ont un problème de répartitions des tâches donc je suis clairement loin du maximum d'optimisation !!)

TSnake41 a écrit:
Citation:
Faire du multi-thread en batch doit être utilisé pour faire des commandes longues en même temps afin d'éviter l'inconvénient des commandes en séries (commande --> attente de la fin de l’exécution --> commande suivante --> ext ...)

Pour ça : OK, c'est ce que l'on appelle plus précisément des actions asynchrones.


Ben le multi-thread (ou multi-processing ont s'en fou c'est le même principe de toute façon) consiste à faire tourner des applications (commandes en batch, pour être précis) simultanément, donc c'est "pas vraiment asynchrone" mais j'appelerais ça plus : "simultanée".

TSnake41 a écrit:
Citation:
- Exécuter des actions lourdes (comme un jeu vidéo, ou un encodeur en base64 http://batch.xoo.it/t5146-Batch-B64X.htm#B64X ), bien entendu tu va pas créé un thread juste pour un 'echo'
On ne peut pas gagner en performance car le disque dur va pas plus vite avec plusieurs accès spontannées, aussi, on double la charge du processeur et augmente le nombre de boucle du noyau requises : au final, on gagne rien.


PARDON ? Un disque dur récent (par exemple de Seagate Barracuda) peut aller jusqu’à ~130 Mo/s en lecture et ~80 mo/s en écriture, c'est clairement pas avec un programme batch multi-thread que tu va bloquer les performances du à la charge d'écriture sur le disque (même si c'est des accès aléatoires) !

" On double la charge du processeur", ben oui c'est normal c'est du mutli-thread donc 2x + de threads !

"Au final on gagne rien", Ben test B64X en multi-thread on en reparle !!




______________________________________________________
Coucou, tu veux voir mon Site Web ?? Mort de Rire
Visiter le site web du posteur Skype
Répondre en citant
Message Un langage de programmation Batch amélioré... 
Citation:
PARDON ? Un disque dur récent (par exemple de Seagate Barracuda) peut aller jusqu’à ~130 Mo/s en lecture et ~80 mo/s en écriture, c'est clairement pas avec un programme batch multi-thread que tu va bloquer les performances du à la charge d'écriture sur le disque (même si c'est des accès aléatoires) !
~130 Mo/s, c'est tout, je suis presque à 406,0 Mo/s (en pratique) sous Linux ^^.

Le soucis du programme multi-thread reste quand même la fragmentation, pas très pratique sur un disque dur NTFS Mr. Green, mais, le multi-thread n'affecte que la génération, la vitesse de cette génération qui est plutôt facultative (et je crois même que Shaxa va plus vite que ta version multi-thread).




______________________________________________________
Partager permet le savoir. Le savoir permet de partager de nouveau savoirs.
Répondre en citant
Message Un langage de programmation Batch amélioré... 
TSnake41 a écrit:
Citation:
PARDON ? Un disque dur récent (par exemple de Seagate Barracuda) peut aller jusqu’à ~130 Mo/s en lecture et ~80 mo/s en écriture, c'est clairement pas avec un programme batch multi-thread que tu va bloquer les performances du à la charge d'écriture sur le disque (même si c'est des accès aléatoires) !
~130 Mo/s, c'est tout, je suis presque à 406,0 Mo/s (en pratique) sous Linux ^^.

Le soucis du programme multi-thread reste quand même la fragmentation, pas très pratique sur un disque dur NTFS Mr. Green, mais, le multi-thread n'affecte que la génération, la vitesse de cette génération qui est plutôt facultative (et je crois même que Shaxa va plus vite que ta version multi-thread).


406 Mo/s sur un disque dur ? C'est louche ... T'es sur que c'est pas un SSD ?

Après la fragmentation, c'est pas compiler un programme avec B64X qui va te fragmenter beaucoup ton pc (en plus selon tes bench, B64X à la taille du fichier "compilé" la plus petite, donc c'est B64X qui fragmente le moins parmis tout les compilateurs !) ... Wink Rolling Eyes

Pour Shaxa vs B64X multi-thread (en génération), j’attends que tu mettent la suite de tes benchmarks (et que tu ajoute le test de la "compilation")




______________________________________________________
Coucou, tu veux voir mon Site Web ?? Mort de Rire
Visiter le site web du posteur Skype
Répondre en citant
Message Un langage de programmation Batch amélioré... 
Xenoxis a écrit:
406 Mo/s sur un disque dur ? C'est louche ... T'es sur que c'est pas un SSD ?
Je suis sur SSD (Solid-Sata Drive).

Citation:
Après la fragmentation, c'est pas compiler un programme avec B64X qui va te fragmenter beaucoup ton pc (en plus selon tes bench, B64X à la taille du fichier "compilé" la plus petite, donc c'est B64X qui fragmente le moins parmis tout les compilateurs !) ... Wink Rolling Eyes
Sauf que tu alloue plusieurs fichiers tronquées à la fois, connaissant NTFS, tout va se mettre dans le désordre à la suite, et quand tu va supprimer les morceaux pour rassembler le tout en 1, tu va avoir un trou de fragmentation.
Sur un SSD, pas de fragmentation mais plus de I/O sur le disque (en fonction de la taille du fichier) donc moins de durée de vie à très très long terme (négligeable).




______________________________________________________
Partager permet le savoir. Le savoir permet de partager de nouveau savoirs.
Message Un langage de programmation Batch amélioré... 


Montrer les messages depuis:
Répondre au sujet Page 1 sur 1
  



Index | créer un forum | Forum gratuit d’entraide | Annuaire des forums gratuits | Signaler une violation | Conditions générales d'utilisation
Copyright 2008 - 2016 // Batch