sasm hyvä työkalu linux asm-editoriksi!

Kokeilitko myös avata esimerkkiprojekteja /usr/share/sasm/Projects:n alta? Sieltä vaikkapa NASMhello.asm tai x64-versio jos 64-bittinen kone? Ei tarvitse kuin painaa play-nappulaa ja ohjelma kääntyy ja oikeasta laidasta löytyy lopputulos! Seuraavaksi haluat varmaankin ladata manuaalit nasm:lle ja tuo nyt kannattaa myös vilkaista:
https://dman95.github.io/SASM/english.html
Ei ole ihan joka iikan työkalu - toisaalta niille jotka tartvitsee vaikka optimointia tehdä varmasti vaivan arvoista opeteltavaa. Ja tarkoitan tässä nyt vaikka gcc-kääntäjän optimointia. Etuhan on se ettei tarvitse välttämättä käyttää gas-assembleria, jonka syntaksi on syvältä.

Anonyymi kirjoitti:

Kokeilitko myös avata esimerkkiprojekteja /usr/share/sasm/Projects:n alta? Sieltä vaikkapa NASMhello.asm tai x64-versio jos 64-bittinen kone? Ei tarvitse kuin painaa play-nappulaa ja ohjelma kääntyy ja oikeasta laidasta löytyy lopputulos! Seuraavaksi haluat varmaankin ladata manuaalit nasm:lle ja tuo nyt kannattaa myös vilkaista:
https://dman95.github.io/SASM/english.html
Ei ole ihan joka iikan työkalu - toisaalta niille jotka tartvitsee vaikka optimointia tehdä varmasti vaivan arvoista opeteltavaa. Ja tarkoitan tässä nyt vaikka gcc-kääntäjän optimointia. Etuhan on se ettei tarvitse välttämättä käyttää gas-assembleria, jonka syntaksi on syvältä.

Lue lisää

Siitäkö ei itsenäisesti ajettavaa tiedostoa saa. Vähän iloa jos pitää editorin omassa pääte-emulaattorissa ajella.

Anonyymi kirjoitti:

Siitäkö ei itsenäisesti ajettavaa tiedostoa saa. Vähän iloa jos pitää editorin omassa pääte-emulaattorissa ajella.

Annapas kun vähän selittelen miksi tämä kiinnostaa juuri nyt.

Eilen vielä kovasti haluttiin Python mollata hitaammaksi kuin C. Sehän ei tietenkään kokonaisuudessaan pidä paikkaansa. Ai, miksikö?

Siksi että kun puhutaan perus Pyhonista sillä tarkoitetaan PythonC kielisiä sovelluksia, ja taas tämä PythonC on tuotettu C ja C koodilla.

Sitten se supernopea Python, jolla tarkoitetaan PyPy tulkkia, joka tuottaa koodin JIT-kääntäjän tekemänä muistivaraisesti ja on yhtä alkukantaista kuin tämä NASM editorinkin käsittelemä.

Olisin halunnut tehdä tuollaisen While silmukan ja verrata PyPy tulkin ja ASM koodin keskinäistä nopeutta. Enempää en häneen aio aikaani tuhlata, koska se on vääjäämättä historiaa.

Silloin ennen vanhaan assemblerit tuotti COM tiedostoja joiden maksimikoko oli 64kt, ja nämä olivatkin sitten erittäin nopeita. mutta nopeus putosi kun haluttiin mennä yli tuon 64kt jolloin ohjelmista tuli EXE päätteisiä. Sekin kiinnostaa että mikä se on tämän päivän tilanne, ja nimenomaan Linux ympäristössä.

Anonyymi kirjoitti:

Kokeilitko myös avata esimerkkiprojekteja /usr/share/sasm/Projects:n alta? Sieltä vaikkapa NASMhello.asm tai x64-versio jos 64-bittinen kone? Ei tarvitse kuin painaa play-nappulaa ja ohjelma kääntyy ja oikeasta laidasta löytyy lopputulos! Seuraavaksi haluat varmaankin ladata manuaalit nasm:lle ja tuo nyt kannattaa myös vilkaista:
https://dman95.github.io/SASM/english.html
Ei ole ihan joka iikan työkalu - toisaalta niille jotka tartvitsee vaikka optimointia tehdä varmasti vaivan arvoista opeteltavaa. Ja tarkoitan tässä nyt vaikka gcc-kääntäjän optimointia. Etuhan on se ettei tarvitse välttämättä käyttää gas-assembleria, jonka syntaksi on syvältä.

Lue lisää

Nykyään optimoidaan niin, että lasketaan GPU:lla kun pitää laskea paljon. Saa laskentatehoa kivasti lisättyä käyttämällä GPU:a missä enemmän laskentaytimiä tai lisäämällä GPU:jen määrää.

En ihan heti keksi mihin optimointiin sasm kävisi.

Anonyymi kirjoitti:

Nykyään optimoidaan niin, että lasketaan GPU:lla kun pitää laskea paljon. Saa laskentatehoa kivasti lisättyä käyttämällä GPU:a missä enemmän laskentaytimiä tai lisäämällä GPU:jen määrää.

En ihan heti keksi mihin optimointiin sasm kävisi.

Lue lisää

Ajatteles nyt neljä miljardia kierrosta, pyörähtää 0,001 sekunnissa. Kyllä sillä jotain varmaan pystyy nopeuttamaan. En tosin ole varma, menikä tuo oikein, mutta jostakin luvin että ebx olisi 32 biitinen rekisteri. While silmukan vastinetta sillä tavoittelin, onko se sitä en osaa sanoa.

https://s7.gifyu.com/images/speed-asm.png

Anonyymi kirjoitti:

Ajatteles nyt neljä miljardia kierrosta, pyörähtää 0,001 sekunnissa. Kyllä sillä jotain varmaan pystyy nopeuttamaan. En tosin ole varma, menikä tuo oikein, mutta jostakin luvin että ebx olisi 32 biitinen rekisteri. While silmukan vastinetta sillä tavoittelin, onko se sitä en osaa sanoa.

https://s7.gifyu.com/images/speed-asm.png

Lue lisää

Häirikkö polki parissa minuutissa tämän ketjun seuraavalle sivulle. Vaikuttaa ärsyyntyvän jos joku asiaa kirjoittelee väliin.

Anonyymi kirjoitti:

Ajatteles nyt neljä miljardia kierrosta, pyörähtää 0,001 sekunnissa. Kyllä sillä jotain varmaan pystyy nopeuttamaan. En tosin ole varma, menikä tuo oikein, mutta jostakin luvin että ebx olisi 32 biitinen rekisteri. While silmukan vastinetta sillä tavoittelin, onko se sitä en osaa sanoa.

https://s7.gifyu.com/images/speed-asm.png

Lue lisää

Oikeissa ohjelmissa ei pyöritetä silmukassa numeroa vaan on jotain dataa mitä käsitellään. Ohjelma joka nimenomaisesti laskee paljon ottaa sitä dataa sisään, laskee, ja tulostaa lopputuloksen. Lopputulos voi olla data jota on käsitelty.

Sitten sitä laskentaa nopeutetaan niin, että se datamöhkäle laitetaan pieniksi paloiksi joita lasketaan rinnakkain kun siellä GPU:ssa on niitä pieniä laskentaytimiä.

Sama temppu toimii tietysti CPU-laskennassa ja palaset jaetaan CPU-ytimille. Sitäkin käytetään jos dataa on hyvin vähän, koska GPU:lle siirto vie aikaa ja tuo latenssia.

Latenssia tekee myös se säikeiden (tai prosessien) käynnistäminen, että aina ei kannata ajaa useammassa säikeissä, tai prosessissa.

Ohjelmointikielellä on myös merkitystä. Esimerkiksi C:llä on tuo nimiavaruusongelma, että ohjelman palastelu moduuleihin tapahtuu ensisijaisesti jakamalla useammalla prosessiin (latenssia).

Ja ajettaessa laskentaa rinnakkain on joutuu olemaan hyvin tarkka siitä, että koodissa ei ole niin sanottuja sivuvaikutuksia: https://en.wikipedia.org/wiki/Side_effect_(computer_science)

Sivuvaikutukset rinnakkaisessa laskennassa nimittäin johtaa helposti bugeihin mitä on hyvin vaikea jäljittää.

Laskennan palastelua sitten tehdään myös niin, että samaa asiaa laskee useampi tietokone samanaikaisesti kun on vaikka paljon dataa.

Anonyymi kirjoitti:

Oikeissa ohjelmissa ei pyöritetä silmukassa numeroa vaan on jotain dataa mitä käsitellään. Ohjelma joka nimenomaisesti laskee paljon ottaa sitä dataa sisään, laskee, ja tulostaa lopputuloksen. Lopputulos voi olla data jota on käsitelty.

Sitten sitä laskentaa nopeutetaan niin, että se datamöhkäle laitetaan pieniksi paloiksi joita lasketaan rinnakkain kun siellä GPU:ssa on niitä pieniä laskentaytimiä.

Sama temppu toimii tietysti CPU-laskennassa ja palaset jaetaan CPU-ytimille. Sitäkin käytetään jos dataa on hyvin vähän, koska GPU:lle siirto vie aikaa ja tuo latenssia.

Latenssia tekee myös se säikeiden (tai prosessien) käynnistäminen, että aina ei kannata ajaa useammassa säikeissä, tai prosessissa.

Ohjelmointikielellä on myös merkitystä. Esimerkiksi C:llä on tuo nimiavaruusongelma, että ohjelman palastelu moduuleihin tapahtuu ensisijaisesti jakamalla useammalla prosessiin (latenssia).

Ja ajettaessa laskentaa rinnakkain on joutuu olemaan hyvin tarkka siitä, että koodissa ei ole niin sanottuja sivuvaikutuksia: https://en.wikipedia.org/wiki/Side_effect_(computer_science)

Sivuvaikutukset rinnakkaisessa laskennassa nimittäin johtaa helposti bugeihin mitä on hyvin vaikea jäljittää.

Laskennan palastelua sitten tehdään myös niin, että samaa asiaa laskee useampi tietokone samanaikaisesti kun on vaikka paljon dataa.

Lue lisää

Epäilemättä, joo.

Mutta pysytäänpä vielä hetki, ihan käytännön tasolla. Tuo sama neljä miljardia kierrosta tekevä While silmukka C kielellä käännettynä ilman minkäänlaista optimointia vie suoritus aikaa:

Normaali kääntäminen
gcc speed.c -o speed
real 0m6,708s
user 0m6,703s
sys 0m0,000s

Kun tuo sama koodi käännetään käyttäen optimointi valitsinta, suoritus nopeus kasvaa huimasti:

Optimointi mukana käännettäessä:
gcc -O speed.c -o speed
real 0m1,093s
user 0m1,092s
sys 0m0,000s

Anonyymi kirjoitti:

Epäilemättä, joo.

Mutta pysytäänpä vielä hetki, ihan käytännön tasolla. Tuo sama neljä miljardia kierrosta tekevä While silmukka C kielellä käännettynä ilman minkäänlaista optimointia vie suoritus aikaa:

Normaali kääntäminen
gcc speed.c -o speed
real 0m6,708s
user 0m6,703s
sys 0m0,000s

Kun tuo sama koodi käännetään käyttäen optimointi valitsinta, suoritus nopeus kasvaa huimasti:

Optimointi mukana käännettäessä:
gcc -O speed.c -o speed
real 0m1,093s
user 0m1,092s
sys 0m0,000s

Lue lisää

Saattaa tulla lisää vauhtia laittamalla vaikka -O3

Enemmän kyllä kiinnostaa nopeus kun suoritetaan jotain käytännöllisempää.

Anonyymi kirjoitti:

Saattaa tulla lisää vauhtia laittamalla vaikka -O3

Enemmän kyllä kiinnostaa nopeus kun suoritetaan jotain käytännöllisempää.

Näin on -O3 vie samoihin kuin tuo speed.asm koodin aika oli, eli

gcc -O3 speed.c -o speed
real 0m0,001s
user 0m0,001s
sys 0m0,000s

Anonyymi kirjoitti:

Näin on -O3 vie samoihin kuin tuo speed.asm koodin aika oli, eli

gcc -O3 speed.c -o speed
real 0m0,001s
user 0m0,001s
sys 0m0,000s

Eli speed.asm ei tuossa auttanut optimoimaan mitään.

Anonyymi kirjoitti:

Näin on -O3 vie samoihin kuin tuo speed.asm koodin aika oli, eli

gcc -O3 speed.c -o speed
real 0m0,001s
user 0m0,001s
sys 0m0,000s

Laitetaanpas tähän vielä tuo C kielinen koodi jota tässä on käsitelty, vaikka se löytyy tuolta aiemin jo julkaisemastani viestistäkin, on vain polettu niin kauaksi etsittäviin, toivottavasti ei nyt ropo poista tätä:

#include <stdio.h>

int main(void) {

unsigned long i = 0;
while ( i < 4000000000) { i = 1; };

return(0);

}

Anonyymi kirjoitti:

Eli speed.asm ei tuossa auttanut optimoimaan mitään.

Siltähän tuo näyttää, mutta toimiiko tuo optimointi, kun mennään rakentelemaan isompia juttuja, tosin ASM on pirun hankala ympäristö sellaiseen. Joko me hyllytetään koko ASM, taitaa olla historiaa. Kohta kuullaan NASM fanin mielipiteet tästä.

Anonyymi kirjoitti:

Siltähän tuo näyttää, mutta toimiiko tuo optimointi, kun mennään rakentelemaan isompia juttuja, tosin ASM on pirun hankala ympäristö sellaiseen. Joko me hyllytetään koko ASM, taitaa olla historiaa. Kohta kuullaan NASM fanin mielipiteet tästä.

Lue lisää

Kääntäjät kun optimoi niin ne voivat analysoida koko lähdekoodin läpi ja hakea koko laajuudelta sitä parasta tapaa.

Formaalin kielen kääntäminen osataan todella hyvin, että koneellisesti tehtyt optimoinnit on helposti parempia kuin mitä käsin nysväämällä saa.

Se mikä haittaa eniten suorituskykyä on käytännössä sellainen koodi mikä näyttää ripulipaskalta. Selkeästä koodista ihminen voi helpommin valita tehokkaimman algoritmin ja kääntäjä osaa myös optimoida sitä hyvin. Yksi tapa parantaa suorituskykyä voikin helposti olla se ohjelmointikielen vaihto mikä pakottaa ohjelmoimaan siistimmin.

Esimerkiksi Haskellilla saa usein helposti tehokkaampaa koodia kuin vaikka C:llä kun ohjelmointikieli pakottaa ohjelman toimimaan niin, että ohjelman tila ei muutu miten sattuu niin mahdollistaa mielenkiintoisia optimointeja missä kääntäjä vain vaihtaa pointteria kun voi olla varma missä tilassa rakenteet on. Säikeistyskin on erittäin helppoa tässä kun ohjelmointikielen keskeinen idea on estää sivuvaikutukset.

Vastaavasti joku Java tai C# voi myös toimia tehokkaammin kuin C kun muistia ei tarvitse vapauttaa vaan ajoympäristö hoitaa sen automaattisesti silloin kun aikaa, ajamalla roskienkerääjää.

Itsellä ei tule nyt mieleen missä ASM:ssa olisi hyötyä kun koodissa on niin paljon optimoitavaa ilman assembleriakin.

Jos jossain sisäsilmukassa voisi saada käsin hinkkaamalla vauhtia kääntäjään nähden, silloinkin varmaan kannattaisi kirjoittaa softa mikä hakee nopeimman sen nopeimman käsky-yhdistelmän jollain hakualgoritmilla.