IPB

Bienvenue invité ( Connexion | Inscription )

3 Pages V  < 1 2 3  
Reply to this topicStart new topic
> Apple n'abandonnera pas le Thunderbolt avec l'arrivée de ses nouveaux Mac ARM, Réactions à la publication du 09/07/2020
Options
raoulito
posté 15 Jul 2020, 13:52
Message #61


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 6 809
Inscrit : 24 Jan 2014
Lieu : La Vienne
Membre no 189 026



Citation (SartMatt @ 15 Jul 2020, 11:47) *
Citation (Sethy @ 15 Jul 2020, 12:40) *
Citation (SartMatt @ 15 Jul 2020, 12:37) *
Citation (Macintox @ 15 Jul 2020, 11:18) *
Et ça chauffe du côté d'ARM, belle bagarre en perspective avec en toile de fond l'énorme chèque qui pourrait faire d"apple le propriétaire de ARM ?? ça doit en inquiéter quelues uns
Je vois pas l'intérêt qu'aurait Apple a devenir propriétaire d'ARM : ça lui ferait payer très cher ce qu'elle peut obtenir pour beaucoup moins cher avec une licence...

Bien sûr, il y aurait en plus le côté "emmerder la concurrence". Mais ça, ça serait extrêmement surveillé : les autorités de la concurrence ne vont pas laisser un fabricant de smartphone racheter ARM sans grosses garanties sur le respect de la concurrence.
+1. C'est le meilleur moyen pour qu'au mieux, tous les concurrents puissent bénéficier de toutes les puces d'Apple ou qu'au pire, la division CPU d'Apple doivent être scindée du groupe.
Ou aussi de racheter une coquille presque vide : la concurrence pourrait décider de se passer d'ARM, tout simplement... Ça prendrait un peu de temps, mais ça réduirait à plus grand chose la valeur d'ARM.


mais pour faire evoluer les instructions I/O imposées par la licence ARM ? actuellement apple doit s’en tenir à cela, contractuellement. En prenant une grosse partie d’arm, pas forcement tout, mettons les 20% du fond cree par softbank, ils auraient peut-être une oreille plus attentive e tla possibilité de proposer des evolutions dont les puces apple seraient les premieres à profiter (vu que préparées plus en amont) ?
juste une hypothèse


--------------------
Çà c'est ma création, un podcast associatif racontant une histoire de SF : http://reduniverse.fr La plus grande saga galactique jamais racontée en podcast :)

Et pour beaucoup de monde ici et ailleurs…

Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout.
JULES CLARETIE
Go to the top of the page
 
+Quote Post
Macintox
posté 15 Jul 2020, 14:39
Message #62


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 3 145
Inscrit : 18 Jan 2004
Membre no 13 512



Citation (raoulito @ 15 Jul 2020, 14:52) *
Citation (SartMatt @ 15 Jul 2020, 11:47) *
Citation (Sethy @ 15 Jul 2020, 12:40) *
Citation (SartMatt @ 15 Jul 2020, 12:37) *
Citation (Macintox @ 15 Jul 2020, 11:18) *
Et ça chauffe du côté d'ARM, belle bagarre en perspective avec en toile de fond l'énorme chèque qui pourrait faire d"apple le propriétaire de ARM ?? ça doit en inquiéter quelues uns
Je vois pas l'intérêt qu'aurait Apple a devenir propriétaire d'ARM : ça lui ferait payer très cher ce qu'elle peut obtenir pour beaucoup moins cher avec une licence...

Bien sûr, il y aurait en plus le côté "emmerder la concurrence". Mais ça, ça serait extrêmement surveillé : les autorités de la concurrence ne vont pas laisser un fabricant de smartphone racheter ARM sans grosses garanties sur le respect de la concurrence.
+1. C'est le meilleur moyen pour qu'au mieux, tous les concurrents puissent bénéficier de toutes les puces d'Apple ou qu'au pire, la division CPU d'Apple doivent être scindée du groupe.
Ou aussi de racheter une coquille presque vide : la concurrence pourrait décider de se passer d'ARM, tout simplement... Ça prendrait un peu de temps, mais ça réduirait à plus grand chose la valeur d'ARM.


mais pour faire evoluer les instructions I/O imposées par la licence ARM ? actuellement apple doit s’en tenir à cela, contractuellement. En prenant une grosse partie d’arm, pas forcement tout, mettons les 20% du fond cree par softbank, ils auraient peut-être une oreille plus attentive e tla possibilité de proposer des evolutions dont les puces apple seraient les premieres à profiter (vu que préparées plus en amont) ?
juste une hypothèse


trés bonne hypothèse . le fait que l'annonce d'une vente ou IPO arrive au moment ou Apple annonce son passage au tout ARM pointe clairement au minima vers une participation pour jouir de plus de liberté, de contrôle, assurer ses arrières, sans s'attirer les foudres des autorités de la concurrence. Mais à ce niveau et vu les enjeux, ça va faire chauffer les chéquiers même des petits porteurs si c'est un IPO.
ET ...n'oublions pas que Apple est a l'origine du ARM co développé avec Acorn computer ,en 1996 Apple et Acorn avaient 43% chacun ! https://en.wikipedia.org/wiki/Acorn_Compute...venture-56'
Apple and Acorn began to collaborate on developing the ARM, and it was decided that this would be best achieved by a separate company.[55] The bulk of the Advanced Research and Development section of Acorn that had developed the ARM CPU formed the basis of ARM Ltd. when that company was spun off in November 1990. Acorn Group and Apple Computer Inc each had a 43% shareholding in ARM (in 1996),[56] while VLSI was an investor and first ARM licensee.[57]

Ce message a été modifié par Macintox - 15 Jul 2020, 14:50.
Go to the top of the page
 
+Quote Post
patrick_a_a
posté 15 Jul 2020, 17:30
Message #63


Nouveau Membre


Groupe : Membres
Messages : 21
Inscrit : 13 Jul 2004
Membre no 20 964



Citation (captaindid @ 15 Jul 2020, 14:46) *
quelques petites précisions

Quelques précisions de détail (ou pas ?)

Citation (captaindid @ 15 Jul 2020, 14:46) *
Citation (patrick_a_a @ 15 Jul 2020, 00:59) *
Mon expérience :
Dans les années 1980, il y avait beaucoup de familles et producteurs de microprocesseur 16 bits (Fairchild, National, Texas Instruments, Intel, Motorola).
Les deux les plus populaires étaient Intel avec le 8086 et Motorola avec le 68000.

le 68000 était un processeur 32 bits; soit, le bus de données était sur 16 bits, et le bus d'adressage sur 24bits, mais le jeu d'instructions était bien 32 bits et pas 16bits, c'est le même que celui des 68020 etc... qui sont eux entièrement 32 bits.

Mon école avait fait en 1979 un symposium dont le titre était : "processeurs 16 bits, pourquoi faire ?".
Les produits présentés l'étaient comme 16 bits par leurs constructeurs, y compris Motorola avec son 68000 (et le futur 68008 avec 2 bus 8 bits multiplexés pour les adresses et données).
Mais comme autre référence, je citerais la page Wikipédia : https://fr.wikipedia.org/wiki/Motorola_68000, où il est écrit :
Citation
Le 68000 est qualifié de 16/32 bits car ses registres ont une largeur de 32 bits et ses instructions acceptent des données de 8, 16 et 32 bits. Toutefois, l'ALU (Unité arithmétique et logique) a une largeur de 16 bits, ce qui fait que les opérations sur 32 bits prennent plus de cycles d'horloge pour être exécutées. En outre, les bus externes ont une largeur de 16 bits pour les données et de 24 bits pour les adresses.

Je confirme bien que les registres étaient sur 32 bits, mais pas les instructions, qui étaient sur 16, 24, 32 ou 48 bits, même sur les 68060.
Exemple dans le code donné dans la fiche Wikipedia https://en.wikipedia.org/wiki/Motorola_68000
12C0 <=> move.b d0,(a1)+
66E6 <=> bne [PC-24]


Citation ( @ 15 Jul 2020, 14:46) *
le principal problème des CPU intel 16bits étaient, outre leur petit nombre de registres spécialisés, un adressage sur 20 bits obtenu avec deux registres 16 bits, décalés de 4 bits: la pire "bonne idée" jamais eue: la gestion de l'adressage et des pointeurs était un vrai casse tête et nécessitait beaucoup de vérifications pour ne pas faire n'importe quoi, dès qu'on utilisait plus de 64ko de données consécutives!
Je plussoie totalement. L'utilisation des CS:, DS:, SS: et ES: était une vraie plaie quand le code était écrit directement en assembleur.

Citation (captaindid @ 15 Jul 2020, 14:46) *
ces défauts ont disparu avec l'apparition du 32 bits : plus de registres généraux, et plus du tout de problème d'adressage;
enfin si! Intel n'a pas pu s’empêcher de recommencer cette connerie avec l'adressage 36 bits sur Xeon: deux registres 32bits décalés de 4 bits
le 64bits introduit par AMD ajoute encore plus de registres généraux et est définitivement exempt de problèmes d'adressage!
Je confirme la disparition du problème de segments à partir de l'Intel 80386, si il est utilisé en mode 32bits et autre que réel, qui était le mode par défaut au boot, par compatibilité et cela semble toujours être le cas pour les core iX ! Une sacrée compatibilité !
Par contre, je confirme que le jeu d'instruction est resté globalement le même (différence : ajout d'instructions de manipulations de bit) et si la spécialisation des registres a bien diminué, leur nombre n'a pas augmenté. Seul a augmenté le nombre de bases de segments (ajout des FS: et GS:) et la longueur des instructions pour les ajouts.


Citation (captaindid @ 15 Jul 2020, 14:46) *
Citation (patrick_a_a @ 15 Jul 2020, 00:59) *
Pour donner une idée, nos premiers programmes qui utilisaient QuickTime 0.9, permettaient en 1992 d'afficher des vidéos de 320 x 240 en 15 i/s sur des Mac avec des processeurs 68030 à 25 MHz.
Pour pouvoir les afficher avec des routines écrites en assembleur sur les PC, il a fallu attendre des 80486 à 50 MHz.

tu laisses entendre qu'un 68030/25 est aussi puissant qu'un 486/50: c'est bien évidement faux: les processeurs des deux constructeurs, de même génération et de même fréquence, ont "à peu près" la même puissance.
la différence que tu cites ne vient-elle pas de QuickTime 0.9? un programme fait par Apple pour le 68k et adapté plus ou moins bien sur PC, en tout cas pour cette version des débuts. Pour les versions suivantes, on pouvait lire les même vidéos avec la même qualité sur mac et PC me semble-t-il...
Mon affirmation est que sur Mac IIci, les routines QuickTime 0.9 et betas précédentes permettaient d'afficher ces vidéos dès 1991.
Sur les PC, QuickTime n'existait pas sur les PC. Nous étions de bons codeurs en assembleur (auparavant, j'avais réalisé des Rom-Bios pour des compatibles PC Matra et BULL, des BIOS embarqués pour des cartes ISA réseau SLDC, X25, RNIS et des cartes graphiques fabriquées par le CNET spécialisées dans l'affichage en natif d'images au format ISO-ADCT, ancêtre du JPEG).
Et malgré le code écrit en C, puis optimisé en assembleur, nous avons du attendre les PC 486 DX2/50 en 1993 pour pouvoir afficher ces mêmes vidéos, ce que voulaient les clients car les PC étaient déjà plus nombreux et bien moins couteux que les Mac IIci.
Donc, pour moi, les processeurs 80486 et 68030 n'avaient pas le même débit.
Maintenant, il faut comparer les évolutions des fréquences et des versions, ce qui nous amène au point suivant.

Citation (captaindid @ 15 Jul 2020, 14:46) *
Citation (patrick_a_a @ 15 Jul 2020, 00:59) *
Après avoir utilisé un processeur "mainstream" (standard à grande diffusion), mais que Motorola ne faisait plus progresser face aux progrès d'Intel, Apple a cherché des remplaçants et a poussé pour une alliance AIM (Apple-IBM-Motorola) pour le PowerPC.

si, Motorola a bien fait progresser les 68k aussi bien que le camps d'en face (intel), et a même continué après le mac quadra 68040 avec le 68060 qui fut un cuisant échec commercial et donc le dernier de la lignée, car plus de clients : ni Apple (qui a changé d'archi), ni les autres (amiga atari etc...) qui ont tous disparus.
si Apple n'a pas continué sur le 68060 c'est qu'avec Motorola et IBM ils ont vu que l'avenir était au PowerPC, et ils avaient raison: les premiers PowerPC ont enterré la famille 68k et les intels concurrents de l'époque.

à ne pas confondre avec le passage du PowerPC à Intel où là oui, Apple a bien été obligé de changer car ni Motorola ni IBM ne voulaient investir dedans pour suivre le rythme imposé par Intel, vu les faibles parts de marché du mac, et donc les faibles retours sur investissements, vu le prix de plus en plus élevé à chaque générations pour développer une archi CPU, et aussi une nouvelle précision de gravure.

évolutions des gammes des processeurs, pour les Mac et les PC :
Mac :
1984 : 68000 à 8 MHz 1987 : 68020 à 16 MHz 1990 : 68030 à 40 MHz 1991 : 68040 à 25 MHz 1993 : 68040 à 40 MHz

PC :
1984 : 80286 à 12 MHz 1987 : 80386 à 25 MHz 1990 : 80486 à 33 MHz 1991 : 80486 à 50 MHz 1993 : 80486 à 66 MHz

Intel compensait la plus faible efficacité par des vitesses de plus en plus plus importantes. Ce qui a été le cas jusqu'au Pentium 4, qui a montré l'obstacle des fréquences trop élevées pour la transmission des signaux au sein même des puces.
Et la stagnation de Motorola sur des fréquences de plus en plus "larguées" par Intel a bien été un facteur déclencheur de recherche d'une autre solution. La mode était au RISC (ARM fut envisagé, mais trop peu puissant) et la solution RISC d'IBM a été préférée, sous condition de sources multiples de production (Motorola + IBM).

Motorola avait conçu son 68000 pour des stations de travail, il était puissant et a été utilisé pour des Ordinateurs Personnels (PC comme Atari ST, Amiga, Next, Be et Macintosh). Mais le rouleau compresseur Intel a découragé Motorola de poursuivre ses efforts, même si la quantité de traitement des 68040 pouvait être 3 fois supérieur au 68030, les fréquences stagnaient et les publicités parlaient toujours de fréquence, seul terme retenu par les clients !
Dans ma collection, il y a un Powermac 7100 à 66 MHz de 1994. Sacré boost en fréquence par rapport au Macintosh Quadra 840AV de 1993 avec un 68040 à 40 MHz.
Par contre, je ne connais pas de Mac ayant utilisé le 68060. Apple a basculé sur PowerPC en 1994, avant la sortie du 68060.

Pour moi, Apple a bien été "contrainte" de passer au PowerPC.


--------------------
Patrick, amateur de Mac depuis 1985. 3,3 planètes, hélas.
Membre du club des AIPBP (Anciens Inscrits Pas Beaucoup de Posts) Voir la liste
Go to the top of the page
 
+Quote Post
Sethy
posté 15 Jul 2020, 18:31
Message #64


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 548
Inscrit : 12 Jul 2011
Membre no 168 767




Intéressant, mais vous "oubliez" un point essentiel ... l'OS.

Il a fallu attendre Windows 95 pour avoir le premier OS Windows "grand public" (omettons ici Windows NT et Linux) qui tire parti du fameux mode réel (ou protégé) des i386. Aucune versions de Windows 3.x (même Windows for Workgroup 3.11) n'était capable d'utiliser ce mode.

La fameuse pub "Macintosh 84" en réponse à "Windows 95" était pertinente puisque dès cette date, l'OS des Macs était multitâche (préemptif) alors que Windows 3.0 n'était pas multitâche (il fallait que les programmes rendent gentiment la main de temps à autre à l'OS principe affublé du qualificatif de "multitâche coopératif").

A titre indicatif, le Pentium 90 date de '94 ... donc c'est bien postérieur au 486 de '89 qui quasiment pendant toute sa durée de vie n'a été exploité sous Windows 3.x (qui avait besoin, rappelons-le d'un dos) et donc dans un mode castré.


--------------------
iMac 21,5" mid 2011 - core i7 - 24 GB - HD 6970M - Maverick
MacBook Air 2014 - core i3 - 8 GB - 128 GB - Maverick
iPad mini 1- 64 GB - iOS 7
Hack X99 - 970 GTX 2015 - Gigabyte X99-UD4 - i7 5830K - Yosemite - Unibeast Lien
DS-918+ - Syno Primary - DS-412+ - Syno Back-up

Go to the top of the page
 
+Quote Post
captaindid
posté 15 Jul 2020, 19:56
Message #65


Adepte de Macbidouille
*

Groupe : Membres
Messages : 82
Inscrit : 6 Sep 2004
Lieu : entre la chaise et le clavier
Membre no 23 160



@Sethy
tu as raison, microsoft n'était pas (n'est toujours pas?) le must en ce qui concerne les OS, mais là on parlait CPU. Intel n'y est pour rien dans les archi moisies de MS.
Enfin tu oublies NT3.11 (une beta en fait) puis surtout NT3.51 : multitâche préemptif, mémoire virtuelle et protégé, en fait tout ce qu'il y a dans un OS moderne, mais avec l'interface graphique de Win3.11. Il est sorti un peu avant win95 et surtout était beaucoup plus stable (pas dur, ça!). j'ai eu l'occasion de bosser dessus, ça marchait bien. par contre ils n'en ont pas vendu des tonnes, NT a commencé à percer avec NT4

@patrick_a_a
merci de ta réponse détaillée
en fait on est d'accord en général; c'était juste histoire de pinailler un peu; ça fait du bien de ressortir de temps en temps nos vieux souvenirs de matos révolus.
quand on parle de CPU 32 bits , on parle d'un CPU qui travaille sur des registres 32 bits, mais bien sur il peut utiliser des données sur autre chose que 32 bits: par exemple sur 8 bits pour traiter des chaines de caractères.
de même un CPU 16 bits utilise des registres 16 bits mais peu traiter des nombres plus grands, répartis sur plusieurs registres; sinon, n'utiliser que des nombres sur 16 bits serait impossible: n serait limité à 65535 pour les entiers non signés par ex: c'est inutilisable!
un CPU 32 bits utilise aussi des adresses sur 32 bits, ce qui ne veut pas dire que physiquement il utilise ces 32 bits: 24 dans le cas du 68000, mais bien 32 pour les suivants
de même un CPU 64 bits traite les adresses sur 64 bits, bien que physiquement les CP actuels n'ont que 40 à 48 bits de bus d'adressage
idem le bus de données pour un CPU 32 bits est souvent de 32 bits, bien que le 68000 soit sur 16bits, le pentium sur 64 ...

après il y a une différence entre RISC et CISC
les CPU RISC ont peu d'instructions et toutes de même taille, ce qui simplifie la conception de la logique du CPU.
les CPU CISC ont beaucoup plus d'instructions, avec des adressage mémoire pléthoriques, et de taille différentes, pas forcément sur 32 bits, donc la taille d'une instruction d'un CPU 32 bits n'est pas forcément 32 bits.
maintenant il n'y a plus de RISC vs CISC : le code est traduit en interne en micro instructions, exécutées dans le désordre (c'est à dire pas dans l'ordre d'arrivée, pas que c'est le bordel)

concernant le nombre de registres, je me suis rafraichi la mémoire et en effet, tu as raison, au passage au 32 bits, le nombre de registres n'a pas progressé, c'est au passage au 64 bits qu'AMD a décidé d'en rajouter pour être au niveau de ce qui se faisait chez les concurrents RISC 64 bits

Enfin concernant les différences de performance entre un 68030 et un 486, d'après l'exemple que tu racontes, sur les macs 68030, pour lire les vidéos vous utilisiez quicktime, et sur PC486 un programme fait par ton équipe en C et assembleur.
c'est peut être là la différence: l'algo utilisé dans quicktime pour mac était peut être plus efficace que le votre sur PC, car je ne me souviens pas d'une telle différence de puissance entre mac et PC, quelques % ou dizaines de % en plus chez motorola à génération et fréquence équivalente, tout au plus; compensé effectivement par une fréquence supérieure chez intel (le 486DX2-66 cassait la baraque à sa sortie)

tout ça c'est du passé avec des archi disparues; voire des fondeurs disparus : motorola devenu en partie freescale.
mais le match continue : intel/amd vs ARM à la sauce apple
les paris sont ouverts ...

Ce message a été modifié par captaindid - 15 Jul 2020, 19:59.


--------------------
"What else?" - George Clooney
Go to the top of the page
 
+Quote Post
SartMatt
posté 15 Jul 2020, 21:00
Message #66


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 31 804
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (Sethy @ 15 Jul 2020, 19:31) *
Il a fallu attendre Windows 95 pour avoir le premier OS Windows "grand public" (omettons ici Windows NT et Linux) qui tire parti du fameux mode réel (ou protégé) des i386. Aucune versions de Windows 3.x (même Windows for Workgroup 3.11) n'était capable d'utiliser ce mode.
Le mode réel, c'est au contraire le mode dans lequel le CPU 286 ou supérieur (y compris ceux d'aujourd'hui, qui ont toujours ce mode réel) "émule" un 86/186 (donc notamment restriction de l'adressage mémoire sur 20 bits, soit une limite de 1 Mo) pas une nouveauté du 386.

Le mode protégé a été introduit avec le 286 (adressage 24 bits, soit 16 Mo, et introduction de la mémoire virtuelle, avec un espace d'adressage virtuel dédié à chaque processus et inaccessible aux autres processus, d'où le nom "protégé").

Et le 386 a amélioré ce mode protégé, avec notamment le passage à des adresses 32 bits (4 Go). Ce mode protégé est resté le mode principal de tous les CPU x86 32 bits (avec une nouvelle extension à 40 bits pour les adresses sur la fin, avec le PAE), et fait aujourd'hui partie du mode legacy des CPU x86 64 bits (mode qui est utilisé quand on fait tourner un OS 16 ou 32 bits, avec un OS 64 bits c'est le long mode qui est utilisé).

Et Windows 3 gérait bel et bien les 3 modes (réel, protégé 286 et protégé 386, que Microsoft avait appelé mode étendu), en choisissant automatiquement le meilleur mode supporté par le CPU.

Je pense que tu confonds avec le 32 bits, qui lui effectivement n'était pas géré par Windows 3 au niveau de l'OS (il était toutefois possible de lancer des applications 32 bits, après avoir installé la bibliothèque Win32s). Windows 95 a effectivement été le premier Windows grand public à gérer nativement le 32 bits.

Citation (captaindid @ 15 Jul 2020, 20:56) *
quand on parle de CPU 32 bits , on parle d'un CPU qui travaille sur des registres 32 bits, mais bien sur il peut utiliser des données sur autre chose que 32 bits: par exemple sur 8 bits pour traiter des chaines de caractères.
Et il peut aussi y avoir des registres plus grands... Les 32 bits font référence à la taille des registres généraux.

Avec certaines instructions spécialisées, il y a des registres plus gros. Le MMX a par exemple introduit des registres 64 bits dans des CPU x86 32 bits, le SSE en a introduit de 128 bits, et aujourd'hui avec l'AVX les plus gros registres des CPU x86 64 bits font 512 bits.

Ce message a été modifié par SartMatt - 15 Jul 2020, 21:03.


--------------------
Go to the top of the page
 
+Quote Post
Sethy
posté 15 Jul 2020, 21:01
Message #67


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 548
Inscrit : 12 Jul 2011
Membre no 168 767




Si j'ai dit une connerie, pas de problème, je le reconnais volontiers.

Mais je me souviens très très bien de l'énorme différence qu'il y avait sous Windows NT matérialisé par un curseur qui se transformait en un pointeur joint à un sablier quand une tâche de fond s'exécutait. Tout comme cette histoire de multitâche préemptif contre le multitâche coopératif.


--------------------
iMac 21,5" mid 2011 - core i7 - 24 GB - HD 6970M - Maverick
MacBook Air 2014 - core i3 - 8 GB - 128 GB - Maverick
iPad mini 1- 64 GB - iOS 7
Hack X99 - 970 GTX 2015 - Gigabyte X99-UD4 - i7 5830K - Yosemite - Unibeast Lien
DS-918+ - Syno Primary - DS-412+ - Syno Back-up

Go to the top of the page
 
+Quote Post
amike
posté 15 Jul 2020, 21:05
Message #68


Macbidouilleur de vermeil !
****

Groupe : Membres
Messages : 1 306
Inscrit : 9 Aug 2012
Membre no 178 091



"intel/amd versus ARM à la sauce Apple"
-> C'est d'autant plus vrai qu'Apple voudrait être autonome aussi pour sa partie graphique. Exit AMD et ses GPU...

"Transition de 2 ans"
->Si Apple a des difficultés, ils ne sont pas obligés de faire des compromis et peuvent se contenter à commencer par des "super ipad pro" : mac OS, pas de contrainte thermique ou d'énergie,... La transition pourrait très bien être continuée pour le mac pro s'il faut vraiment une carte graphique puissante.

"Apple abandonne Intel"
Est-ce qu'Apple est le seul à avoir cela en tête ? Des ARM pour server sont sorties récemment, pourquoi n'iraient-ils aussi sur le marché du Desktop ; les Chromebooks n'ont pas de problème de compatibilité logiciel, Microsoft a à dispo un Windows ARM...
Go to the top of the page
 
+Quote Post
SartMatt
posté 15 Jul 2020, 21:08
Message #69


Macbidouilleur d'Or !
*****

Groupe : Rédacteurs
Messages : 31 804
Inscrit : 15 Nov 2005
Membre no 49 996



Citation (amike @ 15 Jul 2020, 22:05) *
les Chromebooks n'ont pas de problème de compatibilité logiciel, Microsoft a à dispo un Windows ARM...
Et dans ces deux cas, les versions ARM font un flop par rapport aux versions x86... Même pour Chrome OS qui n'a pourtant pas un long historique applicatif x86, et même, dont la principale source d'application est aujourd'hui le Play Store d'Android, donc une plateforme pourtant plutôt ARM...


--------------------
Go to the top of the page
 
+Quote Post
malloc
posté 15 Jul 2020, 22:11
Message #70


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 729
Inscrit : 5 Sep 2004
Membre no 23 103



Citation (Sethy @ 15 Jul 2020, 22:01) *
Si j'ai dit une connerie, pas de problème, je le reconnais volontiers.

Mais je me souviens très très bien de l'énorme différence qu'il y avait sous Windows NT matérialisé par un curseur qui se transformait en un pointeur joint à un sablier quand une tâche de fond s'exécutait. Tout comme cette histoire de multitâche préemptif contre le multitâche coopératif.


Cote Windows je ne sais pas, mais côté MacOS il y a confusion.
MacOS n’a été 100% préemptif qu’à partir de OS X dans les années 2000!

Avant, on était encore sur du coopératif. Un process pouvait tout à fait capter 100% du CPU s’il n’utilisait pas explicitement les MPThreads ou oubliait d’appeler régulièrement l’infâme YieldToAnyThread() hérité des bas-fonds de la ToolBox...

Donc la vérité, c’est que le System 7 et MacOS 8/9 étaient carrément à la traîne de ce côté là, pas en avance sur leur temps pour un sou!
Go to the top of the page
 
+Quote Post
patrick_a_a
posté 15 Jul 2020, 22:39
Message #71


Nouveau Membre


Groupe : Membres
Messages : 21
Inscrit : 13 Jul 2004
Membre no 20 964



Citation (Sethy @ 15 Jul 2020, 22:01) *
Si j'ai dit une connerie, pas de problème, je le reconnais volontiers.

Mais je me souviens très très bien de l'énorme différence qu'il y avait sous Windows NT matérialisé par un curseur qui se transformait en un pointeur joint à un sablier quand une tâche de fond s'exécutait. Tout comme cette histoire de multitâche préemptif contre le multitâche coopératif.

Donc, pour moi, autre correction : Mac OS Classic, sur lequel j'ai programmé de la 6.0.2 à la 8.6 était bien un multi-tâche coopératif (et non préemptif comme tu l'as écris plus haut). Il était tellement facile de le bloquer dans un traitement sans GetNextEvent ou autre appel au Event manager...
Citation
La fameuse pub "Macintosh 84" en réponse à "Windows 95" était pertinente puisque dès cette date, l'OS des Macs était multitâche (préemptif) alors que Windows 3.0 n'était pas multitâche (il fallait que les programmes rendent gentiment la main de temps à autre à l'OS principe affublé du qualificatif de "multitâche coopératif").

Je n'ai pas compris ta phrase sur la Pub "Mac 1984" en réponse à Windows 95 ? Comment répondre en 1984 à Windows 1995 ?
Rappel : Windows a été créé en pompant allègrement Mac OS, lorsque Microsoft a réalisé un Basic sur le Mac (MacBasic / Microsoft Basic).
Je n'ai pas utilisé Windows 1.0, mais Windows 2.0, sorti en 1987 et sur lequel je n'ai jamais réussi à faire fonctionner une autre réalisation en 1988. Bien moins de soucis avec Windows 3.0 en 1990.
Et Windows NT était extraordinairement stable et sûr dès sa sortie. Son concepteur Dave Cutler était un des piliers du système VMS.

Quand aux différences des algorithmes et des OS, quelques précisions sur ma comparaison :
autant pour le Mac, nous étions contraints à la version 7.0 avec QuickTime, autant sur le PC nous avions le choix des armes.

Donc, nous avons réalisé le programme sur PC dans deux systèmes :
- depuis DOS étendu, avec notre propre scheduler de tâches avec priorité maximale sur le programme de décodage vidéo (nous avions comme autres tâches les communications sur Numéris en mode X25 avec des cartes OST et concurrentes).
- Puis nous avons comparé avec le même programme de décodage vidéo utilisé avec le système QNX.
Malgré les très bonnes performances de QNX, que je garde toujours en grande estime, notre réalisation DOS était deux à trois fois plus rapide. Il faut dire que nous tapions directement dans les buffers des cartes vidéo en mode DOS.

Et les clients choisissaient la version DOS, car les vidéos étaient lisibles à partir du 486 DX2, même si l'interface n'était pas belle, alors que la présentation en mode QNX Photon microGUI, ou X-Window, était plus jolie, mais tellement saccadée !

Alors, je persiste à penser que nous produisions un code de qualité et que seule la vitesse d'horloge compensait la moindre puissance des processeurs Intel.
Rappel :
pour le Mac IIci, en 1991 : 68040 à 25 MHz, pour le Mac Quadra 640AV en 1993 : 68040 à 40 MHz
pour les PC de pointe, en 1991: 80486 à 50 MHz et en 1993 : 80486 à 66 MHz


--------------------
Patrick, amateur de Mac depuis 1985. 3,3 planètes, hélas.
Membre du club des AIPBP (Anciens Inscrits Pas Beaucoup de Posts) Voir la liste
Go to the top of the page
 
+Quote Post
Sethy
posté 15 Jul 2020, 23:26
Message #72


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 548
Inscrit : 12 Jul 2011
Membre no 168 767




Je viens de me (re)plonger dans ces histoires de multitâches coopératifs / préemptifs.

Plutôt que de recopier toute la section du wiki, voici une source : https://en.wikipedia.org/wiki/Preemption_(c...#System_support

Pour la comparaison Macintosh 84, voici un quote : "I got a t-shirt that year that reads "Windows '95. All the features of Macintosh '84." I still wear it."

Source : https://www.cultofmac.com/386189/how-apple-...ears-ago-today/



--------------------
iMac 21,5" mid 2011 - core i7 - 24 GB - HD 6970M - Maverick
MacBook Air 2014 - core i3 - 8 GB - 128 GB - Maverick
iPad mini 1- 64 GB - iOS 7
Hack X99 - 970 GTX 2015 - Gigabyte X99-UD4 - i7 5830K - Yosemite - Unibeast Lien
DS-918+ - Syno Primary - DS-412+ - Syno Back-up

Go to the top of the page
 
+Quote Post
malloc
posté 16 Jul 2020, 07:49
Message #73


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 729
Inscrit : 5 Sep 2004
Membre no 23 103



Citation (Sethy @ 16 Jul 2020, 00:26) *
Je viens de me (re)plonger dans ces histoires de multitâches coopératifs / préemptifs.

Plutôt que de recopier toute la section du wiki, voici une source : https://en.wikipedia.org/wiki/Preemption_(c...#System_support

Pour la comparaison Macintosh 84, voici un quote : "I got a t-shirt that year that reads "Windows '95. All the features of Macintosh '84." I still wear it."

Source : https://www.cultofmac.com/386189/how-apple-...ears-ago-today/


Même ta source confirme que MacOS Classic n'était pas préemptif huh.gif

"Although there were plans to upgrade the cooperative multitasking found in the classic Mac OS to a preemptive model (and a preemptive API did exist in Mac OS 9, although in a limited sense[4]), these were abandoned in favor of Mac OS X (now called macOS)"

(Cela dit tu peux faire confiance: ceux qui ont essuyé les plâtres du Thread Manager des années '90 savent très bien de quoi ils parlent quand ils disent que MacOS Classic était coopératif et non préemptif. Nous avons encore les plaques de cheveux arrachés pour le prouver laugh.gif )

Pour les curieux qui veulent un voyage dans le passé, je conseille la lecture de l'excellent Mactech sur le sujet: http://preserve.mactech.com/articles/macte...ager/index.html
Au-delà de la simple question du multitâche, ça rappelle à quelle point les stacks logicielles ont évolué entre '90 et '00... C'était vraiment le Far West et un changement d'époque complet en 10 ans!

Ce message a été modifié par malloc - 16 Jul 2020, 08:17.
Go to the top of the page
 
+Quote Post
Sethy
posté 16 Jul 2020, 09:32
Message #74


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 548
Inscrit : 12 Jul 2011
Membre no 168 767



Citation (malloc @ 16 Jul 2020, 08:49) *
Même ta source confirme que MacOS Classic n'était pas préemptif huh.gif


Toutafé. Au fond seuls Linux et Windows NT l'étaient à cette époque (2ème semestre 2013).


--------------------
iMac 21,5" mid 2011 - core i7 - 24 GB - HD 6970M - Maverick
MacBook Air 2014 - core i3 - 8 GB - 128 GB - Maverick
iPad mini 1- 64 GB - iOS 7
Hack X99 - 970 GTX 2015 - Gigabyte X99-UD4 - i7 5830K - Yosemite - Unibeast Lien
DS-918+ - Syno Primary - DS-412+ - Syno Back-up

Go to the top of the page
 
+Quote Post
malloc
posté 16 Jul 2020, 09:59
Message #75


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 729
Inscrit : 5 Sep 2004
Membre no 23 103



Citation (Sethy @ 16 Jul 2020, 10:32) *
Citation (malloc @ 16 Jul 2020, 08:49) *
Même ta source confirme que MacOS Classic n'était pas préemptif huh.gif


Toutafé. Au fond seuls Linux et Windows NT l'étaient à cette époque (2ème semestre 2013).


Ah, ton message d'hier soir indiquait le contraire !

Citation
La fameuse pub "Macintosh 84" en réponse à "Windows 95" était pertinente puisque dès cette date, l'OS des Macs était multitâche (préemptif) alors que Windows 3.0 n'était pas multitâche (il fallait que les programmes rendent gentiment la main de temps à autre à l'OS principe affublé du qualificatif de "multitâche coopératif").
Go to the top of the page
 
+Quote Post
Sethy
posté 16 Jul 2020, 10:00
Message #76


Macbidouilleur d'Or !
*****

Groupe : Membres
Messages : 1 548
Inscrit : 12 Jul 2011
Membre no 168 767



Citation (Sethy @ 15 Jul 2020, 22:01) *
Si j'ai dit une connerie, pas de problème, je le reconnais volontiers.



--------------------
iMac 21,5" mid 2011 - core i7 - 24 GB - HD 6970M - Maverick
MacBook Air 2014 - core i3 - 8 GB - 128 GB - Maverick
iPad mini 1- 64 GB - iOS 7
Hack X99 - 970 GTX 2015 - Gigabyte X99-UD4 - i7 5830K - Yosemite - Unibeast Lien
DS-918+ - Syno Primary - DS-412+ - Syno Back-up

Go to the top of the page
 
+Quote Post
patrick_a_a
posté 16 Jul 2020, 11:15
Message #77


Nouveau Membre


Groupe : Membres
Messages : 21
Inscrit : 13 Jul 2004
Membre no 20 964



Citation (Sethy @ 16 Jul 2020, 10:32) *
Citation (malloc @ 16 Jul 2020, 08:49) *
Même ta source confirme que MacOS Classic n'était pas préemptif huh.gif


Toutafé. Au fond seuls Linux et Windows NT l'étaient à cette époque (2ème semestre 2013).


Je ne comprends pas la référence "2ème semestre 2013".

Personnellement, en me limitant à la fin 1991 aux systèmes multi-tâches préemptif que j'avais rencontré et utilisé, cela donne :
- pour les Ordinateurs personnels : MP/M 86 ; OS/2 ; QNX ; XENIX ; Sinclair QDOS ; AmigaOS ; Concurrent DOS ; PC-MOS/386 ; Minix 1.5 pour Atari

- Pour les stations de travail et les petits serveurs : NetWare 286 ; NetWare 3.1 ; SunOS ; HP/UX ; VMS

Linux 0.01-0.1 sortait, mais personne n'en parlait ...

Au fond, au début des années 90, il y avait pléthore d'OS préemptif, même pour des processeurs 8 bits.
Leur besoin en mémoire nécessitait beaucoup plus de mémoire que les configurations Mac et PC de base, ou moins de fonctionnalités possibles.

Maintenant, pour donner mon avis sur le sujet de ce fil de discussion :
- Pour la programmation, mon système préféré était VMS, suivi de Mac OS, et Windows était bien loin derrière, puis Unix encore plus loin avec ses incohérences ;

- Pour l'utilisation, depuis mon premier Mac (Mac IIx) , je suis resté fidèle aux Mac (Power 7100, 4400, G3, MDD, Mini 2009, MBP 15 2010, MBP Retina 13 2013).

J'ai vraiment apprécié l'architecture interne ARM, du temps du Newton / MessagePad, et maintenant.
J'ai vraiment pesté et juré contre la programmation des processeurs x86.

Mais je refuse l'enfermement. Donc, pas d'iPod, mais un Cowon, pas d'iPhone, mais un Blackberry QNX Q10, puis un LG G6.

Comme je suis quasiment sûr qu'Apple va continuer dans sa politique d'enfermement à la fois logicielle et matérielle, je pense :
- maintenir mes machines actuellement utilisées par ma famille (Mini 2009, MBP 15 2010, MBP Retina 13 2013) le plus longtemps possible, quitte à les migrer sous Linux et si besoin utiliser des VM MacOS ou Windows,
- acheter ultérieurement des machines ARM (comme le Raspberry 4 ou des portables) avec Linux et des VM / émulation comme QEMU.

Je vote avec mon portefeuille...


--------------------
Patrick, amateur de Mac depuis 1985. 3,3 planètes, hélas.
Membre du club des AIPBP (Anciens Inscrits Pas Beaucoup de Posts) Voir la liste
Go to the top of the page
 
+Quote Post

3 Pages V  < 1 2 3
Reply to this topicStart new topic
1 utilisateur(s) sur ce sujet (1 invité(s) et 0 utilisateur(s) anonyme(s))
0 membre(s) :

 



Nous sommes le : 11th August 2020 - 17:33