Moniajo

[Tuomas Yrjövuori]

Kukas se väittikään, että Commodore 64 ei pysty moniajoon?

<http://picoos.sourceforge.net/ports/6502/index.html>

Toki on niin, että 6502 on lähtökohtaisesti huono prosessori moniajoon
muiden muassa kontekstin vaihtokäskyn puutteen ja kökön nollasivun
toiminnan vuoksi.

--
Tuomas Yrjövuori

[Naked Fame]

Tuomas Yrjövuori <tuomas.y...@aalto.fi> writes:
> Kukas se väittikään, että Commodore 64 ei pysty moniajoon?

Ei kai kukaan.

6502/6510 FTW!

--
Signature

[Reijo Korhonen]

On Fri, 07 Jul 2017 12:21:46 +0300, Tuomas Yrjövuori wrote:

> Kukas se väittikään, että Commodore 64 ei pysty moniajoon?

En tiedä, mutta selitäpä mitä on moniajo. Harva vanhempi laite siihen
pystyy. Moniajo pitäisi olla jotain sellaista, että moni prosessi toimii
yhtä aikaa. Mutta useimmiten vanhoilla laitteilla se ei pidä paikkaansa.
Ainakaan niissi laitteissa joissa on vain yksi prosessori. Uusissakin
laitteissa joissa ytimiä on useita, niin kellolla mitaten tilanne jossa
useita prosesseja on yhtä aikaa toiminnassa on harvinaisempi kuin se,
että nolla tai yksi prosessi toimii. Kotikoneissa varsinkin.

Moniajoa mietitään usein prosessin kannalta. Prosessien pitäisi toimia
yhtä aikaa, jos kyse olisi aidosta moniajosta. Mutta kun prosessit
tarvitsevat pääosin prosessorin prosessointikykyä, niin moniajo
useimmiten ei voi millään olla toiminnassa, sillä vain yksi prosessi on
prosessorilla ja muut jonottavat sinne.

Moniajolla nimitetään siis virheellisesti useimmiten sitä, että laite tai
laite+käyttö/ajoympristä yms. kykenee laittamaan prosessit jonoon
odottamaan ja odotustilassa ne eivät pysty tekemään mitään eli ovat
aivokuolleita eli koomassa. Tämä on paljon hanlalampi tilanne kuin
esimerkiksi mies kaupan kassan jonossa. Siinä jonossa voi olla
mielenkiintoisen näköisiä ihmisiä tai kaupan kassojenkin tarkkailu voi
olla arvokasta katsojan mielestä. Tosielämän jonottaminen on siis paljon
parempi tilanne kuin prosessin jonottaminen "moniajoon" pystyvässä
ympäristössä.

"Moniajojoa" parempi termi voisi olla "vuoroeteneminen", muut on jonossa,
mutta kutakin palvellaan vuorollaan, palvelussa on vain yksi kerrallaan
ja muut koomasssa, ja askel kerrallaan edetään kohti palvelua. Koomassa
aina välillä käyvä prosessi ei tietenkään huomaa koomassa oloa, joten se
luulee koko ajan toimivansa. Kätevää. Tilanne näyttää prosessin luulemana
paljon paremmalta kuin se oikeasti onkaan.

>
> <http://picoos.sourceforge.net/ports/6502/index.html>

Tuo sivu kertoo että prosessorilla voidaan tehdä kontekstin vaihto eli
vaihtamaan prosessin rekisteriedot jollakin vippaskontilla? Tai jollakin
konstilla niin että voidaan siirtyä toisen prosessin palvelemiseen?
Elikkä siis palvelemmaan vuorotellen. Tuo on kyllä jotain muuta kuin
moniajoa. Moniajo on jotain sellaista, että niitä palvelupisteitä on
useita ja niissä palvellaan samalla ajan hetkellä useita prosesseja yhtä
aikaa.

Vertaapa pientä apteekkia jossa on vain yksi reseptiasiakkaita palveleva
luukku. Sinne voi tulla tietenkin yhtä monta asiakasta kuin isompaankin
apteekkiin jossa on kymmenen luukkua. Isossa ja pienessä apteekissa
voidaan paavella yhtä montaa asiakasta, mutta isommassa se vaan käy
nopeammin. Iso apteekki, jossa on kymmenen palveluluukkua palvelee
kymmentä asiakasta oikeasti yhtä aikaa - ainakin ajoittain kun
asiakaspalvelijat eivät hommaa muuta - eli pystyy moniajoon. Pieni
apteekki pystyy vain vuoroajoon. Molemmissa kuitenkin hoituvat samat
asiat.

> Toki on niin, että 6502 on lähtökohtaisesti huono prosessori moniajoon
> muiden muassa kontekstin vaihtokäskyn puutteen ja kökön nollasivun
> toiminnan vuoksi.

Jos yksi työkalu puuttuu, niin saman asian voi tehdä toisella. Joskus
vähän työläämmin. Jos ei ole rakennustöissä metallilapiota, niin lasten
muovisella leikkilapiollakin voi kaivaa. Silläkin saa aikaiseksi aika
ison kuopan, kunhan käyttää aikaa ja kärsivällisyyttä. Ja vaihtaa
leikkilapion aina uuteen tarvittaessa. Eri asia onko hommassa mitään
järkeä.


--
Re...@iki.fi.nospam.invalid
http://www.iki.fi/Reijo

[Tuomas Yrjövuori]

Reijo Korhonen kirjoitti 08.07.2017 klo 12:14:
> En tiedä, mutta selitäpä mitä on moniajo. Harva vanhempi laite siihen
> pystyy. Moniajo pitäisi olla jotain sellaista, että moni prosessi toimii
> yhtä aikaa. Mutta useimmiten vanhoilla laitteilla se ei pidä paikkaansa.

Moniajo on ensisijaisesti softan ja toissijaisesti raudan ominaisuus.

>> <http://picoos.sourceforge.net/ports/6502/index.html>
>
> Tuo sivu kertoo että prosessorilla voidaan tehdä kontekstin vaihto eli
> vaihtamaan prosessin rekisteriedot jollakin vippaskontilla? Tai jollakin
> konstilla niin että voidaan siirtyä toisen prosessin palvelemiseen?
> Elikkä siis palvelemmaan vuorotellen. Tuo on kyllä jotain muuta kuin
> moniajoa. Moniajo on jotain sellaista, että niitä palvelupisteitä on
> useita ja niissä palvellaan samalla ajan hetkellä useita prosesseja yhtä
> aikaa.

Jos samassa huoneessa on monta eri tietokonetta, nekin voivat tehdä
samanaikaisesti eri asioita. Ongelmia tulee siinä vaiheessa, kun eri
tietokoneet yrittävät käyttää samaa yksittäistä resurssia.

Jos siinä kaupan kassajonolla on yhdestä palvelupisteestä tietyn
merkkinen tupakka loppu, kassaneiti pyytää tätä tiettyä tupakkaa
viereiseltä kassalta, ja kolmannella kassalla puolestaan on banaanipussi
on jäänyt punnitsematta ja tarroittamatta, härdelli on valmis. Silloin
kaikki kolme kassaa ovat hetkellisesti tilanteessa, jossa ne eivät pysty
kunnolla palvelemaan ainuttakaan asiakasta.

> Vertaapa pientä apteekkia jossa on vain yksi reseptiasiakkaita palveleva
> luukku. Sinne voi tulla tietenkin yhtä monta asiakasta kuin isompaankin
> apteekkiin jossa on kymmenen luukkua. Isossa ja pienessä apteekissa
> voidaan paavella yhtä montaa asiakasta, mutta isommassa se vaan käy
> nopeammin.

Toki. Mutta jos tilanne sattuu olemaan se, että niitä luukkuja on vain
se yksi. Silloin sen yhden luukun täytyy toimia mahdollisimman
tehokkaasti. Jono on jono yhdelläkin luukulla. Asiakkaat ovat jatkuvassa
palvelusuhteessa apteekkiin. Yhden kassan apteekistakin asiakkaat voivat
käydä hakemassa palvelua aina uudelleen ja uudelleen, sen oman pienen
aikaikkunansa puitteissa.

> Iso apteekki, jossa on kymmenen palveluluukkua palvelee
> kymmentä asiakasta oikeasti yhtä aikaa - ainakin ajoittain kun
> asiakaspalvelijat eivät hommaa muuta - eli pystyy moniajoon. Pieni
> apteekki pystyy vain vuoroajoon. Molemmissa kuitenkin hoituvat samat
> asiat.

Onko moniajon yleinen määritelmä todellakin tuollainen?

--
Tuomas Yrjövuori

[Reijo Korhonen]

On Sat, 08 Jul 2017 21:40:38 +0300, Tuomas Yrjövuori wrote:

> Reijo Korhonen kirjoitti 08.07.2017 klo 12:14:
>> En tiedä, mutta selitäpä mitä on moniajo. Harva vanhempi laite siihen
>> pystyy. Moniajo pitäisi olla jotain sellaista, että moni prosessi
>> toimii yhtä aikaa. Mutta useimmiten vanhoilla laitteilla se ei pidä
>> paikkaansa.
>
> Moniajo on ensisijaisesti softan ja toissijaisesti raudan ominaisuus.
>
>>> <http://picoos.sourceforge.net/ports/6502/index.html>

Mutkun sinun linkkisikin puhui termistä "multitasking", joka on eri asia
kuin "parallel", siis rinnakkaisuus, jossa asioita tehdään rinnakkain,
samaan aikaan. Termisi ovat liian yleistöäviä ja epämääräisiä.

Multitaskingistä en rupeaisi henkseleitä paukuttamaan koska sillä ei ole
rinakkaisuuden kanssa mitään tekemistä, koska se on puhtaasti
ohjelmallinen asia ja silloin koko alkuperäinen viestisi "Kukas se
väittikään, että Commodore 64 ei pysty moniajoon?" on mieletön -
vart5singkankkan kun ei voi tietää tarkoitatko termiä "parallel" jossa
tehdään aisoit6a oikeasti rinnakkain vaiko termiä "multitaskinmg" jossa
on vaan monta taskia hoidettavana, mutta vaikka peräkkäin.
"Multityskingilla" koska viittaat ominaisuuteen jonka on softalla
tehtävissä kaikissa koneissa jotka softaa ajavat ja myös Commodorfe 64
ajaa softaa.

Joten sotaa ei pysty aiheestasi käymään. Sodankäynnissäkin pitää olla
säännöt eikö sääntäjä saa koko ajan vaihtaa että tietää kuka on voitolla.


--
Re...@iki.fi.nospam.invalid
http://www.iki.fi/Reijo

[Reijo Korhonen]

On Sat, 08 Jul 2017 21:40:38 +0300, Tuomas Yrjövuori wrote:

> Onko moniajon yleinen määritelmä todellakin tuollainen?

Suomenkieli on ansoja täynnä kun puhutaan it-termeistä, Jos puhumme
sanasta multiprocessing "https://en.wikipedia.org/wiki/Multiprocessing"
niin tuo sivusto ottaa kentaan myös sanaan "multitasking" ihan it-
terminologialla, vaikka kyllä minun tosielämän esimerkkini isosta ja
pienestä apteekista palvelipisteineen on ihan analoginen rämän
englanninkielisen it-jargonoin kanssa.

Kyse on siitä tehdäänkö asioita oikeasti kellolla katsoen rinnakkain
"rarallel" vaiko anetaanko prosesseilla vain aikaviipaleita suoritukseen
peräkkäin. Yksiprosessorikone yhdellä ytimellä ei millään pysty
multiprocessing-toimintoon mutta multitasking siltä kyllä käy.



--
Re...@iki.fi.nospam.invalid
http://www.iki.fi/Reijo

[Ari Saastamoinen]

Tuomas Yrjövuori <tuomas.y...@aalto.fi> writes:

> Onko moniajon yleinen määritelmä todellakin tuollainen?

Noi nyt on noita Reijon omia pohdintoja, jossa se ei ota huomioon
lainkaan sitä, että loppujenlopuksi se on melko harvinainen tilanne,
että koneessa on monta ohjelmaa jotka samanaikaisesti haluavat kaiken
CPU-ajan itselleen, kun tyypillinen tilanne on se, että ohjelmat
keskimäärin odottavat jotain. Ja jos noihin kioskivertauksiin
mennään, niin parempi olisi vaikka yhden luukun ja myyjän
grillikioski. Myyjä ottaa ekalta asiakkaalta tilauksen, ja laittaa
ranskalaiset kiehumaan rasvaan, tässä välissä hän joko odottaa
ranskalaisten valmistumista, tai sitten ottaa tilauksen seuraavalta
asiakkaalta, ja alkaa hänelle paistamaan sitä jauhelihapihviä
hampurilaiseen. ja kun ranskalaiset on valmiit, niin sitten antaa ne
asiakas ykköselle jne. Molempia asiakkaita palvellaan yhtä aikaa, ja
molemmat saavat tilauksensa pienimmässä mahdollisessa ajassa eikä
moniajo hidastanut kumpaakaan.

--
Arzka oh3mqu+...@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje

[Ari Saastamoinen]

Reijo Korhonen <reijo.k...@invalid.invalid> writes:

> Mutkun sinun linkkisikin puhui termistä "multitasking", joka on eri asia
> kuin "parallel", siis rinnakkaisuus, jossa asioita tehdään rinnakkain,

Hmmm... mun mielestäni tässä keskustelussa ei ole kukaan puhunut
rinnakkaisajosta ennen sinua, joten mitä merkitystä sillä on, että
moniajo ja rinnakkaisajo ei olekaan ihan täsmälleen samoja asioita.

[Reijo Korhonen]

On Sun, 09 Jul 2017 01:25:56 +0300, Ari Saastamoinen wrote:

> Reijo Korhonen <reijo.k...@invalid.invalid> writes:
>
>> Mutkun sinun linkkisikin puhui termistä "multitasking", joka on eri
>> asia kuin "parallel", siis rinnakkaisuus, jossa asioita tehdään
>> rinnakkain,
>
> Hmmm... mun mielestäni tässä keskustelussa ei ole kukaan puhunut
> rinnakkaisajosta ennen sinua, joten mitä merkitystä sillä on, että
> moniajo ja rinnakkaisajo ei olekaan ihan täsmälleen samoja asioita.

Sillä on juuri se merkitys, että tuleeko tai jatkuuko tässä "Hyvää
Päivää!", "Kirvesvartta" -keskustelu. Jos viitsisit lukea antamani linkin
wikipediasta siitä, millä termeillä mistäkin kannattaa keskustella ja
mitä mikin termi merkitsee, saattaisit ymmärtää miksi.


--
Re...@iki.fi.nospam.invalid
http://www.iki.fi/Reijo

[Reijo Korhonen]

On Sun, 09 Jul 2017 00:55:29 +0300, Ari Saastamoinen wrote:

> Tuomas Yrjövuori <tuomas.y...@aalto.fi> writes:
>
>> Onko moniajon yleinen määritelmä todellakin tuollainen?
>
> Noi nyt on noita Reijon omia pohdintoja, jossa se ei ota huomioon
> lainkaan sitä, että loppujenlopuksi se on melko harvinainen tilanne,
> että koneessa on monta ohjelmaa jotka samanaikaisesti haluavat kaiken
> CPU-ajan itselleen, kun tyypillinen tilanne on se, että ohjelmat
> keskimäärin odottavat jotain.

Noi on nyt noita Arin yksityisisä pohdintopja, kun hän ei viitsi edes
wikipedian sivua lukea aiheesta ennen kuin avaa näppäimistöllisen
arkkunsa.


> Ja jos noihin noihin kioskivertauksiin mennään,

> niin parempi olisi vaikka yhden luukun ja myyjän grillikioski.

Elikkä hänet pelattiin kepabille taikka nakkikioskijonoon. Ei olisi
pelattu jonoon, jos olisi ollut useampi auki oleva luukku, josta saisi
palovelua. Eikä tarvitsisi odottaa tai joutua sen riskin alle, että
joutuu tappeluun jos ennen kuin jono tyhjenee hänen edestään. Joten
vertaus on huono. Tietokoneprosessit ovat jonottaessaan aivoluolleita,
joen ne eivät voi kohdata tilanteita joita Ari kioskijonossa. Jonon ja
tappelupujarin kohtaamisen olis voinut välttää sillä, että tappelupukari
jonottaa eri kioskiluukulle kuin Ari. Jolloin palvelua tulee monelta
kioskiluukulta samaan aikaan.


--
Re...@iki.fi.nospam.invalid
http://www.iki.fi/Reijo

[Ari Saastamoinen]

Reijo Korhonen <reijo.k...@invalid.invalid> writes:

> Elikkä hänet pelattiin kepabille taikka nakkikioskijonoon. Ei olisi
> pelattu jonoon, jos olisi ollut useampi auki oleva luukku, josta saisi
> palovelua. Eikä tarvitsisi odottaa tai joutua sen riskin alle, että

Vaikka siellä grillikioskissa olisi 42 luukkua ja yhtä monta
asiakaspalvelijaa, niin siltikin siellä pitäisi odotta, kun ne
ranskalaiset nyt vain eivät valmistu saman tien.

[Tapio Väättänen]

On 2017-07-08, Ari Saastamoinen <oh3mq...@hyper.fi> wrote:
> Reijo Korhonen <reijo.k...@invalid.invalid> writes:
>
>> Mutkun sinun linkkisikin puhui termistä "multitasking", joka on eri asia
>> kuin "parallel", siis rinnakkaisuus, jossa asioita tehdään rinnakkain,
>
> Hmmm... mun mielestäni tässä keskustelussa ei ole kukaan puhunut
> rinnakkaisajosta ennen sinua, joten mitä merkitystä sillä on, että
> moniajo ja rinnakkaisajo ei olekaan ihan täsmälleen samoja asioita.

Parallel processing ja multitasking on toki *ihan* eria asioita.

Olen samaa mieltä, että kukaan ei puhunut rinnakkaislaskennasta (?), ennen
kuin Reijo otti asian puheeksi.

Itse käsittäisin että multitasking on koko lailla sama kuin time sharing.
Jollain tasolla. Siinä on kaksi ulottuvuutta. Aito monen käyttäjän
ympräristö, jolle moniajo on edellytys.

Nykyiset kännykät ovat kuitenkin hyvä esimerkki yhden käyttäjän systeemistä,
joka ei välttämättä oikeasti edes osaa aitoa moniajoa, koska usein yksi
prosessi kerrallaan oikeasti on käynnissä. Tällainen oli tilanne ehkä 2007
iOS:ssä. Nykyisin lienee toisin.

Yhden käyttäjän ympäristökin voi hallita moniajon. Ehkä OS/2 olisi tästä
kohtuullinen esimerkki. Useampi prosessi etenki saman aikaisesti, mutta
kaikki oli yhden käyttäjän alla.

Parellel computing taas tarkoittaa käytännössä yhden "työn" jakamista
usealla ytimelle tai tietokoneelle. Shared nothing architecture lienee tästä
paras esimerkki. Jokainen laskentayksikkö hoitaa oman osansa ja palauttaa
tuloksen. Hadoop lienee tästä kohtuullinen esimerkki.

Jos asiaa haluaa historiallisesti tarkastella, niin CTSS lieni ensimmäisiä
todelliseen moniajoon kykeniviä järjestelmiä ja ITS kenties legdendaarisen
johde edellisestä.

https://en.wikipedia.org/wiki/Incompatible_Timesharing_System

Tästä lopulta syntyi Multics, jonka puutteiden vuoksi kehitettin UNIX, joka
kuten tiedetään, toimi Linuxin innoittajana ja esimerkkinä.

Linux lienee tämän hetken käytetyin ohjelmisto, ja iOS / MacOS / Darvin taas
kaikki perustuu alkuperäiseen BSD UNIXiin. Kaikki siis lopulta lähti
mallintamalla Compatible Time Sharing System (CTSS), joka siis sekin alun
perin kehitettiin MIT:ssa.

https://en.wikipedia.org/wiki/Compatible_Time-Sharing_System

Sinänsä mielenkiintoista, että mobiilimaailma on 99% joko Linux tai BSD UNIX
-johdannaista.

Parellel computing on todiaan ihan eri asia. Multi tasking on kuin intra
parellism ja parellel computing on sama kuin inter preallelism.

Mä olin joskus todella innokas suomentamaan kaiken, mutten tällä kertaa
jaksa.

--
sip:t...@tav.iki.fi http://tav.iki.fi

"You cannot be too rich, too thin, or commit too often." -- Mark A.

[Tapio Väättänen]

On 2017-07-08, Reijo Korhonen <reijo.k...@invalid.invalid> wrote:
> On Sat, 08 Jul 2017 21:40:38 +0300, Tuomas Yrjövuori wrote:
>
>> Onko moniajon yleinen määritelmä todellakin tuollainen?
>
> Suomenkieli on ansoja täynnä kun puhutaan it-termeistä, Jos puhumme
> sanasta multiprocessing "https://en.wikipedia.org/wiki/Multiprocessing"
> niin tuo sivusto ottaa kentaan myös sanaan "multitasking" ihan it-
> terminologialla, vaikka kyllä minun tosielämän esimerkkini isosta ja
> pienestä apteekista palvelipisteineen on ihan analoginen rämän
> englanninkielisen it-jargonoin kanssa.

Niin, koska multi-processing ja multi-tasking on saman asian eri muotoja,
joten ihmekös tuo.

> Kyse on siitä tehdäänkö asioita oikeasti kellolla katsoen rinnakkain
> "rarallel" vaiko anetaanko prosesseilla vain aikaviipaleita suoritukseen
> peräkkäin. Yksiprosessorikone yhdellä ytimellä ei millään pysty
> multiprocessing-toimintoon mutta multitasking siltä kyllä käy.

Multi tasking / multi processing on sama kuin intra parallelism. Inter
parallelism on sitten se rinnakkaislaskenta.

--
sip:t...@tav.iki.fi http://tav.iki.fi

"Jos Microsoftiin ei voisi luottaa, kehen sitten voisi?"
-- Mikko Hyppönen, F-Secure, tivi.fi 6.1.2011

[Tapio Väättänen]

Jos niitä kioskin luukkuja on enemmän kuin yksi, niin me puhutaan
rinnakkaislaskennasta. Esim Ari tilaa hampurilaisen, ja sitten sitä
valmistetaan kolmella luukulla yhtä aikaa, joten se tulee 1/3 ajasta
vs. jos sitä valmistettaisiin yhdellä luukulla.

Jos taas kolme asiakasta tilaa hampurilaisen, kebabin ja makkaraperunat
samalta luukulta, ja yksi jamppa alkaa valmistaa niitä samaa aikaa, niin me
puhutaan moniajosta. Sillä yhdellä jampalla, joka valmistaa noita, kestää
paljon pidempää valmistaa ne kolme tilausta, kuin jos tilauksia olisi ollut
vain yksi. Olettaen, että tailaukset tehtiin samaan aikaan, ja toimitus on
samaan aikaan.

Toivottasti selvensi käsitteitä, koska analogia on ihan hyvä.

--
sip:t...@tav.iki.fi http://tav.iki.fi

"Missähän sinä sitä olet seurannut, kun en kai lähes kymmeneen vuoteen
ole edes nyysseihin kirjoitellut? Jonka lisäksi alan ammattilaisena kykenen
kyllä oikein hyvin sinua neuvomaan." -- Erkki Norrman 10/20/15

[Reijo Korhonen]

On Sun, 16 Jul 2017 21:51:02 +0000, Tapio Väättänen wrote:

> On 2017-07-08, Reijo Korhonen <reijo.k...@invalid.invalid> wrote:
>> On Sat, 08 Jul 2017 21:40:38 +0300, Tuomas Yrjövuori wrote:
>>
>>> Onko moniajon yleinen määritelmä todellakin tuollainen?
>>
>> Suomenkieli on ansoja täynnä kun puhutaan it-termeistä, Jos puhumme
>> sanasta multiprocessing "https://en.wikipedia.org/wiki/Multiprocessing"
>> niin tuo sivusto ottaa kentaan myös sanaan "multitasking" ihan it-
>> terminologialla, vaikka kyllä minun tosielämän esimerkkini isosta ja
>> pienestä apteekista palvelipisteineen on ihan analoginen rämän
>> englanninkielisen it-jargonoin kanssa.
>
> Niin, koska multi-processing ja multi-tasking on saman asian eri
> muotoja,
> joten ihmekös tuo.

Ei asia ole sama vaikka molemmilla voidaan toki ratkaista samanlaisia
ongelmia elikkä rinnakkaisuutta, mutta multi-taskingiossa se on
näennäistä eli käyttäjä saa vaikutelman siitä että aisoita tapahtuu
samaan aikaan, vaikka niitä oikeasti tapahtuu vuorotellen. multi-
prosessin taas tarkoittaa sitä, että aioita oikeasti tapahtuu samaan
aikaan. Kyse ei siis ole saman asian eri muodoista, vaan aidosti eri
asioista.

>> Kyse on siitä tehdäänkö asioita oikeasti kellolla katsoen rinnakkain

>> "parallel" vaiko anetaanko prosesseilla vain aikaviipaleita

>> suoritukseen peräkkäin. Yksiprosessorikone yhdellä ytimellä ei millään
>> pysty multiprocessing-toimintoon mutta multitasking siltä kyllä käy.
>
> Multi tasking / multi processing on sama kuin intra parallelism. Inter
> parallelism on sitten se rinnakkaislaskenta.

En käytäisi tälläisia termejä ollenkaan sotkemaan selvää asiaa, vaan ihan
niita samoja termejä, joita linkissäni wikipediaan käytetään ja jossa
asia selvitetään selvällä englannin kielellä.


--
Re...@iki.fi.nospam.invalid
http://www.iki.fi/Reijo

[Reijo Korhonen]

On Sun, 16 Jul 2017 21:57:08 +0000, Tapio Väättänen wrote:

> Jos taas kolme asiakasta tilaa hampurilaisen, kebabin ja makkaraperunat
> samalta luukulta, ja yksi jamppa alkaa valmistaa niitä samaa aikaa, niin
> me puhutaan moniajosta. Sillä yhdellä jampalla, joka valmistaa noita,
> kestää paljon pidempää valmistaa ne kolme tilausta, kuin jos tilauksia
> olisi ollut vain yksi. Olettaen, että tailaukset tehtiin samaan aikaan,
> ja toimitus on samaan aikaan.
>
> Toivottasti selvensi käsitteitä, koska analogia on ihan hyvä.

Ei analogia ole hyvä. Analogiassa sotketaan ja jätetään määrittelemättä
jonossa ja palvelussa olemisen käsite joka nakkikioskiryppäässä ja
tietokoneohjelmien palvelemisesssa tietokoneella ne ovat täysin
erilaisia. Kahdesta täysin erilaisesta kontekstista et saa millään hyvää
analogiaa. Analogiassa kun pitäisi löytää jotain sellaista kuin
"samanlaista kuin" ja tässä Arin analogiassa sellaista ei voi olla.


--
Re...@iki.fi.nospam.invalid
http://www.iki.fi/Reijo

[Reijo Korhonen]

On Sun, 16 Jul 2017 21:47:41 +0000, Tapio Väättänen wrote:

> On 2017-07-08, Ari Saastamoinen <oh3mq...@hyper.fi> wrote:
>> Reijo Korhonen <reijo.k...@invalid.invalid> writes:
>>
>>> Mutkun sinun linkkisikin puhui termistä "multitasking", joka on eri
>>> asia kuin "parallel", siis rinnakkaisuus, jossa asioita tehdään
>>> rinnakkain,
>>
>> Hmmm... mun mielestäni tässä keskustelussa ei ole kukaan puhunut
>> rinnakkaisajosta ennen sinua,

Asiahan oli esillä otsikossa, joka ei vastannut viestin sisältöä. Puhuin
tästä ristiriidasta jonka sinä yhmmärsit eli ymmärsit viestini ihan
oikein.

> joten mitä merkitystä sillä on, että
>> moniajo ja rinnakkaisajo ei olekaan ihan täsmälleen samoja asioita.

Kysymysmerkki puuttuu. Merkitseekö se sitä, että vastaat omaan
kysymykseesi itse? Katsotaanpa.

> Parallel processing ja multitasking on toki *ihan* eria asioita.

Merkitsee. Vastaat kysymykseesi itse. Näin se on.

> Olen samaa mieltä, että kukaan ei puhunut rinnakkaislaskennasta (?),
> ennen kuin Reijo otti asian puheeksi.

Tämä on toistoa. Asia tulee selväksi jo yllä.

> Itse käsittäisin että multitasking on koko lailla sama kuin time
> sharing. Jollain tasolla. Siinä on kaksi ulottuvuutta. Aito monen
> käyttäjän ympräristö, jolle moniajo on edellytys.

Time sharing, time slicing, Yksi palvelupiste, jossa palvellaan
jonottavia olioita. Jonotusteoria on keksitty jo viime vuosituhannella ja
sieltä saa yksikäsitteidet käsitteet ja mallinnuksen.

> Nykyiset kännykät ovat kuitenkin hyvä esimerkki yhden käyttäjän
> systeemistä,

Yhden tai monen käyttäjän systeemien tarkastelu vie ihan eri
ongelmatiikkaan. Kännykät ovat oikeasti tietokoneita joten kännykkä ei
ole edes tietokoneesta erikoistapaus. Kännykässä on ajoaikaisesti kaksi
käyttäjää, pääkäyttäjä (root) ja käyttäjä (user). Kännyköiden
käyttöjärjestelmissä Unix-peräiset laitteet ovat jo lähes 100%:n
markkiosuudessa. Unix on lähtökohtaisesti monen käyttäjän järjestelmä.
Kun puhutaan käyttäjistä, puhutaan käyttöoikeuksista eri resursseihin. Se
on täysin eri asia kuin moniajo.

Jos käytöoikeudet laitteessa on rataksitu, niin silloin on olemassa
kirjanpito siitä kuka omistaa minkäkin resursin ja mitkä ovat säännöt
joilla noita resursseja jaetaan toisten käytäjien käyttöön.

Käyttöoikeuskeskustelu vie ihan toiseen ongelmatiikkaan kuin moniajo ja
nykyisin resurssit ovat nähtävissä verkon kautta. Kuka saa nähdä mitäkin
ei ole enää edes käyttäjän omassa laitteessa oleva ongelma, vaan pääosin
se on verkossa majaileva ongelma, jossa käyttäjä ei voi edes tietää tai
hallita sitä laitetta joka hänen resurssiensa käytön ratkaisee. Kaikki
tapahtuu "verkon perillä".

> joka ei välttämättä oikeasti edes osaa aitoa moniajoa, koska usein yksi
> prosessi kerrallaan oikeasti on käynnissä. Tällainen oli tilanne ehkä
> 2007 iOS:ssä. Nykyisin lienee toisin.

Aivan. Kuten tietokoneissa yleensäkin. Kännyköissä on ytimiä ainakin yhtä
monta kuin tietopkoneissakin tuppaa olemaan eli neljä tai enemmän. Neljä
asiaa saattaa siis kännykässäkin tapahtua yhtä aikaa kellolla mitaten tai
useampikin. Mutta kellä on oikeaa käyttöä tälläiselle rinnakkaisuudella,
se on eri asia.

> Yhden käyttäjän ympäristökin voi hallita moniajon. Ehkä OS/2 olisi tästä
> kohtuullinen esimerkki. Useampi prosessi etenki saman aikaisesti, mutta
> kaikki oli yhden käyttäjän alla.
>
> Parellel computing taas tarkoittaa käytännössä yhden "työn" jakamista
> usealla ytimelle tai tietokoneelle.

Aivan, mutta tuo työn ajaminen usealle tietokoneelle on jäänyt huonosti
toteutetuksi. Useimmiten kyllä nykyisin käyttäjän työ jaetaab nimenomaan
usealle tietokonneelle elikkä omalle työasemalle tai päätelaitteelle ja
verko perillä oleville paövelimille mutta asiat eivät tapahdu juurikaan
rinnakkain, vaan päätelaite aina joutuu odottamaan vrkon perillä olevien
palvelimien vastauksia. "Verkko lagaa" on nuorten yleisin sanonta ;-)

> Shared nothing architecture lienee
> tästä paras esimerkki. Jokainen laskentayksikkö hoitaa oman osansa ja
> palauttaa tuloksen. Hadoop lienee tästä kohtuullinen esimerkki.

En usko että esimerkkisi selventää asiaa.

> Jos asiaa haluaa historiallisesti tarkastella, niin CTSS lieni
> ensimmäisiä todelliseen moniajoon kykeniviä järjestelmiä ja ITS kenties
> legdendaarisen johde edellisestä.

>
> https://en.wikipedia.org/wiki/Incompatible_Timesharing_System

Elikkä historia johti vuoropalvelusta "Time sharing" ...

> Tästä lopulta syntyi Multics, jonka puutteiden vuoksi kehitettin UNIX,
> joka kuten tiedetään, toimi Linuxin innoittajana ja esimerkkinä.

... moniajoon "parallel processing" joka on tänä paivänä "vaiheessa",
kuten asiat tuppaavat olemaan. Prosessorien viivaleveyttä on prosessorien
nopeuttamiseksi pienennetty äärimmilleen ja sitä ei juurikaan voi enää
pienentää etteivät elektronit hyppää vääriin paikkoihin ja
ylikuumenmisongelmat kaada koko systeemiä. Silloin ytimien lisäys on
ainoa keino nopeuttaa koneita ja silloin rinnakkaisuuden lisääminen
tehtävissä on ainoa keinoa nopeuttaa asioiden tapahtumista kellolla
mitaten. Tämä on kuitenkin vaikea ongelma. Me ihmiset halitsemme
parhaiten peräkkäin tapahtuvat asiat.

Heti kun asioita alkaa tapahtua rinnakkain ja satunnaisessa
järjestyksessä, olomme tulee sekavaksi ja hallinnan tunne menee. Siksi
rinnakkaisuuden tuominen tehtävien ratkaisemiseen on vielä aika
alkeellisella tasolla. Kaikki tahtoo olla vielä "time sharing" tasolla
jopa niin, että että suosiota on tullut ohjelmointikielille ja
arkkitehtuureille, joissa nimenomaan ei ole minkäänlaista rinnakkaisuutta
asioille. Että kaikki menisi oikein.

Kun ei osata miettiä asioita ja ehtoja, joilla homma voisi edetä kun
joitakin osatehtäviä on saatu tehtyä jossakin järjestyksessä. Mitä
seuraavaksi voidaan tehdä kun tämä on tehty. Talotkin tupataan tekemään
jossakin järjestyksessä. Ainakin lattia on olemassa ennen seiniä. Ennen
seiniä ei voi asentaa keittiön kaapistoja, kolmoskerrosta ei voi tehdä
ennen ykköskerrosta. Betonivalun pitäisi kuivua ennen kuin lattiamaton
voi liimata siihen. Vaikka tuntuu että nykyisin tätä rinnakkaisuutta
yritetään tosielämässäklin tilanteissa joissa sitä ei ainakaan niin kuin
ihminen ne tekee nyt voi oikeasti tehdä. Siloin ihan fyysiset asiat
homehtuvat. Atk-maailmassa saa asiat sotkuun virtuaalisilla asioilla
vieläkin helpommin.


--
Re...@iki.fi.nospam.invalid
http://www.iki.fi/Reijo

[Ari Saastamoinen]

Reijo Korhonen <reijo.k...@invalid.invalid> writes:

> Ei analogia ole hyvä. Analogiassa sotketaan ja jätetään määrittelemättä
> jonossa ja palvelussa olemisen käsite joka nakkikioskiryppäässä ja
> tietokoneohjelmien palvelemisesssa tietokoneella ne ovat täysin
> erilaisia. Kahdesta täysin erilaisesta kontekstista et saa millään hyvää
> analogiaa. Analogiassa kun pitäisi löytää jotain sellaista kuin
> "samanlaista kuin" ja tässä Arin analogiassa sellaista ei voi olla.

Itse ensimmäisenä toit tähän vertailuun mukaan myyntiliikeanalogian
seuraavalla tavalla.

> > Vertaapa pientä apteekkia jossa on vain yksi reseptiasiakkaita palveleva
> > luukku. Sinne voi tulla tietenkin yhtä monta asiakasta kuin isompaankin
> > apteekkiin jossa on kymmenen luukkua. Isossa ja pienessä apteekissa
> > voidaan paavella yhtä montaa asiakasta, mutta isommassa se vaan käy

> > nopeammin. Iso apteekki, jossa on kymmenen palveluluukkua palvelee

> > kymmentä asiakasta oikeasti yhtä aikaa - ainakin ajoittain kun
> > asiakaspalvelijat eivät hommaa muuta - eli pystyy moniajoon. Pieni
> > apteekki pystyy vain vuoroajoon. Molemmissa kuitenkin hoituvat samat
> > asiat.

Onko tuo sinun kirjoittamasi analogia sitten muka jollain tapaa
parempi (tuolla ylempänä lainatun "analogia":n selityksesi mukaan)?
Ja millä perusteella?

Mielestäni toi apteekin muuttaminen nakkikioskiksi on hyvinkin
perusteltu nimenomaan tuon määrittelemäsi analogian perustella. Suuri
osa apteekkien asiointiajasta ajasta menee (ainakin omien
apteekkikäyntieni perusteella) valmiin tuotteen rahastukseen, ja itse
tuotteen prosessointiaika on nolla. Ja kun muutin apteekin
nakkikioskiksi, niin mielestäni analogia parani, kun nakkikioskilla
myydäänkin tuotetta, joka valmistetaan (ainakin jollain tavalla) siinä
paikanpäällä, ja suurin osa asiointiajasta menee itse tuotteen
prosessointiin, joka sekään ei vaadi koko aikaa henkilöstön jatkuvaa
tekemistä, vaan henkilöstö voi ihan hyvin moniajaa palvellen toisia
asiakkaita sillä aikaa kun ensimmäisen tuote valmistuu.

[Ari Saastamoinen]

Reijo Korhonen <reijo.k...@invalid.invalid> writes:

> On Sun, 16 Jul 2017 21:47:41 +0000, Tapio Väättänen wrote:
> > On 2017-07-08, Ari Saastamoinen <oh3mq...@hyper.fi> wrote:

> >> Hmmm... mun mielestäni tässä keskustelussa ei ole kukaan puhunut
> >> rinnakkaisajosta ennen sinua,
>
> Asiahan oli esillä otsikossa, joka ei vastannut viestin sisältöä. Puhuin
> tästä ristiriidasta jonka sinä yhmmärsit eli ymmärsit viestini ihan
> oikein.
>
> > joten mitä merkitystä sillä on, että
> >> moniajo ja rinnakkaisajo ei olekaan ihan täsmälleen samoja asioita.
>
> Kysymysmerkki puuttuu. Merkitseekö se sitä, että vastaat omaan
> kysymykseesi itse? Katsotaanpa.
>
> > Parallel processing ja multitasking on toki *ihan* eria asioita.
>
> Merkitsee. Vastaat kysymykseesi itse. Näin se on.

Nyt tässä sotket lainauksia ja kirjoittajia keskenään. Ensinnäkin toi
"joten mitä merkitystä sillä on, että" -rivi oli mun tekemäni vaikka
sen laitoitkin Tapion piikkiin.

Ja sitten tämä viimeisin lainauksesi, joka sitten ilmeisesti vastasi
tuohon esittämääni kysymykseen (ilman kysymysmerkkiä myönnän), ei
ollutkaan enää mun tekemäni vaan (ilmeisesti?) Tapion. Joten miten
vastaan siihen itse, jos vastauksen kerran esitti Tapio :)

> > Olen samaa mieltä, että kukaan ei puhunut rinnakkaislaskennasta (?),
> > ennen kuin Reijo otti asian puheeksi.
>
> Tämä on toistoa. Asia tulee selväksi jo yllä.

Onko se toistoa, jos Tapio ensimmäisen kerran kertoo olevansa kanssani
samaa mieltä?

> ole edes tietokoneesta erikoistapaus. Kännykässä on ajoaikaisesti kaksi
> käyttäjää, pääkäyttäjä (root) ja käyttäjä (user).

En tiedä nyt ihan viimeisimpien kännyköiden sielunelämää, mutta
ainakin jossain vaiheessa noissa oli viä "roottiakin kovempi"
käyttäjätaso, jolla noi kaikki puhelinverkon palvelut pyörivät, ja
joissain laitteissa on jopa ihan erillinen suoritin noille
puhelintoiminnoille.

[Juhani Varemo]

> Talotkin tupataan tekemään
> jossakin järjestyksessä. Ainakin lattia on olemassa ennen seiniä. Ennen
> seiniä ei voi asentaa keittiön kaapistoja, kolmoskerrosta ei voi tehdä
> ennen ykköskerrosta. Betonivalun pitäisi kuivua ennen kuin lattiamaton
> voi liimata siihen. Vaikka tuntuu että nykyisin tätä rinnakkaisuutta
> yritetään tosielämässäklin tilanteissa joissa sitä ei ainakaan niin kuin
> ihminen ne tekee nyt voi oikeasti tehdä. Siloin ihan fyysiset asiat
> homehtuvat. Atk-maailmassa saa asiat sotkuun virtuaalisilla asioilla
> vieläkin helpommin.

Tuokin on hieman vaarallinen esimerkki... käytännössä tuossakin on
todellista rinnakkaisprosessointia. Elementtitehdas tekee elementtejä,
peltifirma kattopeltejä, harkkotehdas harkkoja, saha puutavaraa,
ikkunatehdas ikkunoita. Kaikki rinnakkain ja samaan aikaan.
Eräänlaisia apuprosessoreita :-) IT-puolella kyse voisi olla vaikka
erillisistä prosessoreista, tai eri ytimistä jotka ajavat omia säikeitään.

Loppukokoonpanossa sitten käytetään noita valmiiksi
'rinnakkaisprosessoituja' jonoon varastoituja tuotteita.

Isoja työmaita tehdään myös mahdollisuuksien mukaan eri vaiheita
päällekkäin. Tietysti perustus täytyy ensin olla, mutta pilvenpiirtäjien
tapauksessa ei ole mitenkään harvinaista että alakerroksia jo sisustetaan,
välissä valetaan ja samaan aikaan huipulla vielä kootaan uutta runkoa
teräspalkeista.

[Reijo Korhonen]

On Mon, 17 Jul 2017 16:13:17 +0300, Ari Saastamoinen wrote:

> Nyt tässä sotket lainauksia ja kirjoittajia keskenään.

Enkä sotke. Lainaukset on viestistä johon vastaan.

> Ensinnäkin toi
> "joten mitä merkitystä sillä on, että" -rivi oli mun tekemäni vaikka sen
> laitoitkin Tapion piikkiin.

Enkä laittanut. On siinä '>'-merkit kohdillaan. Toisin kuin sinun
viestissäsi, jossa on riveillä ">> >" josta ei saa tosiaan selvää,
Onkohan sinulla asetukset nyytistimessäsi kohdillaan?


--
Re...@iki.fi.nospam.invalid
http://www.iki.fi/Reijo

[Reijo Korhonen]

On Mon, 17 Jul 2017 20:16:26 +0300, Juhani Varemo wrote:

>> Talotkin tupataan tekemään jossakin järjestyksessä. Ainakin lattia on
>> olemassa ennen seiniä. Ennen seiniä ei voi asentaa keittiön kaapistoja,
>> kolmoskerrosta ei voi tehdä ennen ykköskerrosta. Betonivalun pitäisi
>> kuivua ennen kuin lattiamaton voi liimata siihen. Vaikka tuntuu että
>> nykyisin tätä rinnakkaisuutta yritetään tosielämässäklin tilanteissa
>> joissa sitä ei ainakaan niin kuin ihminen ne tekee nyt voi oikeasti
>> tehdä. Siloin ihan fyysiset asiat homehtuvat. Atk-maailmassa saa asiat
>> sotkuun virtuaalisilla asioilla vieläkin helpommin.
>
>
> Tuokin on hieman vaarallinen esimerkki... käytännössä tuossakin on
> todellista rinnakkaisprosessointia. Elementtitehdas tekee elementtejä,
> peltifirma kattopeltejä, harkkotehdas harkkoja, saha puutavaraa,
> ikkunatehdas ikkunoita. Kaikki rinnakkain ja samaan aikaan.

Mutta ei välttämättä samalle työmaalle vaan varastoon ja siitä sitten
monelle työmaalle valmiina tavarana. IT-maailma taas ei voi ostaa mitään
valmiina, vaan kaikki annetaan aina jollekin tehtöäväksi ainutlaatuisina
yksittäiskappaleina. Olet oikeassa. IT-maailma ja reaalimaailma harvoin
kohtaavat. Hyviä analogioita reaalimaaiolman ja IT-maailman välillä on
vaikea löytää. Jonoteroria kyllä selittää ongelmatiikan riittävän hyvin,
mutta se ei ole havainnollinen.

Tarkoitukseni oli kuitenkin tuoda alkuperäiosessä viestissäni esille sen,
miksi rinnakkaisuus on niin tärkeä asia nykyisin, koska se on nykyään
ainoa keino lisätä prosessoinnin vauhtia. Rinnakkaisuus sisältää
kuitenkin runsaasti huonosti ratkaistuja hallisemattomia ongelmia ja tuo
rakennusalan esimerkki oli mikana siinä tarkoituksessa että se kuvaisi
sitä, kuinka vaikeaa ihmisen on hallita samaan aikaan tapahtuvia asioita
eli selittää sillä sitä, miksi rinnakkaisuutta on IT-maailmassa ratkaistu
niin heikosti. Se kun on voikeaa. En yrittänyt tehdä analogiaa ohgjelmien
ja talon rakennuksen välillä.

> Eräänlaisia apuprosessoreita :-) IT-puolella kyse voisi olla vaikka
> erillisistä prosessoreista, tai eri ytimistä jotka ajavat omia
> säikeitään.

Säie on vain työväline. Onbgelma ei ole se, etteikö säikeitä voitaisi
ajaa rinakkain. Ongelma on se, että ihminen ei osaa jakaa työtä
itsenäisiin rinnakkaisiin osiin jotka voidaan ajaa säikeissä. Ei hallita
sitä koska seuraava vaihe voidaan aloittaa kun sen riippuvuudet ovat
valmiina. Tämä hallitaan teoriassa mutta ei käytännössä.

Mutta tässä talonrtakkusanaliogia toimii hyvin. Jokainen tietää että
lattiamattoa ei saa liimata lattian betoniin ennen kuin betoni on
kuivunut. Mutta käytännössä käy niin, että virolainen osaurakkafirma ei
ymmärrä kommunikoida kenenkään kanssa tai heillä on vaan kiire saada
rahat urakasta ja ne kuitenkin kliimaavat lattiamaton märän betonin
päälle perävalotakuulla. KUkaan ei huomaa mitään ennen kuin puolen vuoden
päästä taloon muuttaneet työntekijät alkavat oirehtia.

Vähän samalla tavalla säikeitetty ohjelma toimii ja ei toimi. Se näyttää
välillä toimivan ihan OK, mutta joskus ei, kun joku "maton liimausta"
vastaava työvaihe pääsee alkamaan liian aikaisin, kun säikeiden
synkronointi on koodattu väärin.

Totta kai sanotte kuten Kekkonen aikoinaan että "Saatanan tunarit". Totta
kai pitää koodata oikein ja pitää testata että se toimii rinnakkain joka
tilanteessa. Juu, pitää pitää, mutta kun ne koodit on ihmisten tekemiä ja
niille sattuu ja tapahtuu, ihan niin kuin siellä työmaalla lattiamattojen
liimauksessa, syystä tai toisesta.

Mutta joo, ollaan tulevaisuususkoisia ja uskotaan, että jonakin päivänä
iminen tämänkin osaa, varmistaa että lattiamatto tulee liimattua kuivan
betonin päälle ja että säikeissä ajettavien rinnakkaisten työvaiheiden
kynkronointi menee oikein IT-ohjelmissa.

>
> Loppukokoonpanossa sitten käytetään noita valmiiksi
> 'rinnakkaisprosessoituja' jonoon varastoituja tuotteita.

Just, just, oikein koodatussa ohjelmassa näin. Ja oikein toimivalla
työmaalla kaikki on oikein rakennettu.


--
Re...@iki.fi.nospam.invalid
http://www.iki.fi/Reijo

[Tapio Väättänen]

On 2017-07-17, Reijo Korhonen <reijo.k...@invalid.invalid> wrote:
> Tarkoitukseni oli kuitenkin tuoda alkuperäiosessä viestissäni esille sen,
> miksi rinnakkaisuus on niin tärkeä asia nykyisin, koska se on nykyään
> ainoa keino lisätä prosessoinnin vauhtia. Rinnakkaisuus sisältää
> kuitenkin runsaasti huonosti ratkaistuja hallisemattomia ongelmia ja tuo
> rakennusalan esimerkki oli mikana siinä tarkoituksessa että se kuvaisi
> sitä, kuinka vaikeaa ihmisen on hallita samaan aikaan tapahtuvia asioita
> eli selittää sillä sitä, miksi rinnakkaisuutta on IT-maailmassa ratkaistu
> niin heikosti. Se kun on voikeaa. En yrittänyt tehdä analogiaa ohgjelmien
> ja talon rakennuksen välillä.

Rinnakkaislaskenta on tehnyt hillittömiä harppauksia Hadoopin ja Sparkin
ansiosta. Samoin ihan perinteisetkin tietovarastointiratkaisut ovat nykyisin
poikkeuksetta rinnakkaislaskentaan perustuvia.

--
sip:t...@tav.iki.fi http://tav.iki.fi

"The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts." -- Bertrand Russell

[Reijo Korhonen]

On Mon, 24 Jul 2017 10:21:25 +0000, Tapio Väättänen wrote:

> On 2017-07-17, Reijo Korhonen <reijo.k...@invalid.invalid> wrote:
>> Tarkoitukseni oli kuitenkin tuoda alkuperäiosessä viestissäni esille
>> sen, miksi rinnakkaisuus on niin tärkeä asia nykyisin, koska se on
>> nykyään ainoa keino lisätä prosessoinnin vauhtia. Rinnakkaisuus
>> sisältää kuitenkin runsaasti huonosti ratkaistuja hallisemattomia
>> ongelmia ja tuo rakennusalan esimerkki oli mikana siinä tarkoituksessa
>> että se kuvaisi sitä, kuinka vaikeaa ihmisen on hallita samaan aikaan
>> tapahtuvia asioita eli selittää sillä sitä, miksi rinnakkaisuutta on
>> IT-maailmassa ratkaistu niin heikosti. Se kun on voikeaa. En yrittänyt
>> tehdä analogiaa ohgjelmien ja talon rakennuksen välillä.
>
> Rinnakkaislaskenta on tehnyt hillittömiä harppauksia Hadoopin ja Sparkin
> ansiosta. Samoin ihan perinteisetkin tietovarastointiratkaisut ovat
> nykyisin poikkeuksetta rinnakkaislaskentaan perustuvia.

No saa harppoa sitten edelleenkin ja pitkään. Rinnakkaislaskenta on
merkittävissä määrin käytössä erittäin kapea-alaisissa ongelmissa kuten
kuvankäsittelyssä. Näissä ongelma on pystytty mallintamaan riittävästi
jotta rinnakkaislaskennasta on oikeasti hyötyä. Parhaiten toimivat
rinnakkaislaskentayksiköthän ovat näyttäkortteja.

Kun Googlettaa "spark parallel processing" huomaa heti, että tulokset
ovat hyvin ristiriitaisia. Ensimmäinen linkki sanoo, että
testiohjelmassa, jossa kokeiltii csv.tiedostojen rinnakkaista lukua
perinteisen peräkkäisen toiminnan suhteen, ei saatukaan mitään
nopeusetua. Tämä on täysin odotettu tulos. Massamuistit rinnakkaistavat
luvun jo nyt niin paljon kuin pystyvät ja siitä suoritusaika riippuu.
Rinnakkaiset säikeet ovat siis jonoissa odottamassa massamuistia, joka
huhkii niin paljon kuin kerkiää. Testiohjelman pitäisi olla paljon
monimutkaisempi jotta rinnakkaisuudesta olisi hyötyä.

Apache Sparkista sanotaan näin: Apache Spark is an open-source cluster-
computing framework. Se on siis framework jolla _ratkaistut_ rinnakkaiset
tehtävät voidaa suorittaa. Nykytiedon tasolla ongelma ei ole laitteioston
tai frameworkkien puute vaan itse rinnakkaisuuden ongelman ratkaisu
käytännön tilanteissa. Se miten jokin ongelma kuvataan rinnakksina
työvaiheina jotka oikeasti voidaan suorittaa rinnakkain ja kuinka hallita
se koska seuraava rinnakkainjen työvaihe voi käynnistyä ja käyttää ajan
tasalla olevaa lähtödataa ja tuottaa oikeaa tulosdataa. Tämän miettiminen
on nykypäivänä käytännön ongelmissa niin työlästä ja tulokset
riskialttiita, että käytännössä työnantajat määräävät työntekijänsä
tekemään tuottavampaa työtä.

Näin se menee käytännössä. Yliopistoissa mietitään ensin teoreettisia
ongelmia ja niihin ratkaisuja, mutta aika kauan tiedemaailma liitelee
omissa pilvissään ennen kuin kohtaa reaalimaailman ja pääsee sille
tasolle, että ratkaisuja voidaan oikeasti soveltaa.

"tietovarastointi" on sen verran geneerinen termi, että se tarkoittaa
ihan kaikkea mitä tietokoneilla tehdään, sillä tietokoneilla käsitellään
tietoa ja se pitää aina varastoida jonnekin, pitemmäksi tai lyhyemmäksi
ajaksi jotta tieto ei katoaisi. Yleensä emme halua että tieto katoaa.
Joskus kyllä se olisi kiva, jos tieto on epämiellyttävä ;-)



--
Re...@iki.fi.nospam.invalid
http://www.iki.fi/Reijo

[Tapio Väättänen]

On 2017-07-25, Reijo Korhonen <reijo.k...@invalid.invalid> wrote:
> On Mon, 24 Jul 2017 10:21:25 +0000, Tapio Väättänen wrote:
>
>> On 2017-07-17, Reijo Korhonen <reijo.k...@invalid.invalid> wrote:
>>> Tarkoitukseni oli kuitenkin tuoda alkuperäiosessä viestissäni esille
>>> sen, miksi rinnakkaisuus on niin tärkeä asia nykyisin, koska se on
>>> nykyään ainoa keino lisätä prosessoinnin vauhtia. Rinnakkaisuus
>>> sisältää kuitenkin runsaasti huonosti ratkaistuja hallisemattomia
>>> ongelmia ja tuo rakennusalan esimerkki oli mikana siinä tarkoituksessa
>>> että se kuvaisi sitä, kuinka vaikeaa ihmisen on hallita samaan aikaan
>>> tapahtuvia asioita eli selittää sillä sitä, miksi rinnakkaisuutta on
>>> IT-maailmassa ratkaistu niin heikosti. Se kun on voikeaa. En yrittänyt
>>> tehdä analogiaa ohgjelmien ja talon rakennuksen välillä.
>>
>> Rinnakkaislaskenta on tehnyt hillittömiä harppauksia Hadoopin ja Sparkin
>> ansiosta. Samoin ihan perinteisetkin tietovarastointiratkaisut ovat
>> nykyisin poikkeuksetta rinnakkaislaskentaan perustuvia.
>
> No saa harppoa sitten edelleenkin ja pitkään. Rinnakkaislaskenta on
> merkittävissä määrin käytössä erittäin kapea-alaisissa ongelmissa kuten
> kuvankäsittelyssä. Näissä ongelma on pystytty mallintamaan riittävästi
> jotta rinnakkaislaskennasta on oikeasti hyötyä. Parhaiten toimivat
> rinnakkaislaskentayksiköthän ovat näyttäkortteja.
>
> Kun Googlettaa "spark parallel processing" huomaa heti, että tulokset
> ovat hyvin ristiriitaisia.

Googlettaa? Mulla on kyllä ihan käytössä Spark ja tiedän googlettammatta.

--
sip:t...@tav.iki.fi http://tav.iki.fi

"Microsoft innovate! Give me a fucking break." -- Larry Ellison

[Reijo Korhonen]

On Mon, 31 Jul 2017 15:05:24 +0000, Tapio Väättänen wrote:

> Googlettaa? Mulla on kyllä ihan käytössä Spark ja tiedän
> googlettammatta.

No sittenpä tiedät millaisia ongelmia on sielläpäin mallinnettu
rinnakkaisiksi tehtäviksi. Mutta jos et googleta, ety tiedä millasia
ongelmia muut ovat osanneet mallintaa rinnakkaisiksi tehtäviksi. Tämä
ongelma kun ei ole mitenkään triviaali kuten edellisessä viestissäni
kuvasin ja framework auttaa toteutuksessa vasta kun mallinnus on osattu
tehdä.



--
Re...@iki.fi.nospam.invalid
http://www.iki.fi/Reijo

[Tuomas Yrjövuori]

Reijo Korhonen kirjoitti 03.08.2017 klo 02:26:
> Mutta jos et googleta, ety tiedä millasia
> ongelmia muut ovat osanneet mallintaa rinnakkaisiksi tehtäviksi. Tämä
> ongelma kun ei ole mitenkään triviaali kuten edellisessä viestissäni
> kuvasin ja framework auttaa toteutuksessa vasta kun mallinnus on osattu
> tehdä.

Jos ongelma on rinnakkaistettavissa, jonkun täytyy koordinoina ongelman
palasien jakaminen suorittavien yksiköiden välille. Eräs tapa hoitaa
asia on antaa ongelman jakaminen käyttöjärjestelmän ja/tai
käyttöjärjestelmien hoidettavaksi.

Jos suorittavat yksiköt sattuvat olemaan eri puolilla maailmaa,
kannattaa varautua ennalta määräämättömiin latensseihin ja jopa
suorittavien yksiköiden käyttökatkoksiin. Se on sitä
rinnakkaislaskentaa. Jos ongelma on liukuhihnoitettavissa, kannattaa
etsiä ongelman kriittinen polku ja kiinnittää siihen erityistä huomiota.

Jos taas puhutaan moniajosta, siinä resurssien jakamisen merkitys
korostuu entisestään. Erityisen tärkeää se on silloin, kun järjestelmän
täytyy pystyä kovaan reaaliaikaisuuteen. Samaan yhteyteen huomauttaisin,
että myöskään eri puolille maailmaa rinnakkaistetun ongelman ei ole
mahdotonta pystyä kovaan reaaliaikaisuuteen, vaikka se vaikeaa olisikin.

--
Tuomas Yrjövuori

[Tapio Väättänen]

On 2017-08-02, Reijo Korhonen <reijo.k...@invalid.invalid> wrote:
> On Mon, 31 Jul 2017 15:05:24 +0000, Tapio Väättänen wrote:
>
>> Googlettaa? Mulla on kyllä ihan käytössä Spark ja tiedän
>> googlettammatta.
>
> No sittenpä tiedät millaisia ongelmia on sielläpäin mallinnettu
> rinnakkaisiksi tehtäviksi. Mutta jos et googleta, ety tiedä millasia
> ongelmia muut ovat osanneet mallintaa rinnakkaisiksi tehtäviksi. Tämä
> ongelma kun ei ole mitenkään triviaali kuten edellisessä viestissäni
> kuvasin ja framework auttaa toteutuksessa vasta kun mallinnus on osattu
> tehdä.

No sanopa nyt ihan omin sanoin mitä nämä Sparkin ja Hadoopin ongelmat
rinnakkaislaskennassa ovat?

--
sip:t...@tav.iki.fi http://tav.iki.fi

"Ei me nyt tietenkään niin paljon saada kuin jotkut poikabändit."
-- Timo Kotipelto IS:ssa 11.9.2015

[Tapio Väättänen]

On 2017-08-03, Tuomas Yrjövuori <tuomas.y...@aalto.fi> wrote:
> Reijo Korhonen kirjoitti 03.08.2017 klo 02:26:
>> Mutta jos et googleta, ety tiedä millasia
>> ongelmia muut ovat osanneet mallintaa rinnakkaisiksi tehtäviksi. Tämä
>> ongelma kun ei ole mitenkään triviaali kuten edellisessä viestissäni
>> kuvasin ja framework auttaa toteutuksessa vasta kun mallinnus on osattu
>> tehdä.
>
> Jos ongelma on rinnakkaistettavissa, jonkun täytyy koordinoina ongelman
> palasien jakaminen suorittavien yksiköiden välille. Eräs tapa hoitaa
> asia on antaa ongelman jakaminen käyttöjärjestelmän ja/tai
> käyttöjärjestelmien hoidettavaksi.
>
> Jos suorittavat yksiköt sattuvat olemaan eri puolilla maailmaa,
> kannattaa varautua ennalta määräämättömiin latensseihin ja jopa
> suorittavien yksiköiden käyttökatkoksiin. Se on sitä
> rinnakkaislaskentaa. Jos ongelma on liukuhihnoitettavissa, kannattaa
> etsiä ongelman kriittinen polku ja kiinnittää siihen erityistä huomiota.

Jos nyt Hadoopista puhutaan, niin siinähän on ihan oma mallinsa sille, kuin
etäällä eri noodit ovat toisistaan. Lisäksi, kun data on hajautettu eri
noodien kesken tasaisesti, niin toisin kuin Reijo väittää, mallinnus ei ole
useimmiten ongelma ollenkaan, koska HDFS on hajautettu
tietodostojärjestelmä- Niinpä jokainen noodi käsittelee omilta levyiltään
löytyvän datan.

Samoin esimerkiksi tietovarasto puolella Netezza ja INZA. Jokainen snippet
processing unit (SPU) on vastauussa omalta data sliceltä löytyvästä datasta.
Tällöin rinnakkaisuus toimii juuri niin hyvin kuin valittu distribution key
on. Ei siis kovin suuri työ mallinnuksen suhteen, koska ainoastaan sillä on
merkitystä, kuinka tasaisesti data on jakautunut.

> Jos taas puhutaan moniajosta, siinä resurssien jakamisen merkitys
> korostuu entisestään.

Moniajossa useita laskentatehtäviä ajetaan yhden noodin sisällä.
Rinnakkaislaseknnassa tietysti yhtä laskenta tehtävää suoritetaan usealla
noodilla.

> Erityisen tärkeää se on silloin, kun järjestelmän
> täytyy pystyä kovaan reaaliaikaisuuteen. Samaan yhteyteen huomauttaisin,
> että myöskään eri puolille maailmaa rinnakkaistetun ongelman ei ole
> mahdotonta pystyä kovaan reaaliaikaisuuteen, vaikka se vaikeaa olisikin.

Minusta sekä Hadoop että Spark osoittaa, että tässä on tehty valtavia
harppauksia. En tiedä miten Suomessa, mutta ainakin Torontossa joka ikisellä
puljulla on vähintään yksi Hadoop-klusteri käytössään.

--
sip:t...@tav.iki.fi http://tav.iki.fi

[Tuomas Yrjövuori]

Tapio Väättänen kirjoitti 03.08.2017 klo 13:48:
> Moniajossa useita laskentatehtäviä ajetaan yhden noodin sisällä.
> Rinnakkaislaseknnassa tietysti yhtä laskenta tehtävää suoritetaan usealla
> noodilla.

Näin minäkin olen moniajon ja rinnakkaislaskennan käsitteet sisäistänyt.

Joskus näihin asioihin saatetaan lisäksi "sotkea" DMA versus MMIO,
vaikkeivät nämä täysin suoranaisesti moniajoon liitykään. Joillain
vanhemmilla Linuxin kerneleillä tietyt wifi-kortit eivät kyenneet
toimimaan DMA-tilassa, vaan tiedonsiirto oli muistiosoitepohjaista, mikä
hidasti wifin toimintaa kohtuuttomasti.

En tosin tiedä oliko wifi-korttien toimivuusongelma varsinaisesti
kernelissä vaiko huonosti koodatuissa moduuleissa.

--
Tuomas Yrjövuori

[Reijo Korhonen]

On Thu, 03 Aug 2017 10:29:28 +0300, Tuomas Yrjövuori wrote:

> Reijo Korhonen kirjoitti 03.08.2017 klo 02:26:
>> Mutta jos et googleta, ety tiedä millasia ongelmia muut ovat osanneet
>> mallintaa rinnakkaisiksi tehtäviksi. Tämä ongelma kun ei ole mitenkään
>> triviaali kuten edellisessä viestissäni kuvasin ja framework auttaa
>> toteutuksessa vasta kun mallinnus on osattu tehdä.
>
> Jos ongelma on rinnakkaistettavissa, jonkun täytyy koordinoina ongelman
> palasien jakaminen suorittavien yksiköiden välille. Eräs tapa hoitaa
> asia on antaa ongelman jakaminen käyttöjärjestelmän ja/tai
> käyttöjärjestelmien hoidettavaksi.

Tämä on se tavallisin tapa, mutta se on valitettavan tehoton. Tämä kun ei
nopeuta yksittäistä prosessia, vaan prosessien kokonaisuutta. Näinhän se
on tehty iät ja ajat. Koetetaan saada tiertokoneen resurssit tehokkaastu
yhtä aikaa käyttöön. Kun yklsi ohjelma käyttää IO:ta, niin toinen voi
käyttää prosessoria. Tai prosessoreita tai pikemminkin ytimiä, joita voi
olla vaikkapa kahdeksan. Ytimiä alkaa nyklyprosessoreissa olemaan paljon,
koska kellotaajuutta eui voida enää nostaa. Huomaat mikä on ongelmana.
Meillä pitäisi olla kahdeksanytimisessä koneessa kahdeksdalla ohjelmalla
järkevää tekemistä ytimellä, että konetta käyrtettäisiin tehokkaasti ja
eyyä koneen ostaja saisi vastinetta rahoilleen, kun on ostanut
kahdeksanytimsen koneen luullen sen olevan nopea.

Kunnianbhinoisempi tapa on kuitenkin yrittää nopeuttaa sovellusta. Ja
vain tämä sovellusten nopeutetyuminen on se efekti, joka saisi käyttäjän
huutamaan että jee, nythän se toimii nopeammin. Eli yksi sovellus pitää
osata säikeistää ja saada se käyttämään mahdollimman nontaa ydintä yhtä
aikaa. Ja tässä vaoheessa päädytään siihen minun peräänkuuluttamaani
rinnakkaisten tehtävien mallinnukseen. Yhdestä sovelluksest pitää löytää
tehtäviä, jotka volidaan tehdä yhtä aikaa. Muuten yksi sovellus ei pysty
montaa ydintä hyödyntämään.

> Jos suorittavat yksiköt sattuvat olemaan eri puolilla maailmaa,
> kannattaa varautua ennalta määräämättömiin latensseihin ja jopa
> suorittavien yksiköiden käyttökatkoksiin.

Rinnakkaisia tehtäviä voidaan totta kai jakaa paitsi yhden rpsessorin
sisälly ytimille, mutta tehtävän mittakaavaa muuttamalla tehtävä voidaan
jakaa eri tietokoneille. Tällöin tietenkin tehtä on todellakin oltava
mallinnettu erilaisessa mittakaavassa ja sen riippuvuudet toisista
tehtävistä pitää mioimoida juuri noiden latenssien takia, joka koneiden
välillä netissä on ihanb eri kertaluokkaa kuin säikeiden välinen
kommunikointi keskusmuistin väliyyksellä.

Hallinnointiin pitää kiinnittää huomiota, sillä tehtävän suorittaminen
toisella puolellöa maailmaa saattaa jäädä kesken eli vastausta ei sieltä
tuler järkevässä ajassa. Mitä sitten tehdään? No tuop pitää osata huomata
ja antaa tehtävä sitten jollekin toiselle. Tässä ei periaatteeessa ole
mitään erikoista. Asynkronisiin tehtäviin on aina liitetty tomeoutit.

> Se on sitä
> rinnakkaislaskentaa. Jos ongelma on liukuhihnoitettavissa, kannattaa
> etsiä ongelman kriittinen polku ja kiinnittää siihen erityistä huomiota.

Niinpä. Jos haluat nopeuttaa jotakin ohjelmaa, niin kannattaa tutkia
mihin ohjelma käyttää eniten aikaansa. Kun nopeutetat tätä, nopeutus on
tietenkin vaikutukseltaan suurenpi kuin jos nopeutat jotain, johon
ohjelma käyttää muutenkin hyvin vähän aikaa.

> Jos taas puhutaan moniajosta, siinä resurssien jakamisen merkitys
> korostuu entisestään. Erityisen tärkeää se on silloin, kun järjestelmän
> täytyy pystyä kovaan reaaliaikaisuuteen. Samaan yhteyteen huomauttaisin,
> että myöskään eri puolille maailmaa rinnakkaistetun ongelman ei ole
> mahdotonta pystyä kovaan reaaliaikaisuuteen, vaikka se vaikeaa olisikin.

Kyllä kyllä, mutta en puhuisi samassa lauseessa asynkromisten tehtävien
jakamisesta prosessorin sisällä säiseille ja maailmanlaajuisesti verkon
avulla eri tietokoneille. Mittakaava on täysin eri, jolloin rinnakkaistus
ja mallinnus tehdään ohjelman kerroksissa täysin eri tasoille jas keinot
ja menetelmät ovat tietenkin täysin erilaiset, vaikka periaatteet
olisivatkin samat. Itse asiassa rinnakstgusta voi olla yhtä aikaa
sovelluksen eri kerroksissa eli vaikka tehtävä voidaan jakaa verkossa eri
puolilla maailmaa oleville solmuille, niin nuo solmut voivat ja niiden
totta kai pitäisikin jakaa tehtävä solmun sisällä olesille resursseille
mahdollisimman tehokkaasti. Elikkä niille solmun ytimille rinnakkaisia
hommia.

--
Re...@iki.fi.nospam.invalid
http://www.iki.fi/Reijo

[Reijo Korhonen]

On Thu, 03 Aug 2017 10:48:00 +0000, Tapio Väättänen wrote:

> Jos nyt Hadoopista puhutaan, niin siinähän on ihan oma mallinsa sille,
> kuin etäällä eri noodit ovat toisistaan. Lisäksi, kun data on hajautettu
> eri noodien kesken tasaisesti, niin toisin kuin Reijo väittää, mallinnus
> ei ole useimmiten ongelma ollenkaan, koska HDFS on hajautettu
> tietodostojärjestelmä- Niinpä jokainen noodi käsittelee omilta
> levyiltään löytyvän datan.

Antaudun. Jos et suostu ymmärtämään, että jokainen työ josta odotetaan
tietoneelta tuloksia, on analysoitava, ymmärrettavä ja jaetava tehtäviin
ja osatehtäviin, joilla on riippuvuuksia keskenään. Vain näin tietokone
pystyy tekemään jotain järkevää.

Tämä on täysin eri asia kuin frameworkki, jossa tehtävät ja osatehtävät
voidaan esitten kuvata tietokoneen ymmärtämässä nuodossa kugten eria asia
on myös infrastruktuuri koja nuo tehtävät ja osatehtävät sitten ajaa.

Mutta jos et ymmärrä tätä ja luulet tuiollaisten frameworkkien toimivan
itsestään ja ottavan maailman kaikki ongelmat itsenäisesti rinnakkaiseen
ajoon, niin sillehän minä en voi mitään. Muuta en pyydäkään, kuin että et
mainitse nimeäni yhteyksissä, jousta minä en ole lausunut yhtään mitään.
Jooko? Tapio, jottei jottei väärinkäsityksiä tulisi enempää, en lue enää
viestejäsi joten en enää niihin vastaakaan.


--
Re...@iki.fi.nospam.invalid
http://www.iki.fi/Reijo

[Tapio Vaattanen]

Ehkä sinun kannattaisi itse selvittää mikä Hadoop on.

Ja sitten kun olet sen selvittänyt, niin mieti mitä haasteita siinä on
:)

Tai mikä on Netezza, ja miten se liittyy rinnakkaisuuteen.

--
sip:t...@tav.iki.fi http://tav.iki.fi

"Writing a new OS only for the 386 in 1991 gets you your second 'F' for
this term." -- Prof. Andrew S. Tanenbaum