Vampire V4 julkaistiin A500:lle

Yllämainittu nopeus koskee lähinnä tilannetta, jossa ajetaan 68080:lle optimoitua koodia. Vanha koodi pyörii varmaan noin 2-3x hitaammin, mutta 68060:lle optimoitu koodi varmaan jo paremmin. Superskalaarinen arkkitehtuuri vaatii että konekäskyt tulevat tietyssä järjestyksessä, jotta suoritus olisi mahdollisimman nopeaa. Joka tapauksessa esim. 100 MHz:lla 400 MIPS on maksimi, eli 4 konekäskyä per kellonjakso on maksimi 68080:lla.

Kuitenkin mukana tulee myös AMMX- ja AMMX2-käskykanta, jotka voivat nopeuttaa laskentaa aivan huimasti mm. videon dekoodauksessa, mp3/jpeg-kompression käsittelyssä, alpha blendauksessa, ja tekstuurien filtteröinnissä. Nämä vastaavat Intelin MMX/SSE-käskykantaa, ja AMMX on kokonaislukupohjainen, ja AMMX2 liukulukupohjainen. MMX otettiin käyttöön Intelin Pentium-prosessoreissa ja SSE on alkaen Pentium III:sta.

m36-intj kirjoitti:

Yllämainittu nopeus koskee lähinnä tilannetta, jossa ajetaan 68080:lle optimoitua koodia. Vanha koodi pyörii varmaan noin 2-3x hitaammin, mutta 68060:lle optimoitu koodi varmaan jo paremmin. Superskalaarinen arkkitehtuuri vaatii että konekäskyt tulevat tietyssä järjestyksessä, jotta suoritus olisi mahdollisimman nopeaa. Joka tapauksessa esim. 100 MHz:lla 400 MIPS on maksimi, eli 4 konekäskyä per kellonjakso on maksimi 68080:lla.

Kuitenkin mukana tulee myös AMMX- ja AMMX2-käskykanta, jotka voivat nopeuttaa laskentaa aivan huimasti mm. videon dekoodauksessa, mp3/jpeg-kompression käsittelyssä, alpha blendauksessa, ja tekstuurien filtteröinnissä. Nämä vastaavat Intelin MMX/SSE-käskykantaa, ja AMMX on kokonaislukupohjainen, ja AMMX2 liukulukupohjainen. MMX otettiin käyttöön Intelin Pentium-prosessoreissa ja SSE on alkaen Pentium III:sta.

Lue lisää

Niin tuo AMMX2 ei taida olla mikään liukulukupohjainen, sitä saa vielä odottaa, vaan pelkkä parannus AMMX-käskykantaan.

Vampire FPGA:lla on lähtökohtaisesti kysyntää sen vuoksi, että vanhoja Amigan erikoispiiristöjä ei ole valmistettu yli 20 vuoteen, samaten uusia Motorolan m68k-sarjan prosessoreita ei juuri valmisteta enää. Näin ollen uutta rautaa ei saada juuri mistään ja sen vuoksi esim. 68060-kiihdytinkorttien hinnat ovat nousseet aika huimasti viime aikoina, kun kysyntää kuitenkin on. Turha siis urputtaa siitä, miksi kukaan haluaa ostaa vanhaa Amiga-rautaa, markkinat ja kysyntä ovat mitä ovat.

Riippuu siitä mitä itse haluaa, jos pelkkä softaemulaatio ei kelpaa, ja ei myöskään välitä näistä PPC-Amigoista, jotka ovat epäyhteensopivia vanhojen Amigojen kanssa, niin Vampire FPGA on hyvä valinta, siinä on kuitenkin moninkertaisesti tehoja verrattuna 50 MHz 68060-suorittimeen, ja uusia parempia näyttötiloja, jne.

"pelkkä softaemulaatio ei kelpaa, ja ei myöskään välitä näistä PPC-Amigoista, jotka ovat epäyhteensopivia vanhojen Amigojen kanssa"

PPC-Amigat kuitenkin kykenee ajamaan vanhojen amigoiden softat noin 99%:sti.

Mutta alkuperäinen klassikossa on toki aina omanlaisensa fiilis, mutta nekään ei 100% olleet yhteensopivia edes keskenään saatikka jonkun uuden prosessorituotoksen kanssa. Tuossa mielessä vampire toki voi olla parempi kuin alkuperäinen prossu, koska yhteensopiivuutta voi säätää ohjelmallisesti, prossua ei tarvitse vaihdella.

Se on insinöörimäisten-kokeilunhaluisten-nörttien-lelu.
Muut pysyköön kaukana.
Tällöin ei tule pettymystä.

amigisti-nisti kirjoitti:

"pelkkä softaemulaatio ei kelpaa, ja ei myöskään välitä näistä PPC-Amigoista, jotka ovat epäyhteensopivia vanhojen Amigojen kanssa"

PPC-Amigat kuitenkin kykenee ajamaan vanhojen amigoiden softat noin 99%:sti.

Mutta alkuperäinen klassikossa on toki aina omanlaisensa fiilis, mutta nekään ei 100% olleet yhteensopivia edes keskenään saatikka jonkun uuden prosessorituotoksen kanssa. Tuossa mielessä vampire toki voi olla parempi kuin alkuperäinen prossu, koska yhteensopiivuutta voi säätää ohjelmallisesti, prossua ei tarvitse vaihdella.

Lue lisää

Softaemulaatiota saa halvemmalla ja paremmin esim. WinUAE:lla. PPC-prosessorit ovat varsin epäonnistuneita tekeleitä, RISC-tyyppisiä, hankala ohjelmoida käsin, mutta kuitenkaan eivät kovin tehokkaita, jos vertaa samalla kellotaajuudella muihin suorittimiin. Ainakin vanhemman sukupolven PPC-prosessorit ovat hitaita (601, 603, 604, 620, ja G3/G4). Modernit PPC-Amigat (X1000 ja X5000) taas ovat liian kalliita että niitä kukaan haluaisi, ja niissä aivan samat ongelmat kuin PC-tietokoneissa, eli täysin epäyhteensopivia hardware-tasolla vanhojen Amigojen kanssa.

Täytyy muistaa että Vampire FPGA:ssa tulee mukana myös SAGA, joka on siis toteutus AAA-piiristöstä, joka jäi Commodorelta tekemättä. Koska Amigan 3.x käyttöjärjestelmä on hyvin kevyt, ei tarvita GHz-luokan prosessoria sitä pyörittämään, kun se onnistuu jo melko hyvin 8 MHz 68000-prosessorilla. Voitte varmaan kuvitella miten se lentää 100 MHz:n 68080-prosessorilla, vaikka korkeampaa resoluutiota käyttäisikin. AGA-koneet olivat vielä hitaita, johtuen hitaasta grafiikkamuistista, mutta Vampire FPGA:ssa muistinopeus on noin 600 MB/s.

>Softaemulaatiota saa halvemmalla ja paremmin esim. WinUAE:lla.

Mutta tällöin on pakko käyttää windowsia kaikkine satoine puutteineen ja v*ttumaisuuksineen.

> PPC-prosessorit ovat varsin epäonnistuneita tekeleitä,

Höps. Melkolailla parhaat koskaan tehdyt RISC suorittimet.
Nytkin superkoneissa käytetään paljon PPC sukuisia.

> RISC-tyyppisiä,

Aikakautensa tuote. Silloin oli yleinen näkemys että RISC:llä voidaan tehdä tehokkaampia prosessoreja. Mutta tilanne on muuttunut sikäli että kaikissa prosessoreissa on konepellin alla jotain muuta kuin RISC tai CISC vaikka käskykanta olisi jompi kumpi.

Nykyisin RISC prosessorit ovat kuitenkin yleisimpiä ja käytetyimpiä prosessoreja maailmassa.
Pari vuotta sitten miltei jokainen pelikonsolikin oli powerpc pohjainen.

> hankala ohjelmoida käsin,

Höps.
Paljon helpompi ohjelmoida kuin binääriperverssit intelit.
Mutta PPC amigoita voi ohjelmoida ongelmitta myös 68000 CISC koodilla, jos haluaa.
Toimii ihan suoraan.

Erona kuitenkin alkuperäisiin se että konekieltä ei samassa määrin ole pakko käyttää koska prossutehoa on moninkertainen määrä.

>mutta kuitenkaan eivät kovin tehokkaita, jos vertaa samalla kellotaajuudella muihin suorittimiin.

Ainoastaan moderni intel on samalla kellotaajuudella merkittävästi nopeampi.
Amigalle ei kuitenkaan ole juurikaan ohjelmistoa joka hyötyisi esim. yli 2ghz prosessorista.
Nykyiset PPC amigat on jopa satoja kertoja nopeampia kuin alkuperäiset.
Nopeus on siis suhteellista.

>Ainakin vanhemman sukupolven PPC-prosessorit ovat hitaita (601, 603, 604, 620, ja G3/G4).

Jos vertaa saman aikakauden muihin prosessoreihin, ei ne niin hitaita olleet.
PowerPC prossut eivät vain pärjää moderneille intel/AMD tuotteille.

>Modernit PPC-Amigat (X1000 ja X5000) taas ovat liian kalliita että niitä kukaan haluaisi, ja niissä aivan samat ongelmat kuin PC-tietokoneissa,

Isot/tehokkaat Amiga on aina olleet kalliita.
Mun koneiden hinnat euroiksi muunnettuna
-A500 800€
-A2000 1700€
-A4000 2300€ 060 CPU 1200€ 3D 500€
-Sam440ep 1000€

Tuon SAM:n hankinnan jälkeen en ole nuita vanhempia enään käynnistänyt ... ehkä kertaakaan.

>eli täysin epäyhteensopivia hardware-tasolla vanhojen Amigojen kanssa.

On totta että jos haluaa videon kautta naatiskella AGA/OCS/ECS ominaisuuksista, tällöin on oltava vanhoja amigoita (kaikki eri mallit).
Mutta jos haluaa tehdä muutakin (jotain puolimodernia) niin sitten mielestäni on oltava A4000/060:aa nopeampi laite. Mieluummin yli 1000Mhz kuin alle.

>Täytyy muistaa että Vampire FPGA:ssa tulee mukana myös SAGA, joka on siis toteutus AAA- piiristöstä, joka jäi Commodorelta tekemättä.

Sille vain ei ole oikein mitään softaa joka sitä tukisi.
Itse kun hankin näytönohjaimen AGA koneeseen, en AGA:aa enään käyttänyt kuin demoissa yms. jotka ei näytönohjainta ymmärtäneet.

Mikään FPGA pohjainen näytönohjain ei pärjää moderneille näytönohjaimille, tuskin edes mun vanhalle cybervisionille.

>Koska Amigan 3.x käyttöjärjestelmä on hyvin kevyt, ei tarvita GHz-luokan prosessoria sitä pyörittämään, kun se onnistuu jo melko hyvin 8 MHz 68000-prosessorilla. Voitte varmaan kuvitella miten se lentää 100 MHz:n 68080-prosessorilla,

Omassa AGA koneessa on 50Mhz 68060 ja sillä AOS3 toimii jouhevasti. Sanoisin kuitenkin että 8Mhz prossu liikuttaa vain perus 3.1 käyttistä joten kuten. Esim. AOS3.9 käyttikselle 25Mhz 030 on suosittelemani minimi.

Mun tehokkaimmassa amigamyllyssä 666Mhz PPC ajaa Amigasoftaa reilusti nopeammin.
Joku voisi sanoa FPGA 68080:sta "mutta kuitenkaan eivät kovin tehokkaita".

Mielestäni SAM440ep AOS4.1 -kombinaatiolla yhteensopivuus commodoren aikaisiin sovelluksiin on parempi kuin mun A4000 koneella, johtunee siitä että oikealla raudalla yhteensopivaksi säätäminen (mode promotion yms) on vaikeampaa.

>vaikka korkeampaa resoluutiota käyttäisikin.
>AGA-koneet olivat vielä hitaita, johtuen hitaasta grafiikkamuistista, mutta Vampire FPGA:ssa muistinopeus on noin 600 MB/s.

AGA:ssa taisi olla 28MB/s.
Mun A4000 näytönohjaimessa 180MB/s väylällä toimi 1024x768x24bit grafiikat hyvällä nopeudella.
Ja nykyisessä SAM440ep koneessa on 1600MB/s muistiväylä grafiikalle. 1920x1080x24bit toimii nopeammin kuin yksikään amiga sitä aikaisemmin.

Voin minäkin joskus ehkä vampirea kokeilla... mutta x5000 kiinnostaa enemmän... kun vain olisi 2000€ ylimääräistä.

PowerPC- ja ARM-prosessoreissa on vakio 32-bittinen konekäskypituus, mikä aiheuttaa todella paljon turhaa koodia. Jos haluaa ladata 64-bittisen osoitteen rekisteriin, niin siihen vaaditaan yhteensä 5 konekäskyä PowerPC-prosessorilla. Myöskin 32-bittiseen osoitteeseen vaaditaan useita käskyjä. 680x0-prosessorilla osoitteen lataamiseen tarvitaan vain yksi käsky. Samat ongelmat tulevat eteen tietysti kun vakioita haluaa käsitellä, yhdessä 32-bittisessä konekäskyssä on tilaa useinkin vain yhdelle 16-bittiselle luvulle, koska toinen puolikas menee itse konekäskyn koodaamiseen. 680x0-prosessorissa on taas vaihtuvanpituiset konekäskyt, joihin mahtuu kaksi 32-bittistä lukua tai 68080-prosessorissa kaksi 64-bittistä lukua. Puhumattakaan siitä, että RISC-arkkitehtuurit ovat load/store-tyyppisiä, ei ole mitään monimutkaisia osoitusmuotoja, joita tarvitaan sujuvaan konekieliohjelmointiin.

Käyttämäsi 667MHz SAM440ep on myös hidas, se hävisi 93 MHz:n 68080:lle yhdessä lajittelubenchmarkissa, jonka Apollocore-tiimi teki vertauksena PPC-suorittimiin. Tässä PowerPC:n hitaus käy ilmi, siinä SAM440ep:ssa on myös jotain ongelmia muistinopeudessa.
http://www.apollo-core.com/index.htm?page=performance

Niin, todellakin vain AmigaOS 3.0-3.1 toimivat 68000-prosessorilla, ja AOS 3.5-3.9 vaativat paljon enemmän, mutta nämä ovat jotain puolivirallisia käyttöjärjestelmäpäivityksiä, eivät Commodoren tekemiä. Nythän tulee myös päivitys 3.1:lle 3.1.4 muodossa, se on virallinen päivitys.

Jos minä haluaisin konekielellä koodata, koodaisin toki 68k koodia koska se toimii SAM440ep:ssä ihan suoraan.

Aina tietenkin löytyy keinotekosiia/synteettisiä testejä joka 68080 saadaan nopeammaksi kuin ikivanhalla PPC440 prossulla, jossa ei ole edes L2 välimuistia.
Moderneissa on kuitenkin. Samoin löytyy 128bittiset vektorilaskentayksiköt ja 128bittiset muistiväylät ja ytimiä riittämiin.

>puolivirallisia käyttöjärjestelmäpäivityksiä, eivät Commodoren tekemiä. Nythän tulee myös päivitys 3.1:lle 3.1.4 muodossa, se on virallinen päivitys.

Kyllä ne aivan virallisia olivat. Myöskään 3.1.4 ei tule olemaan commodoren tekemä.
AOS4.1 on viimeisin virallinen Amigakäyttis joka pohjautuu 3.1 koodiin.

Pidän AOS-versioita 3.5 ja 3.9 epäonnistuneina, ne olivat lähinnä kosmeettisia parannuksia, joissa käyttöliittymän grafiikkaa parannettiin ja lisättiin TCP/IP-pino, ja muita apuohjelmia. Voi myös kysyä miksi siirryttiin taas takaisin 3.1-versioon, kun tätä 3.1.4 päivitystä tehdään. 3.1.4 versiossa sentään yritetään korjata vanhoja bugeja esim. tiedostojärjestelmästä ja muista käyttöjärjestelmän osista, mitkä olisi pitänyt tehdä kauan aikaa sitten, eikä vain lisätä uusia ominaisuuksia. 3.1.4 toimii myös edelleen 68000-prosessorilla, toisin kuin 3.5 ja 3.9.

Minun tietääkseni haage&partner ei ole koskaan luovuttanut 3.5 ja 3.9 versioissa käytettyjä lähdekoodeja. Siksi re-start on tehty 3.1:stä sekä 4.1:n että tuohon 3.1.4:n.

m36-intj kirjoitti:

Softaemulaatiota saa halvemmalla ja paremmin esim. WinUAE:lla. PPC-prosessorit ovat varsin epäonnistuneita tekeleitä, RISC-tyyppisiä, hankala ohjelmoida käsin, mutta kuitenkaan eivät kovin tehokkaita, jos vertaa samalla kellotaajuudella muihin suorittimiin. Ainakin vanhemman sukupolven PPC-prosessorit ovat hitaita (601, 603, 604, 620, ja G3/G4). Modernit PPC-Amigat (X1000 ja X5000) taas ovat liian kalliita että niitä kukaan haluaisi, ja niissä aivan samat ongelmat kuin PC-tietokoneissa, eli täysin epäyhteensopivia hardware-tasolla vanhojen Amigojen kanssa.

Täytyy muistaa että Vampire FPGA:ssa tulee mukana myös SAGA, joka on siis toteutus AAA-piiristöstä, joka jäi Commodorelta tekemättä. Koska Amigan 3.x käyttöjärjestelmä on hyvin kevyt, ei tarvita GHz-luokan prosessoria sitä pyörittämään, kun se onnistuu jo melko hyvin 8 MHz 68000-prosessorilla. Voitte varmaan kuvitella miten se lentää 100 MHz:n 68080-prosessorilla, vaikka korkeampaa resoluutiota käyttäisikin. AGA-koneet olivat vielä hitaita, johtuen hitaasta grafiikkamuistista, mutta Vampire FPGA:ssa muistinopeus on noin 600 MB/s.

Lue lisää

"Softaemulaatiota saa halvemmalla ja paremmin esim. WinUAE:lla."

Halvempaa ja parempaa on kirjoittaa koodi niin, että sen voi kääntää nappia painamalla uusiksi kun alusta muuttuu.

Tuossa toisessa viestissä mainittu SDL on esimerkiksi oikein kiva, vuosikymmenestä toiseen sama koodi toimii.

kuka tekee mitäkin
jotkut tekee musiikkia, jotkut animaatiota, julkaisee lehtiä, 3d mallinnusta, maisemagenerointia, ohjaa automaatiota, tekee multimediaesityksiä, jotkut tekee pelejä ja jotkut pelaa pelejä https://en.wikipedia.org/wiki/List_of_Amiga_games .

Tuolta näkee mitä ilmaista softaa on helposti saatavissa: http://aminet.net/

Tuo on aika hauska:
https://www.youtube.com/watch?v=s1RsvEm7UrU (miksi käyttää amigaa, englanniksi)

Tuoltakin voi selvitä lisää:
https://amigaworld.net//
https://distrita.com/10-reasons-amigaos-still-rulez-2016/


Tuolla on suomalaisia harrastelijoita: http://saku.bbs.fi/foorumi/

Tuossa taitaa olla yksi parhaista vanhojen amigoiden harraste -foorumeista:
http://eab.abime.net/

Kyllä tuo on oikeasti nostalgiafiilistelyyn.

Jos Amigalla jotain tärkeätä on, sen ohjelman kyllä kääntää tai vaikka tekee uusiksi nykyvehkeille.

M-Kar kirjoitti:

Kyllä tuo on oikeasti nostalgiafiilistelyyn.

Jos Amigalla jotain tärkeätä on, sen ohjelman kyllä kääntää tai vaikka tekee uusiksi nykyvehkeille.

AmigaOS olisi mukeva saada "nykyvehkeille".

Harmi että emulaatioväännökset vaativat bloat-roskan allensa, koska muuten ei rautaa saa käyntiin.
https://www.amikit.amiga.sk/

Mutta systeemin saa näyttämään siltä että winkkaria tai linuxia ei ole mutta kaikki niiden sovellukset saa käyntiin AmigaOS:n kautta ja ikkunaan.

-Amigisti

Anonyymi kirjoitti:

AmigaOS olisi mukeva saada "nykyvehkeille".

Harmi että emulaatioväännökset vaativat bloat-roskan allensa, koska muuten ei rautaa saa käyntiin.
https://www.amikit.amiga.sk/

Mutta systeemin saa näyttämään siltä että winkkaria tai linuxia ei ole mutta kaikki niiden sovellukset saa käyntiin AmigaOS:n kautta ja ikkunaan.

-Amigisti

Lue lisää

AmigaOS:ssa tuskin on mitään ominaisuutta ei löytyisi uudemmista.

Muutamanlaisia on olemassa.
https://www.v2.fi/artikkelit/viihde/523/Minimig/
http://amigastore.eu/en/318-mist-fpga-computer.html

Amigisti-nisti kirjoitti:

Muutamanlaisia on olemassa.
https://www.v2.fi/artikkelit/viihde/523/Minimig/
http://amigastore.eu/en/318-mist-fpga-computer.html

Lue lisää

Vau, tuokin oli mulle uutta että Comptetition Pro joystic perinteisellä Atari -liitännällä on otettu uudelleen tuotantoon, siis jotain 80-luvulla saatavilla ollutta on tänä päivänä saatavana uutena, aika huikeaa :)

kaikenmoista tulee ja menee
https://www.verkkokauppa.com/fi/product/34487/jbdjs/Atari-Flashback-8-HD-Gold-pelikonsoli

Ei kait sitä muu voi selittää kuin että retro myy.
Tai me entiset 8bit:lla aloittaneet ollaan nyt 50 kriisissä tulleet hulluiksi.

Amigisti-nisti kirjoitti:

kaikenmoista tulee ja menee
https://www.verkkokauppa.com/fi/product/34487/jbdjs/Atari-Flashback-8-HD-Gold-pelikonsoli

Ei kait sitä muu voi selittää kuin että retro myy.
Tai me entiset 8bit:lla aloittaneet ollaan nyt 50 kriisissä tulleet hulluiksi.

Lue lisää

Heh, olen 43v ja menin ostamaan tuon C-64 minin :D Pelaillessa tulee mieleen muistoja siitä aidosta ja alkuperäisestä kuusnelosesta joka mulla kerran oli.
On tuota kyllä tallessa vielä muita aitoja ja alkuperäisiä koneita...

Tuo on hyvin alhainen suorituskyky, ja kuvanlaatu on heikko.

Raspberry Pi 4 maksaa muutaman kympin, ja siinä on 3840x2160 resoluutio eikä mitään värirajoitteita.

Ymmärrän toki tuon minimalismi ajatuksen, että ei tehdä möhköä ja ymmärrän myös koodin optimointajatuksen mutta sekin on vähän huono syy hankkia tuota. Sitä voi tehdä vaikka tuolla Raspberry Pi:llä. Paitsi että jos tekee Raspberry Pi:llä jotain siistiä se on kova juttu jos leuka putoaa lattiaan muutaman kympin tietokoneen mahtavilla tehoilla.

Jos se on myyntivaltti, että sama laite ajaa vanhoja Amigan ohjelmia niin tuo on lähinnä nostalgianälkään.

Et ole käyttänyt Amigaa aikaisemmin? Itse käyttöjärjestelmä on suunniteltu toimimaan 8 MHz:n MC68000:lla. Vampire V4:n on noin 300 kertaa nopeampi, ja sillähän se käyttöjärjestelmä lentää. AmigaOS on moninkertaisesti kevyempi pyörittää kuin esim. Windows 95, vaikka tarjoaakin suunnilleen samat ominaisuudet. Muistiakin kuluu huomattavasti vähemmän.

Mitä resoluutioon tulee, niin 2D-toimintapeleihin ei useinkaan tarvita enemmän kuin 640x512, mutta kyllähän sitä saa paljon enemmän tietysti Vampirella. On vaikeaa myöskin tehdä grafiikkaa käsin bitmap-pohjaisesti korkealla resoluutiolla. Lähes kaikki pelit Amigalle tehtiin 320x200 tai 320x256 resoluutiolla ja 16/32 värillä. Copper-apupiirillä sai sitten huomattavasti enemmän värejä näytölle.

Mitä tulee Raspberry Pi:hin, se ei yksinkertaiseti kelpaa, ARM/PowerPC-prosessorit ovat kehnoja, ja niitä ei voi helposti ohjelmoida assembler-kielellä. Amigalle suuri osa softasta on kuitenkin tehty assemblerkielellä, ja tehdään edelleen, koska se ei ole niin vaikeaa hyvän prosessorin ansiosta.

"Et ole käyttänyt Amigaa aikaisemmin?"

Olen toki.

"Vampire V4:n on noin 300 kertaa nopeampi, ja sillähän se käyttöjärjestelmä lentää."

Ei se myöskään tee oikein mitään.

"AmigaOS on moninkertaisesti kevyempi pyörittää kuin esim. Windows 95, vaikka tarjoaakin suunnilleen samat ominaisuudet."

Sekään ei tee oikein mitään. Ankea käyttää. 80- ja 90-luvun oksennuksissa oli myös paljon bugeja vaikka eivät tehneet juuri mitään.

"Mitä resoluutioon tulee, niin 2D-toimintapeleihin ei useinkaan tarvita enemmän kuin 640x512"

Näyttää röpelöiseltä.

"On vaikeaa myöskin tehdä grafiikkaa käsin bitmap-pohjaisesti korkealla resoluutiolla."

Alkoivat jo 80-luvun puolella esirenderöimään, että pikselien asettelun sijasta kirjoitetaan vaikka skriptiä että asetellaan primitiivejä kuten pallo, kuutio, kartio, torus jne. ja skaalaillaan, tehdään CSG:tä, tai vaikka polygonimeshiä.

Siitä saadaan sitten saadaan laskettua ns. täydellisesti halutulla resoluutiolla ja frameja niin paljon kuin haluaa. Niitä perusprimitiivejä voi nysvätä vaikka yhtä paljon kuin 320x200 tarkkuudelle sopii pikseleitä mutta saadaan laskettua vaikka 3840x2160 tarkkuudelle natiivisti.

"Mitä tulee Raspberry Pi:hin, se ei yksinkertaiseti kelpaa, ARM/PowerPC-prosessorit ovat kehnoja, ja niitä ei voi helposti ohjelmoida assembler-kielellä."

ARM prosessorit ovat oikein mainioita. Niissä on paljon elegantimpi käskykanta kuin Motorolassa tai Intelin/AMD:n jutuissa.

Mutta, sillä ei ole merkitystä. Kääntäjät on keksitty sitä varten, että ei tarvitse assembleria kirjoittaa. Ennen muinoin kääntäjät oli toki alkeellisempia kun silloin yritettiin ensisijaisesti saada se kääntäjä toimimaan. Nykyään ne optimoivat. Meni jo joskus 90-luvulla sellaiseksi, että ihminen ei saanut käsin assemblerilla nysvättyä nopeammaksi. Olivat aika poikkeavia juttuja missä onnistui ja oli joku sisin silmukka missä oli kierretty kääntäjä.

Tosin silloinkin oli vaikka käytössä kääntäjä mikä haki optimaalisen käskykombon hakemalla sitä bruteforcella jostain hakuavaruudesta, että jätetty koneet rouhimaan sitä optimaalista assemblerkoodia: https://en.wikipedia.org/wiki/Superoptimization

Käytännössä sitten kun on kyse isomman mittakaavan optimoinneista, voi ihminen jäädä kakkoseksi kun hyödynnetään rinnakkaisuutta ja pitää varmistaa, että koodissa ei ole minkäänlaisia sivuvaikutuksia ja kehittyneet välineet auttaa varmistamaan sitä.

Yksi merkittävä asia mikä myös pitää huomioida on bugit. Yksi ihminen ei oikein pysty hallitsemaan valtavia määriä koodia kun se koodikokonaisuus ei enää sovikkaan kehittäjän päähän. Yli 100000 rivillä alkaa tulla ongelmia joten onkin sitten tarvetta myös saada koodirivejä vähemmälle.

"Amigalle suuri osa softasta on kuitenkin tehty assemblerkielellä, ja tehdään edelleen, koska se ei ole niin vaikeaa hyvän prosessorin ansiosta."

Siinä ei kuitenkaan ole oikein mitään järkeä tehdä assemblerkielellä kun voi tehdä siistimmän, nopeamman, siirrettävän ja virheettömämmän käyttämällä kääntäjää.

m36-intj kirjoitti:

Et ole käyttänyt Amigaa aikaisemmin? Itse käyttöjärjestelmä on suunniteltu toimimaan 8 MHz:n MC68000:lla. Vampire V4:n on noin 300 kertaa nopeampi, ja sillähän se käyttöjärjestelmä lentää. AmigaOS on moninkertaisesti kevyempi pyörittää kuin esim. Windows 95, vaikka tarjoaakin suunnilleen samat ominaisuudet. Muistiakin kuluu huomattavasti vähemmän.

Mitä resoluutioon tulee, niin 2D-toimintapeleihin ei useinkaan tarvita enemmän kuin 640x512, mutta kyllähän sitä saa paljon enemmän tietysti Vampirella. On vaikeaa myöskin tehdä grafiikkaa käsin bitmap-pohjaisesti korkealla resoluutiolla. Lähes kaikki pelit Amigalle tehtiin 320x200 tai 320x256 resoluutiolla ja 16/32 värillä. Copper-apupiirillä sai sitten huomattavasti enemmän värejä näytölle.

Mitä tulee Raspberry Pi:hin, se ei yksinkertaiseti kelpaa, ARM/PowerPC-prosessorit ovat kehnoja, ja niitä ei voi helposti ohjelmoida assembler-kielellä. Amigalle suuri osa softasta on kuitenkin tehty assemblerkielellä, ja tehdään edelleen, koska se ei ole niin vaikeaa hyvän prosessorin ansiosta.

Lue lisää

Jos nyt jostain syystä kokee, että assembler paradigmana on mitä ideaalisin niin sitä voi kirjoittaa vaikka tällä: https://webassembly.org/

Saa modernin raudan mukavuudet käyttöön ja koodi siirrettäväksi.

M-Kar kirjoitti:

"Et ole käyttänyt Amigaa aikaisemmin?"

Olen toki.

"Vampire V4:n on noin 300 kertaa nopeampi, ja sillähän se käyttöjärjestelmä lentää."

Ei se myöskään tee oikein mitään.

"AmigaOS on moninkertaisesti kevyempi pyörittää kuin esim. Windows 95, vaikka tarjoaakin suunnilleen samat ominaisuudet."

Sekään ei tee oikein mitään. Ankea käyttää. 80- ja 90-luvun oksennuksissa oli myös paljon bugeja vaikka eivät tehneet juuri mitään.

"Mitä resoluutioon tulee, niin 2D-toimintapeleihin ei useinkaan tarvita enemmän kuin 640x512"

Näyttää röpelöiseltä.

"On vaikeaa myöskin tehdä grafiikkaa käsin bitmap-pohjaisesti korkealla resoluutiolla."

Alkoivat jo 80-luvun puolella esirenderöimään, että pikselien asettelun sijasta kirjoitetaan vaikka skriptiä että asetellaan primitiivejä kuten pallo, kuutio, kartio, torus jne. ja skaalaillaan, tehdään CSG:tä, tai vaikka polygonimeshiä.

Siitä saadaan sitten saadaan laskettua ns. täydellisesti halutulla resoluutiolla ja frameja niin paljon kuin haluaa. Niitä perusprimitiivejä voi nysvätä vaikka yhtä paljon kuin 320x200 tarkkuudelle sopii pikseleitä mutta saadaan laskettua vaikka 3840x2160 tarkkuudelle natiivisti.

"Mitä tulee Raspberry Pi:hin, se ei yksinkertaiseti kelpaa, ARM/PowerPC-prosessorit ovat kehnoja, ja niitä ei voi helposti ohjelmoida assembler-kielellä."

ARM prosessorit ovat oikein mainioita. Niissä on paljon elegantimpi käskykanta kuin Motorolassa tai Intelin/AMD:n jutuissa.

Mutta, sillä ei ole merkitystä. Kääntäjät on keksitty sitä varten, että ei tarvitse assembleria kirjoittaa. Ennen muinoin kääntäjät oli toki alkeellisempia kun silloin yritettiin ensisijaisesti saada se kääntäjä toimimaan. Nykyään ne optimoivat. Meni jo joskus 90-luvulla sellaiseksi, että ihminen ei saanut käsin assemblerilla nysvättyä nopeammaksi. Olivat aika poikkeavia juttuja missä onnistui ja oli joku sisin silmukka missä oli kierretty kääntäjä.

Tosin silloinkin oli vaikka käytössä kääntäjä mikä haki optimaalisen käskykombon hakemalla sitä bruteforcella jostain hakuavaruudesta, että jätetty koneet rouhimaan sitä optimaalista assemblerkoodia: https://en.wikipedia.org/wiki/Superoptimization

Käytännössä sitten kun on kyse isomman mittakaavan optimoinneista, voi ihminen jäädä kakkoseksi kun hyödynnetään rinnakkaisuutta ja pitää varmistaa, että koodissa ei ole minkäänlaisia sivuvaikutuksia ja kehittyneet välineet auttaa varmistamaan sitä.

Yksi merkittävä asia mikä myös pitää huomioida on bugit. Yksi ihminen ei oikein pysty hallitsemaan valtavia määriä koodia kun se koodikokonaisuus ei enää sovikkaan kehittäjän päähän. Yli 100000 rivillä alkaa tulla ongelmia joten onkin sitten tarvetta myös saada koodirivejä vähemmälle.

"Amigalle suuri osa softasta on kuitenkin tehty assemblerkielellä, ja tehdään edelleen, koska se ei ole niin vaikeaa hyvän prosessorin ansiosta."

Siinä ei kuitenkaan ole oikein mitään järkeä tehdä assemblerkielellä kun voi tehdä siistimmän, nopeamman, siirrettävän ja virheettömämmän käyttämällä kääntäjää.

Lue lisää

AmigaOS ei tee mitään? Mitä sen sitten pitäisi tehdä? Tehokas moniajo, ja ikkunointijärjestelmä siinä missä nykyaikaisissa järjestelmissäkin. Helposti laajennettavissa, mikrokernelisysteemi. Esim. AmigaOS 3.1:ssa, joka oli viimeinen Commodoren tekemä käyttisversio, ei ollut TCP/IP-tukea, mutta sen pystyi helposti rakentamaan myöhemmin ethernet-driverina ja nettiapplikaationa, joka käytti driveria, joka ei olisi mahdollista esim. Linuxissa, koska kaikki driverit kuuluvat kerneliin.

Amigalle saa myös useimmat GNU-työkalut, kuten make, awk, gcc, sed, latex, emacs, gnuplot, jne. Ne eivät tarvitse Linuxia toimiakseen. Nykyään niitä ei tosin enää ylläpidetä, uudemmat versiot olisikin vaikeaa saada toimimaan enää Amigalle, niiden binäärit ovat paisuneet kuin pullataikina, tuomatta juurikaan lisäarvoa käyttäjille.

Jos tarkoitat ray-tracingia ja vastaavia tekniikoita, niin toki niitä renderöityjä grafiikoita tehtiin joihinkin Amiga-peleihin, kuten esim. Stardustiin, mutta tuo menetelmä ei vaan sovi kaikenlaisen grafiikan tekemiseen.

Se nyt ei pidä paikkaansa, että kääntäjät pystyisivät tekemään parempaa koodia kuin kokenut assemblerohjelmoija. gcc:n m68k-backend tuotti heikkoa koodia vielä 90-luvun lopulla, ja siinä pystyi helposti kirjoittamaan parempaa koodia, vaikka ihan yksinkertaisesta loopista. Sen jälkeen m68k tuki lopetettiin gcc:stä. Tein joskus myös työtä 2000-luvun lopulla Texas Instrumentsin DSP C-kääntäjän kanssa, sen tuottama DSP-koodi oli myös surkeaa, ja sen vuoksi siinä oli valmiit optimoidut DSP-rutiinit assemblerkielellä toteutettuna, joita sitten käytettiin C-ohjelmissa.

Kun nyt katselen omia strategioitani lyhentää assemblerkoodiani, niin makroja voi käyttää myös assemblerilla, ja usein käytetyt valmiit rutiinit voi kääntää binääriksi tiedostoon ja ladata ohjelmaan, johon sitten vain hypätään. Näin ohjelmarivien määrä saadaan alaspäin.

ARM:lla on heikko suorituskyky verrattuna esim. Intelin/AMD-suorittimiin. Sen etuna on halpuus ja energiatehokkuus, mutta se ei kelpaa esim. pöytätietokoneisiin. Elegantti se ei ainakaan ole assemblerohjelmoijan näkökulmasta. Asiaa on käsitelty aikaisemmin tässä ketjussa.

Siirrettävyydellä ei ole juuri merkitystä kun tekee ohjelmia Amigalle, koska monet nykyiset rajapinnat ja kirjastot ovat kuitenkin liian hitaita että ne toimisivat Amigalla (mukaanlukien esim. SDL).

m36-intj kirjoitti:

AmigaOS ei tee mitään? Mitä sen sitten pitäisi tehdä? Tehokas moniajo, ja ikkunointijärjestelmä siinä missä nykyaikaisissa järjestelmissäkin. Helposti laajennettavissa, mikrokernelisysteemi. Esim. AmigaOS 3.1:ssa, joka oli viimeinen Commodoren tekemä käyttisversio, ei ollut TCP/IP-tukea, mutta sen pystyi helposti rakentamaan myöhemmin ethernet-driverina ja nettiapplikaationa, joka käytti driveria, joka ei olisi mahdollista esim. Linuxissa, koska kaikki driverit kuuluvat kerneliin.

Amigalle saa myös useimmat GNU-työkalut, kuten make, awk, gcc, sed, latex, emacs, gnuplot, jne. Ne eivät tarvitse Linuxia toimiakseen. Nykyään niitä ei tosin enää ylläpidetä, uudemmat versiot olisikin vaikeaa saada toimimaan enää Amigalle, niiden binäärit ovat paisuneet kuin pullataikina, tuomatta juurikaan lisäarvoa käyttäjille.

Jos tarkoitat ray-tracingia ja vastaavia tekniikoita, niin toki niitä renderöityjä grafiikoita tehtiin joihinkin Amiga-peleihin, kuten esim. Stardustiin, mutta tuo menetelmä ei vaan sovi kaikenlaisen grafiikan tekemiseen.

Se nyt ei pidä paikkaansa, että kääntäjät pystyisivät tekemään parempaa koodia kuin kokenut assemblerohjelmoija. gcc:n m68k-backend tuotti heikkoa koodia vielä 90-luvun lopulla, ja siinä pystyi helposti kirjoittamaan parempaa koodia, vaikka ihan yksinkertaisesta loopista. Sen jälkeen m68k tuki lopetettiin gcc:stä. Tein joskus myös työtä 2000-luvun lopulla Texas Instrumentsin DSP C-kääntäjän kanssa, sen tuottama DSP-koodi oli myös surkeaa, ja sen vuoksi siinä oli valmiit optimoidut DSP-rutiinit assemblerkielellä toteutettuna, joita sitten käytettiin C-ohjelmissa.

Kun nyt katselen omia strategioitani lyhentää assemblerkoodiani, niin makroja voi käyttää myös assemblerilla, ja usein käytetyt valmiit rutiinit voi kääntää binääriksi tiedostoon ja ladata ohjelmaan, johon sitten vain hypätään. Näin ohjelmarivien määrä saadaan alaspäin.

ARM:lla on heikko suorituskyky verrattuna esim. Intelin/AMD-suorittimiin. Sen etuna on halpuus ja energiatehokkuus, mutta se ei kelpaa esim. pöytätietokoneisiin. Elegantti se ei ainakaan ole assemblerohjelmoijan näkökulmasta. Asiaa on käsitelty aikaisemmin tässä ketjussa.

Siirrettävyydellä ei ole juuri merkitystä kun tekee ohjelmia Amigalle, koska monet nykyiset rajapinnat ja kirjastot ovat kuitenkin liian hitaita että ne toimisivat Amigalla (mukaanlukien esim. SDL).

Lue lisää

"Mitä sen sitten pitäisi tehdä?"

Esimerkiksi saada samaan järjestelmään useita samanaikaisia käyttäjiä ja suojattua eri käyttäjiä toisiltaan, kuin suojattua myös eri ohjelmia toisiltaan.

Tietojenkäsittelyn rinnakkaistaminen on myös kova juttu. Jos nyt seurailee vaikka tätä vuosikymmenien kehitystä niin pari asiaa vaikuttaa vahvasti:

1. Von Neummannin pullonkaula.

Tarkoittaa sitä, että piirit kyllä laskevat kokoajan paremmalla hyötysuhteella mutta siinä on pullonkaulaa ja latenssia kun haetaan tietoa hitaammasta muistista

https://en.wikipedia.org/wiki/Von_Neumann_architecture#Von_Neumann_bottleneck

2. Rinnakkaistaminen

Yhtä laskevaa yksikköä ei voida nopeuttaaa kuin tiettyyn pisteeseen saakka, että prosessointia pitää saada skaalattua mahdollisimman paljon jakamalla sitä useille suoritinyksiköille. Alkaen vaikka lisäämällä CPU-ytimiä, GPU-ytimiä, palvelimia jne.

Rinnakkaistamiselle sitten on omat rajansa myös.

A = B C
D = A E

Niin ei tuo rinnakkaistu koska jälkimmäinen operaatio riippuu aikaisemmasta. Rinnakkaistamiselle on myös tällainen efekti mikä liittyy latenssiin: https://en.wikipedia.org/wiki/Amdahl's_law

Eli siis kuinka siis maksimoidaan laskennan rinnakkaistumista ja minimoidaan Von Neumannin pullonkaulan vaikutusta on avainjuttu kun revitään suorituskykyä.

Nuo pätevät universaalisti mille tahansa raudalle ja tarkoittaa käytännössä sitä, että käsiteltävä data pitäisi saada sopimaan mahdollisimman nopeaan muistiin ja rinnakkaistettua suoritinytimille mitä koneessa tai vaikka useassa keskusyksikössä.

"Nykyään niitä ei tosin enää ylläpidetä, uudemmat versiot olisikin vaikeaa saada toimimaan enää Amigalle, niiden binäärit ovat paisuneet kuin pullataikina, tuomatta juurikaan lisäarvoa käyttäjille."

GNU projektin peruspalikoissa on aika paljon ominaisuuksia että en nyt niitä ottaisi minimalistiseen systeemiin muutenkaan. Tämä taitaa olla viimeisin mikä uppoaa Amigaan ja siinä on rapsittu ylimääräiset pois peruspalikoista: https://www.openbsd.org/55.html

Koodi on myös kohtalaisen siivottua, että pystyisi mergettämään tuoreimmasta OpenBSD:stä korjaukset.

"Se nyt ei pidä paikkaansa, että kääntäjät pystyisivät tekemään parempaa koodia kuin kokenut assemblerohjelmoija."

Pystyy, kun käy vaikka bruteforcella läpi mikä on optimaalisen käskysarjan tai sitten kun tulee nämä mitkä toimii isommassa mittakaavassa, että rinnakkaistetaan ja sitten jos vaikka pitää kopioida puurakenne paikasta toiseen niin tuotetaan koodia missä kopioidaan vain pointteri ja samaa rakennetta käytetään useassa säikeessä kun kääntäjä varmistaa, että siinä koodissa ei ole yhtään sivuvaikutuksia mikä estää tämän.

GCC tuskin tuotti optimaalista 68k koodia missään kohtaan. Tuskin sitä kehitettiin enää ihmeemmin kun 68k prossut väistyi silloin 90-luvulla. Assemblerilla sai Intelille hinkattua Pentium II vehkeillä mutta sen jälkeen meni kääntäjäteknologia kuin myös prosessorien sisäinen käskydekooderi ja suoritusjärjestyksen optimointi sellaiseksi, että menetti merkityksen. C:llä sai oikeastaan aina yhtä hyvää. Ehkä just joku silmukka jossain missä otettiin SIMD huomioon ja bruteforcella kävi että sai sieltä sisimmästä silmukasta viimeisimmät kellojaksot pois mutta se oli sitten siinä. 90-luvun lopulla assembler oli jo hyvin merkityksetön.

Käytännön ohjelmoinnissa kompleksisuuden hallinta on aika keskeistä, myös suorituskykyä optimoidessa.

Noin esimerkiksi, C:llä saa oikein hyvin tehtyä optimoituja ja kapseloituja komponentteja mutta nimiavaruus rajoittaa scopettamista. Se onkin suunniteltu niukemmille muistimäärille ja että tehdään komponentteja joita joissa datavirtoja putkitetaan: https://en.wikipedia.org/wiki/Pipeline_(Unix)

Ja tietysti kun jokainen komponentti on omassa prosessissa ja kommunikoi käyttöjärjestelmän putkien kanssa niin siitä tulee myös hävikkiä vaikka tuossa käyttöjärjestelmä rinnakkaistaa. Joku service mikä käynnistää aina palikan tekee latenssia.

Muistinkulutus pysyy pienenä toki mutta tässä on abstraktiohävikkiä, että voi olla kiinnostuksia ajaa kokonaisuutta enemmän samassa prosessissa. Sitä varten sitten on vaikka oliokieliä kuten vaikka C missä suurempi nimiavaruus, että voi saman prosessin sisälle rakentaa niitä kapseloituja komponentteja.

Kieli on kompleksisempi mutta tuo itseasiassa helposti suuremman suorituskyvyn kapseloiduilla komponenteilla kun jää se abstraktiohävikki pois kun ajetaan samassa prosessissa niitä komponentteja. Ja uudemmat kääntäjät sitten osaa tehdä isomman mittakaavan optimointia kun käyvät kaikkien komponenttien koodimassaa läpi mitä siihen käännökseen tulee. Sattumalta uudemmat kääntäjät alkoikin sitten rohmuta muistia paljon enemmän siinä käännöksessä mutta tuo tulee siitä, kun pyrkivät käsittelemään koko koodimassaa muistissa yhtenä käännettävänä kokonaisuutena, eikä niin että käännetään vaikka sed:istä yksi palikka ja cat:ista toinen.

M-Kar kirjoitti:

"Mitä sen sitten pitäisi tehdä?"

Esimerkiksi saada samaan järjestelmään useita samanaikaisia käyttäjiä ja suojattua eri käyttäjiä toisiltaan, kuin suojattua myös eri ohjelmia toisiltaan.

Tietojenkäsittelyn rinnakkaistaminen on myös kova juttu. Jos nyt seurailee vaikka tätä vuosikymmenien kehitystä niin pari asiaa vaikuttaa vahvasti:

1. Von Neummannin pullonkaula.

Tarkoittaa sitä, että piirit kyllä laskevat kokoajan paremmalla hyötysuhteella mutta siinä on pullonkaulaa ja latenssia kun haetaan tietoa hitaammasta muistista

https://en.wikipedia.org/wiki/Von_Neumann_architecture#Von_Neumann_bottleneck

2. Rinnakkaistaminen

Yhtä laskevaa yksikköä ei voida nopeuttaaa kuin tiettyyn pisteeseen saakka, että prosessointia pitää saada skaalattua mahdollisimman paljon jakamalla sitä useille suoritinyksiköille. Alkaen vaikka lisäämällä CPU-ytimiä, GPU-ytimiä, palvelimia jne.

Rinnakkaistamiselle sitten on omat rajansa myös.

A = B C
D = A E

Niin ei tuo rinnakkaistu koska jälkimmäinen operaatio riippuu aikaisemmasta. Rinnakkaistamiselle on myös tällainen efekti mikä liittyy latenssiin: https://en.wikipedia.org/wiki/Amdahl's_law

Eli siis kuinka siis maksimoidaan laskennan rinnakkaistumista ja minimoidaan Von Neumannin pullonkaulan vaikutusta on avainjuttu kun revitään suorituskykyä.

Nuo pätevät universaalisti mille tahansa raudalle ja tarkoittaa käytännössä sitä, että käsiteltävä data pitäisi saada sopimaan mahdollisimman nopeaan muistiin ja rinnakkaistettua suoritinytimille mitä koneessa tai vaikka useassa keskusyksikössä.

"Nykyään niitä ei tosin enää ylläpidetä, uudemmat versiot olisikin vaikeaa saada toimimaan enää Amigalle, niiden binäärit ovat paisuneet kuin pullataikina, tuomatta juurikaan lisäarvoa käyttäjille."

GNU projektin peruspalikoissa on aika paljon ominaisuuksia että en nyt niitä ottaisi minimalistiseen systeemiin muutenkaan. Tämä taitaa olla viimeisin mikä uppoaa Amigaan ja siinä on rapsittu ylimääräiset pois peruspalikoista: https://www.openbsd.org/55.html

Koodi on myös kohtalaisen siivottua, että pystyisi mergettämään tuoreimmasta OpenBSD:stä korjaukset.

"Se nyt ei pidä paikkaansa, että kääntäjät pystyisivät tekemään parempaa koodia kuin kokenut assemblerohjelmoija."

Pystyy, kun käy vaikka bruteforcella läpi mikä on optimaalisen käskysarjan tai sitten kun tulee nämä mitkä toimii isommassa mittakaavassa, että rinnakkaistetaan ja sitten jos vaikka pitää kopioida puurakenne paikasta toiseen niin tuotetaan koodia missä kopioidaan vain pointteri ja samaa rakennetta käytetään useassa säikeessä kun kääntäjä varmistaa, että siinä koodissa ei ole yhtään sivuvaikutuksia mikä estää tämän.

GCC tuskin tuotti optimaalista 68k koodia missään kohtaan. Tuskin sitä kehitettiin enää ihmeemmin kun 68k prossut väistyi silloin 90-luvulla. Assemblerilla sai Intelille hinkattua Pentium II vehkeillä mutta sen jälkeen meni kääntäjäteknologia kuin myös prosessorien sisäinen käskydekooderi ja suoritusjärjestyksen optimointi sellaiseksi, että menetti merkityksen. C:llä sai oikeastaan aina yhtä hyvää. Ehkä just joku silmukka jossain missä otettiin SIMD huomioon ja bruteforcella kävi että sai sieltä sisimmästä silmukasta viimeisimmät kellojaksot pois mutta se oli sitten siinä. 90-luvun lopulla assembler oli jo hyvin merkityksetön.

Käytännön ohjelmoinnissa kompleksisuuden hallinta on aika keskeistä, myös suorituskykyä optimoidessa.

Noin esimerkiksi, C:llä saa oikein hyvin tehtyä optimoituja ja kapseloituja komponentteja mutta nimiavaruus rajoittaa scopettamista. Se onkin suunniteltu niukemmille muistimäärille ja että tehdään komponentteja joita joissa datavirtoja putkitetaan: https://en.wikipedia.org/wiki/Pipeline_(Unix)

Ja tietysti kun jokainen komponentti on omassa prosessissa ja kommunikoi käyttöjärjestelmän putkien kanssa niin siitä tulee myös hävikkiä vaikka tuossa käyttöjärjestelmä rinnakkaistaa. Joku service mikä käynnistää aina palikan tekee latenssia.

Muistinkulutus pysyy pienenä toki mutta tässä on abstraktiohävikkiä, että voi olla kiinnostuksia ajaa kokonaisuutta enemmän samassa prosessissa. Sitä varten sitten on vaikka oliokieliä kuten vaikka C missä suurempi nimiavaruus, että voi saman prosessin sisälle rakentaa niitä kapseloituja komponentteja.

Kieli on kompleksisempi mutta tuo itseasiassa helposti suuremman suorituskyvyn kapseloiduilla komponenteilla kun jää se abstraktiohävikki pois kun ajetaan samassa prosessissa niitä komponentteja. Ja uudemmat kääntäjät sitten osaa tehdä isomman mittakaavan optimointia kun käyvät kaikkien komponenttien koodimassaa läpi mitä siihen käännökseen tulee. Sattumalta uudemmat kääntäjät alkoikin sitten rohmuta muistia paljon enemmän siinä käännöksessä mutta tuo tulee siitä, kun pyrkivät käsittelemään koko koodimassaa muistissa yhtenä käännettävänä kokonaisuutena, eikä niin että käännetään vaikka sed:istä yksi palikka ja cat:ista toinen.

Lue lisää

Toki se oliorakenne tuo myös oman abstraktiohävikkinsä mutta uuden prosessin käynnistäminen vie helposti enemmän aikaa kuin alustaa uusi luokka samassa prosessissa.

"ARM:lla on heikko suorituskyky verrattuna esim. Intelin/AMD-suorittimiin. Sen etuna on halpuus ja energiatehokkuus, mutta se ei kelpaa esim. pöytätietokoneisiin. "

Ei päde: https://www.howtogeek.com/393139/mobile-cpus-are-now-as-fast-as-your-desktop-pc/

"Siirrettävyydellä ei ole juuri merkitystä kun tekee ohjelmia Amigalle, koska monet nykyiset rajapinnat ja kirjastot ovat kuitenkin liian hitaita että ne toimisivat Amigalla (mukaanlukien esim. SDL)."

Asian juttu se että miksi se pitää saada toimimaan Amigalla kun koodi toimii siirrettävästi, suorituskykyisemmin, pienemmillä wateilla, paremmilla ominaisuuksilla ja halvemmalla Raspberry Pi 4:llä?

Tuo on kuitenkin Amigaan verrattuna supertietokone.

M-Kar kirjoitti:

Toki se oliorakenne tuo myös oman abstraktiohävikkinsä mutta uuden prosessin käynnistäminen vie helposti enemmän aikaa kuin alustaa uusi luokka samassa prosessissa.

"ARM:lla on heikko suorituskyky verrattuna esim. Intelin/AMD-suorittimiin. Sen etuna on halpuus ja energiatehokkuus, mutta se ei kelpaa esim. pöytätietokoneisiin. "

Ei päde: https://www.howtogeek.com/393139/mobile-cpus-are-now-as-fast-as-your-desktop-pc/

"Siirrettävyydellä ei ole juuri merkitystä kun tekee ohjelmia Amigalle, koska monet nykyiset rajapinnat ja kirjastot ovat kuitenkin liian hitaita että ne toimisivat Amigalla (mukaanlukien esim. SDL)."

Asian juttu se että miksi se pitää saada toimimaan Amigalla kun koodi toimii siirrettävästi, suorituskykyisemmin, pienemmillä wateilla, paremmilla ominaisuuksilla ja halvemmalla Raspberry Pi 4:llä?

Tuo on kuitenkin Amigaan verrattuna supertietokone.

Lue lisää

Taitaa aika monella nykyisellä Amigan käyttäjällä olla jonkinlaista fanaattisuutta, kun pitävät kiinni vanhasta systeemistä, vaikka se onkin teholtaan aika vaatimaton ja siitä puuttuu monia nykyajan mukavuuksia (esmes kunnon rullahiirituki).

Itsekin kyllä mielelläni verestäisin vanhoja muistoja, mutta meikän Amiga hajosi aikoja sitten. Se oli kyllä yleiseen tasoon verrattuna melko kova mylly (060/50, 16 megaa muistia, Voodoo 3 1600x1200/16 bit), mutta ei tietenkään vedä vertoja tuolle Vampirelle tai edes PPC-Amigoille. Tosin AmigaOS 4:n etuna olisi, että sille ilmeisesti saisi jopa Qt Creatorin...

M-Kar kirjoitti:

Toki se oliorakenne tuo myös oman abstraktiohävikkinsä mutta uuden prosessin käynnistäminen vie helposti enemmän aikaa kuin alustaa uusi luokka samassa prosessissa.

"ARM:lla on heikko suorituskyky verrattuna esim. Intelin/AMD-suorittimiin. Sen etuna on halpuus ja energiatehokkuus, mutta se ei kelpaa esim. pöytätietokoneisiin. "

Ei päde: https://www.howtogeek.com/393139/mobile-cpus-are-now-as-fast-as-your-desktop-pc/

"Siirrettävyydellä ei ole juuri merkitystä kun tekee ohjelmia Amigalle, koska monet nykyiset rajapinnat ja kirjastot ovat kuitenkin liian hitaita että ne toimisivat Amigalla (mukaanlukien esim. SDL)."

Asian juttu se että miksi se pitää saada toimimaan Amigalla kun koodi toimii siirrettävästi, suorituskykyisemmin, pienemmillä wateilla, paremmilla ominaisuuksilla ja halvemmalla Raspberry Pi 4:llä?

Tuo on kuitenkin Amigaan verrattuna supertietokone.

Lue lisää

Hienoa teoriaa, mutta pysytään aiheessa: m68k:lle ei ole mitään hyvää C-kääntäjää, joka tuottaisi hyvää koodia. Ei tietystikään myöskään 68080:lle ja AMMX:lle. Tässä kyllä yritettiin tehdä jotakin backendiä gcc:lle, mutta homma osoittautui liian monimutkaiseksi.

Ja tuskin koodingenerointi toimii optimaalisesti monille muillekaan alustoille. En ole kokeillut ARM/x64-alustoja, mutta epäilen että tässäkään ei optimaalisuus toteudu kaikissa skenaarioissa. Ongelmana ei näissä järjestelmissä muutenkaan ole koodin laatu, vaan yleinen bloatti, liikaa softakerroksia ja muuta roinaa välissä.

Hyvä asia vaan että ARM on saamassa prosessoreitaan paremmiksi kuin Intel, vielä muutama vuosi sitten ARM oli selvästi hitaampi kuin Intelin prosessorit. Intelin prosessorit ovatkin sisäisesti rumia, hyvä että kostautuu jossakin vaiheessa.

M68k-prosessorit olivat aina parempia kuin Intelin vastaavat. Toivottavasti nekin löydetään uudelleen, uudemmilla valmistustekniikoilla saisi esim. 68060:n kellotaajuuden nostettua ihan uusille lukemille. M68k:t ovat ARM:n tapaan myös energiatehokkaita, mutta niissä on myös paras kooditiheys (code density) kaikista tavallisista prosessoreista, mikä myös parantaa suorituskykyä.

m36-intj kirjoitti:

Hienoa teoriaa, mutta pysytään aiheessa: m68k:lle ei ole mitään hyvää C-kääntäjää, joka tuottaisi hyvää koodia. Ei tietystikään myöskään 68080:lle ja AMMX:lle. Tässä kyllä yritettiin tehdä jotakin backendiä gcc:lle, mutta homma osoittautui liian monimutkaiseksi.

Ja tuskin koodingenerointi toimii optimaalisesti monille muillekaan alustoille. En ole kokeillut ARM/x64-alustoja, mutta epäilen että tässäkään ei optimaalisuus toteudu kaikissa skenaarioissa. Ongelmana ei näissä järjestelmissä muutenkaan ole koodin laatu, vaan yleinen bloatti, liikaa softakerroksia ja muuta roinaa välissä.

Hyvä asia vaan että ARM on saamassa prosessoreitaan paremmiksi kuin Intel, vielä muutama vuosi sitten ARM oli selvästi hitaampi kuin Intelin prosessorit. Intelin prosessorit ovatkin sisäisesti rumia, hyvä että kostautuu jossakin vaiheessa.

M68k-prosessorit olivat aina parempia kuin Intelin vastaavat. Toivottavasti nekin löydetään uudelleen, uudemmilla valmistustekniikoilla saisi esim. 68060:n kellotaajuuden nostettua ihan uusille lukemille. M68k:t ovat ARM:n tapaan myös energiatehokkaita, mutta niissä on myös paras kooditiheys (code density) kaikista tavallisista prosessoreista, mikä myös parantaa suorituskykyä.

Lue lisää

"Hienoa teoriaa, mutta pysytään aiheessa: m68k:lle ei ole mitään hyvää C-kääntäjää, joka tuottaisi hyvää koodia."

Nykypäivänä on helpompaa tehdä oma kääntäjä joka optimoi kuin kirjoitella assembleria. Tekee vaikka oman backendin LLVM:lle. Saa just niin hyvän kuin itse osaa optimoida.

"Ongelmana ei näissä järjestelmissä muutenkaan ole koodin laatu, vaan yleinen bloatti, liikaa softakerroksia ja muuta roinaa välissä."

Nyt en ihan käsitä... Ihan ohjelmoijasta se on kiinni mitä kerroksia sinne haluaa.

Backendissä käytännössä I/O kerros siellä se, että ne vie aikaa kun vaikka tehdään tiedosto, luetaan tai kirjoitetaan. Kaikki muu koodi sitten voidaan ajaa ilman mitään roinaa.

Frontendissä sitten on ohut kerros missä webassembly käännetään prosessorin natiiviksi JIT:llä mutta se vaikuttaa vain moduulin käynnistykseen. Shaderit käännetään sitten suoraan GPU:lle niin, että siellä ei ole mitään välissä.

" M68k:t ovat ARM:n tapaan myös energiatehokkaita, mutta niissä on myös paras kooditiheys (code density) kaikista tavallisista prosessoreista, mikä myös parantaa suorituskykyä."

Koodin tiheys lähinnä auttaa siinä, että välimuistiin sopii enemmän. Kasvattamalla välimuistin kokoa, tuo etu menee.

Käskyjen dekoodaaminen RISC käskyiksi tosin vaatii piiriltä tilaa ja voi vaatia osia mitä ajetaan tupla tai tripla kelloilla, ja sitten tulee ongelmia nostaa normikellotaajuutta kun siellä sellaisia kuumana käyviä pisteitä siellä sirulla.

Nuo prosessorien tavukoodit mitä nyt on käytössä, ovat kaikki vanhoja. Ei ole mitenkään mahdotonta rakentaa uutta tavukoodia mitä tehty sen mukaan mitä nykyisin tiedetään pullonkauloista piirisuunnittelussa.

Ohjelmoijalle sillä ei ole väliä. Kaikki koodi kirjoitetaan kuitenkin mahdollisimman korkealla tasolla ja käännetään alustan ymmärtämään muotoon, että sillä ei ole väliä vaikka prosessorin tai runtimen tavukoodin muoto vaihtuu.

Lopputulos siis se, että hinta, watit ja suorituskyky ratkaisee ja lähtökohta on se, että toimii oikein. Jos on buginen tai ei toimi niin se on sitten paska.

Ja täytyy mainita että itse en ole vielä hankkinut ensimmäistäkään Vampire-korttia, koska pidän koko projektia vielä keskeneräisenä.

Ja en kyllä hankkisi tuota A500/A600-malleille. Siinä nyt on ongelmia mm. virtalähteen kanssa, pitää ehkä hankkia isompi, alkuperäinen virtalähde ei välttämättä käy. Ja sitten pitää ehkä jotain kondensaattoreita vaihtaa/poistaa emolevyltä. Lisäksi ei välttämättä kovin stabiili tuo kortti, kun pitää kytkeä kiinni ruuveilla alkuperäisen prosessorin päälle. A1200:ssa on sentään laajennusportti, johon kortti vaan laitetaan kiinni. Noissa V2-malleissa lisäksi osittainen softFPU ja ei AGA-tukea. SAGA on vielä keskeneräinen ja ei kelpaa minulle lainkaan. Blitter myös softapohjaisesti emuloitu CPU:lla. Siinä lähtee mukavasti tehot, kun ei ole oikeaa blitteripiiriä rakennettu FPGA:lla, ja tämä ei vastaa lainkaan alkuperäistä Amiga-arkkitehtuuria jossa blitteri pystyi toimimaan rinnakkain prosessorin kanssa.

On jäänyt kyllä huono maku suuhun koko apollocore FPGA-projektista. V4 ei ole vieläkään valmis, ei taida olla tiimillä resursseja saada valmiiksi asioita. Olisivat tyytyneet vain 68080-FPGA prosessoriin, jonka sitten saisi laajennuskorttina muistilla varustettuna.

Perkele siis Amigan VASEMMAN kyljen laajennusporttiin!!

Minulle Amiga tarkoitti minimissään 3megan muistia ja kovalevyä vuodesta 1989 eteenpäin.
Harmi että kesti vuoteen 1994/95 ennen kuin oli rahaa siirtyä Amigassa nopeanpaan prosessoriin. Suomen hinnat oli hirveitä.


Nyt haaveena että jonkin ajan kuluttua olisi:
-Amiga4000 huollettuna autenttiseen OCS ECS AGA retroiluun
-Amiga2000 rakennettuna 1989 aikaiseen "loistoon"
-Amiga600 rakennettuna low-end demoilu ja multimediakioski -koneeksi
-Vampire Amiga500:n kopassa ... ?

Hyötysoftat varmaan ajelen enimmäkseen NG koneissa.

-Amigisti