MorphOS tourne sur iMac G5…

Voici ce que nos amis outre-Manche appellent un “proof of concept” (une démonstration de faisabilité en bon françois bien de chez nous). En effet Frank Mariak, membre de la MorphOS Team, a mis en ligne quatre photos montrant MorphOS sur un iMac G5 doté d’une carte graphique Radeon X600.

Rien d’officiel dans cette “annonce” qui n’en est pas une, mais on sait désormais que si la MorphOS Team s’y attelle, alors MorphOS pourrait bien tourner sur quelques Mac G5 d’ici quelques temps.

Voici donc les quelques photos disponibles :

Source : OSNews.com

30 Commentaires

Passer au formulaire de commentaire

  1. Le jour ou morphos support plusieurs processeurs ca va faire mal sur les mac g5 quad!

    Le x1000 va pleurer 😀

    • sur 2 janvier 2011 à 16h59

    Se jour est loin d’être arrivé 😀

    Le X1000 ne pleura pas, par contre les G5 quad core… si…. d’avoir un OS qui gère pas les 4 core… sur AOS se sera seulement 2…

    • sur 2 janvier 2011 à 18h31

    Oh ca ca m’interesse je vais ptete en recup un gratos 🙂

    • Tiki sur 2 janvier 2011 à 20h50

    En ce moment, c’est pas la fête pour les ImacG5. Les pannes se multiplient de manère assez importante du faite de l’âge et, peut être, de problème de conception de la machine. Alimentations, Cartes mères, Chipsets graphiques. Tout a l’air de partir en vrille. Il suffit de regarder les forums MacGé.
    Pour ma part, j’opterais plutôt pour un PowerMac G5 refroidit par air.

    Tiki

  2. la morphos team planche sur le G5, je m’atelle aussi a morphos.

    Le x1000 ne vas plus tardé, normale que la MosTeam joue la carte de la puissance, parcontre se seras un mos 3.XX, il y auras peut être un repaiement de la liscence.

    • serge sur 3 janvier 2011 à 0h20

    @ sayasupacrew :
    c’est pas dit que ce soit en V3.xx que MorphOS supporte le G5. Comme l’a dit Fab à maintes reprises, la version 3 de MorphOS correspond à une version de développement réservée à la MOSTeam.
    Et puis, quelque soit la version qui supportera le G5, comme de toutes façons la licence est dépendante de la carte mère, tous les G5 devrons avoir une nouvelle licence uisque ca n’aura aucun sens de vouloir les mettre à jour.
    Pour ce qui est des autres machines, Peg, Powermac G4 etc, bah, le jour où il faut payer une nouvelle licence, je ne pleurerai pas car la licence en 2.x a déjà pas mal d’années et j’estime en avoir bien profité 🙂

    J’espère en tous cas qu’il supporterons aussi t surtout les PowerMac G5 car comme l’as souligné tiki, les Imac tombent comme des mouches alors que les PowerMac sont presque eternels.

    pour comparaison avec la capture faite par Frank Mariak sur l’Imac G5, voici ce que renvoit memtest sur mon PEG II et sur mon Macmini 1,25Ghz

    PEG II @1Ghz

    Nouvelle tâche Shell 2
    Ram Disk:> memtest
    Allocated memory at 0x2B8790C0 -> 0x3DA1963F, 303695232 bytes
    Writing 0x00000000… 425 MB/sec.
    Verifying 0x00000000… 191 MB/sec.
    Writing 0xFFFFFFFF… 390 MB/sec.
    Verifying 0xFFFFFFFF… 208 MB/sec.
    Memory is ok!
    Ram Disk:>

    Macmini @1,25Ghz

    Nouvelle tâche Shell 2
    Ram Disk:> memtest
    Allocated memory at 0x22F4CEC0 -> 0x5C8E763F, 966371200 bytes
    Writing 0x00000000… 721 MB/sec.
    Verifying 0x00000000… 338 MB/sec.
    Writing 0xFFFFFFFF… 737 MB/sec.
    Verifying 0xFFFFFFFF… 347 MB/sec.
    Memory is ok!
    Ram Disk:>

    ImacG5@2,1Ghz

    Données reprises sur la capture d’écran:

    Neuer Shell – Prozess 3
    Ram Disk:> memtest
    Allocated memory at 0x27032F40 -> 0x59F4D63F, 854697728 bytes
    Writing 0x00000000… 986 MB/sec.
    Verifying 0x00000000… 1599 MB/sec.
    Writing 0xFFFFFFFF… 993 MB/sec.
    Verifying 0xFFFFFFFF… 1609 MB/sec.
    Memory is ok!
    Ram Disk:>

    données compilées pour une meilleure lisibilité :
    PEG-II@1GhzMacmini@1,25GhzImacG5@2,1Ghz

    Writing 0x00000000…
    425 MB/sec.——-721 MB/sec.—–986 MB/sec.

    Verifying 0x00000000…
    191 MB/sec.——-338 MB/sec.—–1599 MB/sec.

    Writing 0xFFFFFFFF…
    390 MB/sec.——-737 MB/sec.—–993 MB/sec.

    Verifying 0xFFFFFFFF…
    208 MB/sec.——-347 MB/sec.—–1609 MB/sec.

    Dire que l’imac G5 éclate littéralement le Pegasos et le Macmini c’est peu dire !!! 😮 😮 😮

    • crisot sur 3 janvier 2011 à 5h43

    Niveau ram, y’a pas photo, le X1000 tourne plus vite 😀

    🙄 😛 😀

    • serge sur 3 janvier 2011 à 10h53

    Crisot : Tu sais nous dire quelle est la différence? Est ce qu’on est à quelques petits MB/s, dizaines ou centaines de MB/s?

    • Fab1 sur 3 janvier 2011 à 12h42

    @crisot

    Niveau ram, y’a pas photo, le X1000 tourne plus vite

    Ca n’a pas vraiment d’importance, car l’allocateur mémoire d’OS4 est là pour diviser toutes les perfs par 10. 🙂

    • sur 3 janvier 2011 à 13h09

    Fab1: lol

    • serge sur 3 janvier 2011 à 13h19

    :lol::lol::lol:

  3. Bonjour,

    C’est bon tout cela 😆 😆 ayant un IMAC G5 1.8 ghz
    je voulais le vendre et bien je le garde 🙂 🙂
    je n’ai jamais eu de problèmes côté fonctionnement,
    comme tout électronique le nettoyage annuel est bénéfique 😉

    j.c.

    • SixK sur 3 janvier 2011 à 14h06

    Bon comme déjà évoqué, les iMac G5 et core2duo (mais ca on s’en fout) semblent avoir de serieux problemes de fiabilité ! 🙁
    Le probleme récurrent semble etre des lignes verticales (jaune, blue ou rose) qui apparaissent à l’ecran. Ceci dit, le probleme semble venir de l’ecran et avec un ecran externe le probleme n’apparait plus.

    SixK

  4. Hé oui, vive le made in China …

    Enfin bref, y a quand même pas photo sur les benchs … ces vieux Macs peuvent être bien utile à la communauté Amiga …

    • serge sur 3 janvier 2011 à 15h45

    comment mesurer la différence de la gestion de la mémoire entre MorphOS et l’AmigaOS4?
    j’aimerai comparer les deux systèmes sur le meme pegasos II.
    La commande memtest n’existe pas sur AmigaOS4 🙁

    • Fab1 sur 3 janvier 2011 à 17h19

    Serge

    C’était en référence à un benchmark d’allocation mémoire que j’ai effectué il y a plusieurs mois, où OS4 se révélait extrêmement inefficace sur des allocations en masse.

    http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=29569&forum=14&106

    OS4 est 312 fois plus lent, en fait.

    • serge sur 3 janvier 2011 à 18h10

    @ fab1 : OS4 est 312 fois plus lent !!!

    Est ce possible pour un système qui fonctionne malgré tout relativement correctement?

    N’y a t il pas un cas particulièrement défavorable à l’OS4 qui en réalité est rare et qui aurait été mesuré?

    Faut il croire que l’AmigaOS4 est réellement sur la moyenne des opérations 312 fois plus lent? !!!

    Ça me parait inconcevable ca ! 😮 😮 😮

    • crisot sur 3 janvier 2011 à 18h13

    Il est fort probable que le Bench de Fab soit tout à fait exact.

    Tout comme il est certain que ça n’a aucune incidence dans la pratique.

    On alloue/desalloue pas de la ram à tout bout de champ. Et le temps d’allocation n’a aucune incidence sur les performances d’acces à la ram.

    • Fab1 sur 3 janvier 2011 à 18h43

    @crisot

    On alloue/desalloue pas de la ram à tout bout de champ. Et le temps d’allocation n’a aucune incidence sur les performances d’acces à la ram.

    Si tu connaissais le C++, tu dirais pas ça. 🙂
    Mal utilisé (et c’est bien souvent le cas), ça induit des tonnes d’allocations de ce genre.

    @serge

    en pratique, ça ne se ressent pas autant, car c’est un cas pas trop trop fréquent (les allocations de taille substancielle semblent être le goulot d’étranglement, mais il faudrait revérifier).
    Mais même sur un benchmark plus usuel, le SLAB se fait défoncer par TLSF.

    • crisot sur 3 janvier 2011 à 20h22

    Mal utilisé

    Libre aux autres d’être des billes.

    • Fab1 sur 3 janvier 2011 à 20h34

    Oui, mais le truc c’est que WebKit, FireFox, QT, pleins de jeux sont des grosses bibilles en C++ qui n’y vont pas à la cuillère sur les allocations mémoire. 🙂

    • serge sur 3 janvier 2011 à 20h42

    @ Fab1: tu voulais peut être dire qui n’y vont pas avec le dos de la cuillère 😉

    /me est tout content comme un gammin idiot d’avoir réussi à corriger Fab 😉

    • Fab1 sur 3 janvier 2011 à 20h45

    Oui, en effet. Ca m’apprendra à taper des conneries. 🙂
    J’ai fait un mix entre “à la louche” et “dos de cuillère”.

    • crisot sur 4 janvier 2011 à 3h40

    Manque plus que quelqu’un pour placer “le dos de la louche” et on aura fait les 4 combis possibles 🙂

    • JaY sur 4 janvier 2011 à 17h13

    A priori tu viens de le faire crisot :clap:

    Bon sinon globalement le seul qui ai tout compris ici c’est tiki … Pas la peine de rêver. Les Mac G5 sont d’une conception désastreusement mal pensée. Bilan ca chauffe et ca meurt très jeune ou du moins les problèmes sont si nombreux qu’il faut être suicidaire pour placer des billes dans ce type de matos … Dommage car coté perfs ils n’étaient pas inintéressants …

    Bref si la la mos team perd du temps sur un tel portage perso je n’y comprendrai pas grand chose … 🙄

    • serge sur 4 janvier 2011 à 18h45

    @ Jay : il ne faut pas confondre Imac G5 et PowerMac G5.
    Je travaille avec plusieurs PowerMac G5 depuis leur sortie et je peux te garantir que ce sont des machines très très solides.

    • JaY sur 4 janvier 2011 à 19h06

    @serge: Et bien touches du bois alors. Je ne voudrais pas te faire stresser mais les Powermac G5 sont mort par pelotons entiers … Et ce malgré les refroidissement de fou que posait apple sur les modèles plus récents … 😕

    • sur 5 janvier 2011 à 18h01

    @FAB1 & Crisot:

    Si on alloue de la mémoire à des tableaux, mais avant la boucle principale d’un PRG, sa a une incidence sur la vitesse du programme sous AOS?

    Se problème d’allocation est présent sur tous les “compatible” AOS?

    Après avoir alloué ses espaces mémoire, si j’y accède, mon programme ne sera pas ralenti? si?

    • crisot sur 5 janvier 2011 à 18h38

    Non, si tu alloue ton buffer avant la boucle principale de ton programme, cela n’aura pas d’incidence sur les perf lors de l’acces.

    Ca commence à avoir une incidence si tu commences à libérer/réallouer de la ram en plein millieu d’une boucle (pour étendre un buffer par exemple).

    • sur 5 janvier 2011 à 21h02

    Merci crisot, en fin de compte se bug n’a pas réélement d’inscidence car normalement (moi en tant que bidouilleur bien sur ;-)) j’alloue pas de la mémoire durant une boucle principale, je le fais avant pour la précalculation ou la lecture de données (fichier par exemple)… perso, je vois pas l’interêt d’allouer de la mémoire pendant l’exécution de la boucle principale, pour mes Prgs bien sûr.

    Mais c’est vrai aussi que je m’oriente plus sur le jeux que le prg pro.

    Merci encore pour l’info caillin 😉

    Sa va m’aider pour les tests de perf hollywood

Les commentaires sont désactivés.

Amiga Impact