[mOved] GL2X utilisation des 2 processeurs :) - Page 2

En quoi le dual core est une abération ?

LAF ! ! ... !

Simplement par ce que c'est vendre 1 core inutile, puis ce que les particuliers ne disposent pas de logiciels profitant du second core. Tout repose alors sur le partage des threads de windows (ahahah) pour le multitache, sachant que les jeux par exemple, resteront bloqué sur un seul core tant qu'on aura pas des jeux multithreadé.

Sinon sur ma ngpc, ya 2 procs (tlcs900h et z80) aussi qui marchent en parallèle avec une zone mémoire partagée.
ça communique par interruption, c assez simple.
Et il y a bien un langage pour gérer ça : l'asm...

tellement simple/abordable/pratique l'asm!

Ben vi !
Et téllement plus parlant que du C !
Ok penpen, j'avais crut comprendre que justement pour éviter ce probléme, les Dual core étais vut comme des mono core.


LAF ! ! ... !

penpen :
puis ce que les particuliers ne disposent pas de logiciels profitant du second core. Tout repose alors sur le partage des threads

Oui, exactement.

gallenza :
que les dual-cores AMD soient une aberration tu verras jamasi un gars qui a conçu un processeur qui osera dire une telle énormité

Tu ne sais pas de quoi tu parles et tu veux donner des leçons aux autres. Je me tapes totalement de l'avis du concepteur de processeur qui propose du dual core sous pression marketting, je suis admin système et programmeur et je te dis que le language évolué permettant une gestion multi-proc simple et transparente n'existe pas encore. Pour l'instant les programmeurs se reposent sur les mécanismes de gestion de thread proposés par l'OS (et même là, avec cette simplification, ca n'est pas si simple pour des questions de réentrance (cf dev de pointe sous solaris)), et le multi-proc n'est pas correctement géré sous linux (il faut ajouter des ordonnanceurs spécifiques, ou des noyaux adaptés, et ensuite disposer d'applicatifs qui utilisent ces nouvelles capacités, avec des bibliothèques spécifiques type RTAI, Xenomai (les plus connues du moment => http://www.openwide.fr/index.php?id=57 ). Sur ce point, le BeOS puisque designé pour un système multi-proc à l'origine reste plus en avance. Au fait, t'à déjà touché à cet OS ou développé sur du temps réel ?

Pour ne pas faire peur aux autres, la GP2x n'oblige pas l'utilisation de systèmes complexes, il suffit de designer des taches arbitraires asynchrones à faire effectuer par le proc additionnel. Mais qui dit gestion "manuelle" par le programmeur implique une répartition non optimale et d'être obligé de truffer le code d'appels de synchronisation. Cela peut se faire en asm mais aussi dans des languages plus évolués (perl, java, ..), mais ca reste très lourd et très inconfortable pour le programmeur (et surtout non portable ce qui est une hérésie).

j'avais completement oublie ce topic ^^, voila ce que j'ai poste ce matin, si ca peut aider
topics/73233-moved-utilisation-du-bi-proc-sur-gp2x

Ouaip j'avais bien vu ça, c'est pas mal.

Par contre il faut garder à l'esprit que le test dont il parle c'est : "calculating prime numbers using square roots".

Donc évidemment il fait globalement l'impasse sur tous les aspects synchronisations inter CPU etc, ce qui lui permet d'afficher benoitement un gain de 100% avec le deuxième CPU. La réalité dans le cadre d'un dev de jeu risque d'être moins idyllique

ce qui sera interessant en tant que donnees sera le teste memoire car ca permet de bien voir le transfert de donnees

Oui en effet, le test de calcul pur fait aussi l'impasse sur ce ralentissement potentiel.

oui et non ca rles deux proc on besion d'accéder a la mémoire pour faire les calculs non ?
Donc si oui cela veux dire qu'il ne ralentisse pas sinon ben faut attendre ! lol !

LAF ! ! ... !

magiceyes :
Au fait, t'à déjà touché à cet OS ou développé sur du temps réel ?

Perso le temps réel est mon métier, et je n'ai pas aussi peur que toi du point de vue de la performance de ce genre de systèmes.
Mais comme tu le dis si bien, la question est différente sur GP2X qui est un système beaucoup plus réduit, et surtout, fermé: le matériel en place est prédéterminé, ça simplifie énormément la répartition des ressources et le calibrement du système d'exploitation.
Pour la problématique de l'utilisation asynchrone, je pense que les solutions sont multiples:
- utilisation du second proc comme coproc graphique, avec communication par interruptions. Simple à gérer, peu d'interférences entre les deux coeurs, gain variable selon le rapport entre la charge graphique et la charge "autre"
- utilisation d'un OS multithreadé. Linux devrait déjà l'être. Au pire faudrait en écrire un autre. Je n'ai pas regardé les datasheets des deux coeurs, sont-ils binairement compatibles ?

Sinon, je ne vois pas le côté hérétique de la non portabilité. On veut être performant ou on ne l'est pas. Et si même des OS peuvent-être portables (en changeant une 20aine de lignes de code assembleur parfois seulement), pourquoi pas des apps ? Suffit d'être rigoureux en les écrivant

Sinon le test mémoire a l'air de prouver qu'on peut bien compter sur le deuxième proc pour gagner pas mal de perfs

magiceyes :
je suis admin système et programmeur

Donc effectivement tu ferais mieux de te taire sur la conception de processeur

magiceyes :
le multi-proc n'est pas correctement géré sous linux

T'as pas une plus grosse connerie à sortir ? T'as pas l'air d'être programmeur système en tout cas, et les 512 CPU que Linux peux gérer nickel te saluent.

magiceyes
Sur ce point, le BeOS puisque designé pour un système multi-proc à l'origine reste plus en avance.

Effectivement faire du multi-proc avec deux CPU c'est à l'évidence la preuve d'une grande avance sur un système qui en gère 512....

D'ailleurs ça fait un bail que unix, linux et même certaines versions professionnelles de windows gèrent le multiproc. Les mainframes, supercalculateurs, ou simplement les serveurs, ça existe

Ximoon, pk j'ai l'impression que tu cherches la polémique alors que tu dis la même chose que moi ?

Non ?

Ca doit être moi alors ..

Bien entendu que linux gère les multi-proc, je le dit et je le répète, debout sur ma table : y'a des milliers de versions de Linux dont plein qui savent gérer le multi-proc !!!! Mais voilà, elles le font mal, avec des interfaces particulières (souvent onéreuses), des compils très précises et du code pas simple a appréhender. C'est là le pb du multi-proc, ca n'est pas grand public du tout. C'est carrément un métier (le tiens en l'occurence ?). Oui on peut faire plus simple (mais je vais pas te l'apprendre et puis je l'avais déjà dit), mais alors on est tellement proche de la machine que cela ne peux tourner que cette machine. Le code n'est plus portable. Pk c'est une hérésie ? Parce que y'en a marre du code spécifique, une belle console comme ca, avec volonté de faire du SDL, du consensuel, du code multi-machine et paf .. pour customiser les perfs il va falloir faire du code tellement dédié que personne ne pourra l'exploiter ailleurs ? Sniff, voilà.

gallenza :
les 512 CPU que Linux peux gérer

Mdr. Il n'y a pas de limite au nombre de processeurs que Linux "peux" gérer. Tu parles de quoi là ?
Toutes tes interventions sont à cette image, on ne sait pas de quoi tu parles, on a l'impression que toi non plus,
mais que tu cherches à tout prix à démontrer quelque chose. Ca t'arrive d'intervenir sans chercher des polémiques stériles ?

magiceyes
:

gallenza :
les 512 CPU que Linux peux gérer

Mdr. Il n'y a pas de limite au nombre de processeurs que Linux "peux" gérer. Tu parles de quoi là ?

Bah si justement, faudrait te renseigner un peu. Grâce au super boulot fait par SGI maintenant la scalabilité de Linux lui permet d'être performant jusqu'à 512 CPU.
Tu connais mal Linux et surtout sa gestion multi-proc...pourquoi tant en parler?
C'est quoi ton pipeau lamentable sur les miliers de version de Linux? C'est du logiciel libre, on peut même dire qu'il y en a des millions!!! c'est quoi ces interfaces onéreuses??ce code pas simpe à appréhender?,franchement t'es dans ton délire...
Linux a une arborescence unique qui gère du téléphone portable au plus gros supercalculateur du monde, il va sans dire que les noyaux qui gèrent ces systèmes ne sont pas compilés avec les mêmes options...heureusement!! mais le truc c'est que ça n'empeche aps Linux d'être au top dans tous les cas.

Je connais très bien Linux et son noyau, c'est un OS que j'utilise tous les jours .. Tiens là en ce moment je suis sous Linux. Il n'y a pas "une" gestion multi-proc de Linux mais autant que de noyaux dédiés à ce type d'architecture. De quoi je te parle quand je parle d'interface onéreuses et complexes ? Ben demande à Ximoon puisque c'est son métier .. Je te parle de réentrance, d'interblocages, de véritable code multi-proc qui ne se réduit pas à du multi-threading basique, et qui permet une reelle efficacité du dev sur multi-proc.

gallenza :
Linux a une arborescence unique qui gère du téléphone

Voilà, tu ne peux pas t'en empêcher .. encore une phrase qui ne veut rien dire.

Cette difficulté rend de toute façon peut vraisemblable l'utilisation ultra-optimisée des deux processeurs (comme sur toutes les machines de ce type, sur la PSP le problème est le même), et de façon plus crédible, on peut plutôt penser à l'utilisation de bibliothèques capables de mettre en oeuvre le second processeur sur des taches dédiées (qui me semble aussi être la seule manière de garder une portabilité exploitable du code développé, pourvu que les bibliothèques en questions gardent une API conforme à ce qui existe déjà). Mais bien entendu, c'est sur ce type de solution que l'efficacité de l'exploitation du second proc chute le plus brutalement.

Bonjour a tous, je fais une rapide incursion chez vous. Je suis devellopeur Jaguar (http://jagware.org) et le petit débat concernant la fréquence et la vitesse m'on tilté.

Sur la Jaguar, on dispose de 3 microprocesseurs (un 68000 et deux processeurs RISC maison), ce qui fait que je peux donner un petit avis pratique personnel.

Pour situer la chose j'écris tout en asm. Dans certains cas de figure, deux processeurs séparés seront plus rapides pourquoi ? Certains processeurs disposent d'un jeu d'instruction différents d'un autre donc seront plus rapide d'en certains domaines que d'autres, Ensuite les histoires de synchro, un programmeur sachant correctement arrangé son programme sera capable de faire tourner deux codes en parallèle sans problème, on fait pas tourner le meme programme sur deux processeurs différents on adapte et si on se cale bien, les deux progs on fini simultanément donc pas d'attente.

Mais cela dépend surtout du type de microprocesseur (Cisc, Risc, etc..)

GT Turbo (Jagware)

Merci de nous faire part de ton expérience GT Turbo !!

Mais justement c'est exactement cela que j'aimerais éviter pour mes dev persos, je veux dire par là être obligé de faire de la répartition de code assembleur en fonction des qualités des différents processeurs. C'est carrément un sacerdoce, et les vitesses de nos processeurs devraient enfin nous permettre de rester à un plus haut niveau .. (enfin j'espère !!). Imagine si maintenant tu devais porter ton code jaguar sur GP2x .. Il faudrait tout recoder de A a Z non ?

magiceyes :
Parce que y'en a marre du code spécifique, une belle console comme ca, avec volonté de faire du SDL, du consensuel, du code multi-machine et paf .. pour customiser les perfs il va falloir faire du code tellement dédié que personne ne pourra l'exploiter ailleurs ? Sniff, voilà.

Tu peux descendre à un niveau aussi "bas" que le C, rester ainsi portable et très performant.
Après si pour utiliser toutes les performances de la bestiole ta méthode c'est d'utiliser des langages très haut niveau et d'autant plus gourmands en ressources (mémoire, proc), libre à toi... Moi j'appelle ça gâcher.
Quand aux porblèmes que tu évoques d'OS gérant plusieurs procs, les concepts ne sont pas fondamentalement différents, et pas vraiment plus gourmands que les mécanismes de multithread sur un seul proc, je ne pense pas que la charge CPU supplémentaire d'un OS qui gère ça soit significative comparée au gain apporté par le second CPU, loin de là.

TU peux même carrément descendre au code machine comme ça tu est sur d'être hyper performant. Par contre pour la lisibilité......

LAF ! ! ... !

Au moins en assembleur, il n'y a pas de pièges de syntaxe, et par certains côtés je trouve ça bien plus lisible que du C
Bon après, si y'a pas un commentaire par ligne, c'est pas la peine de reprendre un code laissé en plan pendant un an, je te le concède

je trouve, perso, que ce topic a 60% contient des infos inutile
On est d'accord l'ASM permet de faire les chose bien mais pas trop facilement et seulmeent pour certaines partie mais sinon une lib sera disponible pour prog les 2 proc plus facilement .
Maintenant il faut attendre et voir ce que ca va donner

Yod4z :
je trouve, perso, que ce topic a 60% contient des infos inutile

C'est mieux que pas mal de topics

Yod4z :
On est d'accord l'ASM permet de faire les chose bien mais pas trop facilement et seulmeent pour certaines partie mais sinon une lib sera disponible pour prog les 2 proc plus facilement .

Rohg l'autre je parle de code machine et lui traduit en assembleur !
Non non le code source c'est plus bonard tu parle direct a ton µproc a toi d'apprendre par coeur les corespondance de chaque code hexadécimal.
DE tout façon si tu veux travailler en ASM, d'abord tu fait un organigramme et ensuite tu fait corespondre chaque bout de ton programme a chaque étape de ton organigramme. Donc tant que tu a l'organigramme sous la main ton code source n'est pas dificile a comprendre.

LAF ! ! ... !

C'est pas valable que pour l'assembleur ce genre de méthode de travail hein (même si "organigramme" n'est pas le terme le plus juste amha)

voila enfin le support pour les developpeur des 2 proc de la GP2x grace au librairies minimal de Rlyeh

/* minimal.c

GP2X minimal library v0.9 by rlyeh, 2005. emulnation.info@rlyeh (swap it!)

+ GP2X 920t/940t CPUs library with a FIFO message system.
+ GP2X video library with double buffering.
+ GP2X sound library with double buffering.
+ GP2X blitter library.
+ GP2X timer library.
+ GP2X joystick library.

Thanks to Squidge, Robster, snaff, Reesy and NK, for the help & previous work! :-)

License
=======

Free for non-commercial projects (it would be nice receiving a mail from you).
Other cases, ask me first.

GamePark Holdings is not allowed to use this library and/or use parts from it.

Known projects using the library or parts from it
=================================================

REminiscence-0.1.8 (rlyeh)
Payback (jrd)
Atari800 GP2X pre-release 3 (foft)
XUMP (kedo)
MAME2X (Franxis)
DrMD for GP2X (Reesy)

What's new
==========

0.9: initial FIFO message system for dual cpu cores.
initial 48 Mb support.
initial quadruple buffering in 8bbp mode.

0.8: initial dual cores cpu support.
added very basic blit functions by popular demand ;-)
added hsync & vsync waiting code (thanks Reesy)
bugfixed a stupid typo in 8bpp mode (thanks Franxis for the bug report)

0.7: sound volume added.
rewritten timer.
faster init code.
fixed launch code when exiting.

0.6: timer added.
palette handling improved and fixed.
sound pause added.

0.5: sound patched for real stereo output (by using NK's solution)
better init code.

0.4: lots of cleanups.
sound is threaded and double buffered now.
8 bpp video support.
better exiting code.

0.3: shorter library.
improved joystick diagonal detection.

0.2: better code layout.
public release.

0.1: beta release. */

Pour recup la nouvelle version 0.9 et avoir des infos:
http://www.emulnation.info/retrodev/forum/viewtopic.php?p=755#755

magiceyes :
Mais justement c'est exactement cela que j'aimerais éviter pour mes dev persos, je veux dire par là être obligé de faire de la répartition de code assembleur en fonction des qualités des différents processeurs. C'est carrément un sacerdoce, et les vitesses de nos processeurs devraient enfin nous permettre de rester à un plus haut niveau .. (enfin j'espère !!). Imagine si maintenant tu devais porter ton code jaguar sur GP2x .. Il faudrait tout recoder de A a Z non ?

Tout recoder oui, m'ais j'ai un tros gros problème avec le C, les X tentatives de programmation avec ce langage, m'ont calmé. Ne jamais oubliée une chose, meme si les portages sont plus facile, l'assembleur reste le langage ultime en vitesse et en taille (Un de mes copros ne disposent que de 4k de ram interne !). J'ai dernierement discuté avec une personne qui a developpé un compacteur / décompacteur LZW, il a dit que sur un ARM9 a 66 Mhz ca peinait a décompresser. Faut savoir une chose avec un copro a 32 Mhz on arrive a lire du MP3, En C c'est possible ?

Pourquoi est ce que les PC doivent augmenter leur fréquence d'horloge tous les mois ? Car tout le monde programme en C et au lieu d'optimiser leur code (Combien pensent qu'un compilateur optimise mieux qu'une personne ! ) ou d'écrire en assembleur.

Ximoon :
Au moins en assembleur, il n'y a pas de pièges de syntaxe, et par certains côtés je trouve ça bien plus lisible que du C

200% avec toi, l'assembleur est plus lisible. Le coté scryptique du C est assez lourd a avaler (i++=1, if a==4, etc....)

Asm Power !!

GT Un fanatique de l'assembleur !!

J'avoue apprécier l'assembleur, mais juste pour me faire plaisir à moi-même en fait.

Ceci dit, il est clair que pour exploiter un proc avec 4K de mémoire, difficile de faire cela autrement.

Mais justement il me semble que l'architecture de la GP2x dispose de largement suffisamment de puissance
et de mémoire pour permettre un code plus générique. Si tu adores l'assembleur, je comprend que tu trouves
que cela soit un peu du gachis. Mais j'imagine que toi aussi tu trouves cela inutilement long et répétitif de faire
tous les codes simples en assembleur genre initialiser tes périphériques, charger des fichiers de ressources ...

Le compromis idéal reste encore de faire un code haut niveau pour tout ce qui n'est pas crucial en performance,
et de faire des petites routines ASM pour le reste, qui devront être adaptées en cas de portage.

magiceyes :
J'avoue apprécier l'assembleur, mais juste pour me faire plaisir à moi-même en fait.

Ceci dit, il est clair que pour exploiter un proc avec 4K de mémoire, difficile de faire cela autrement.

Mais justement il me semble que l'architecture de la GP2x dispose de largement suffisamment de puissance
et de mémoire pour permettre un code plus générique. Si tu adores l'assembleur, je comprend que tu trouves
que cela soit un peu du gachis. Mais j'imagine que toi aussi tu trouves cela inutilement long et répétitif de faire
tous les codes simples en assembleur genre initialiser tes périphériques, charger des fichiers de ressources ...

Le compromis idéal reste encore de faire un code haut niveau pour tout ce qui n'est pas crucial en performance,
et de faire des petites routines ASM pour le reste, qui devront être adaptées en cas de portage.

tout a fait d'accord pour moi c'est le mieu et ca rend l'application plus portable