Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Monisäikeistys androidissa.
11 views
Skip to first unread message
Matti Lehtiniemi
Apr 7, 2013, 12:14:13 AM4/7/13
to
Olen tehnyt parit hyödylliset ohjelmat nettipokeri- käyttöön.
Ne laskee todennäköisyyksiä, ja vaatii hieman laskentakapasiteettia.
Kaikki on koodattu Visual C++ -ohjelmointikielellä.
Ne on ns. tappiin optimoituja, eikä niitä oikeastaan tuon nopeammaksi saa muuta
kuin monisäikeistämällä.
Meikäläistä vaivaa kuitenkin melkoinen moraali-ongelma nettipokerin suhteen enkä
suoraan sanottuna kehtaa tehdä rahaa sillä.Jonkun 100 euroa ehkä tehnyt tuolla
softalla.
Mieleeni tuli kuitenkin että josko uploadais softan Android-marketiin ja
yrittäisi tehdä sillä tavalla rahaa.
Softassa on 2.5 Megatavun taulukko.Taulukon generointi vie 5 minuuttia aikaa C++
:lta.(Core 2 duo 2.13 Ghz)
(Tämä ei ole optimoitu Visual C++:n CThread -luokalla)
Jos konveroitoin softan Androidille ja monisäikeistän sen javan Thread -luokalla
niin saanko tehot ulos ?
Eli osaako Android monisäikeistää myös pikku applettien sisällä ? (eikä
pelkästään sovellusten välillä)
(Siis tarkalleen ottaen Dalvik VM)
Eli jos heitän karkean arvion että 1 ghz Android suoriutuu 10 minuutissa
taulukkoni generoinnista niin käykö niin että 4-ytiminen Android suoriutuu siitä
2.5 minuutissa ? (neljäsosalla ajasta)
Tässä on meinaan kaupalliselta kannalta todella iso ero,meneekö siihen 2-3
minuuttia vai 10 minuuttia koska ihmiset ovat nyk. niin lyhytpinnaisia.
Käytössä itselläni hyväksi koettu ZTE Blade Android-puhelin. Eclipseä olen
joskus käyttänyt Java-ohjelmointiin.
Yhtään Android-ohjelmaa en ole vielä tehnyt.
Sen olen lukenut että Eclipseen saa Android-pluginin.
Matti
Ne laskee todennäköisyyksiä, ja vaatii hieman laskentakapasiteettia.
Kaikki on koodattu Visual C++ -ohjelmointikielellä.
Ne on ns. tappiin optimoituja, eikä niitä oikeastaan tuon nopeammaksi saa muuta
kuin monisäikeistämällä.
Meikäläistä vaivaa kuitenkin melkoinen moraali-ongelma nettipokerin suhteen enkä
suoraan sanottuna kehtaa tehdä rahaa sillä.Jonkun 100 euroa ehkä tehnyt tuolla
softalla.
Mieleeni tuli kuitenkin että josko uploadais softan Android-marketiin ja
yrittäisi tehdä sillä tavalla rahaa.
Softassa on 2.5 Megatavun taulukko.Taulukon generointi vie 5 minuuttia aikaa C++
:lta.(Core 2 duo 2.13 Ghz)
(Tämä ei ole optimoitu Visual C++:n CThread -luokalla)
Jos konveroitoin softan Androidille ja monisäikeistän sen javan Thread -luokalla
niin saanko tehot ulos ?
Eli osaako Android monisäikeistää myös pikku applettien sisällä ? (eikä
pelkästään sovellusten välillä)
(Siis tarkalleen ottaen Dalvik VM)
Eli jos heitän karkean arvion että 1 ghz Android suoriutuu 10 minuutissa
taulukkoni generoinnista niin käykö niin että 4-ytiminen Android suoriutuu siitä
2.5 minuutissa ? (neljäsosalla ajasta)
Tässä on meinaan kaupalliselta kannalta todella iso ero,meneekö siihen 2-3
minuuttia vai 10 minuuttia koska ihmiset ovat nyk. niin lyhytpinnaisia.
Käytössä itselläni hyväksi koettu ZTE Blade Android-puhelin. Eclipseä olen
joskus käyttänyt Java-ohjelmointiin.
Yhtään Android-ohjelmaa en ole vielä tehnyt.
Sen olen lukenut että Eclipseen saa Android-pluginin.
Matti
Matti Lehtiniemi
Apr 7, 2013, 7:23:59 AM4/7/13
to
> Jos konveroitoin softan Androidille ja monisäikeistän sen javan
> Thread -luokalla niin saanko tehot ulos ?
Ainakin tuon mukaan:
> Thread -luokalla niin saanko tehot ulos ?
http://www.slideshare.net/coolmirza143/multithreading-in-android
"
Particularly useful in the case of a single process that spawns multiple threads
ontop of a multiprocessor system.In this case real parallelism is
achieved.Consequently,a multithreaded program operates faster on computer
systems that have multiple CPUs."
Siis ihan peruskauraa, implementoidaan Runnable ja sitten ajetaan Thread.Start()
?
Tai vaihtoehtoisesti periytetään Thread -luokasta.
Voiko tuohon slide-show:hun luottaa ? onko se oikeasti noin ?
Entä mites 2.5 Megatavun taulukko ? Pystyyko Android java Dalvik VM siihen ?
Alkaako ARM -prossun välimuistipuskuri trashäämään jos monta säiettä kirjoittaa
samaan aikaan muistiin vai osaako se sopivasti antaa oman lohkonsa jokaiselle
säikeelle ?
2.5 Megatavua mahtuu core2-duo:n L2-välimuistiin mutta ei varmaakaan
ARM -prossan välimuistiin ?
Matti
Martti Mäkelä
Apr 7, 2013, 2:22:42 PM4/7/13
to
On 04/07/2013 02:23 PM, Matti Lehtiniemi wrote:
>
> Siis ihan peruskauraa, implementoidaan Runnable ja sitten ajetaan
> Thread.Start() ?
> Tai vaihtoehtoisesti periytetään Thread -luokasta.
Jep. Mahdollinen synkronointitarve hoidetaan panemalla synchronize (+
>
> Siis ihan peruskauraa, implementoidaan Runnable ja sitten ajetaan
> Thread.Start() ?
> Tai vaihtoehtoisesti periytetään Thread -luokasta.
objekti jos lukkona ei ole this) koodiblokin eteen. Joskaan taulukon
alustamisessa synkronointia ei tarvinne muuhun kuin mahdollisesti
valmistumisen tarkistamiseen.
Dalvik toteutuksen tehokkuudesta en osaa sanoa.
--
Teuvo Hakkarainen presidentiksi
Matti Lehtiniemi
Apr 8, 2013, 1:01:41 AM4/8/13
to
> Jep. Mahdollinen synkronointitarve hoidetaan panemalla synchronize (+ objekti
> jos lukkona ei ole this) koodiblokin eteen. Joskaan taulukon
Tässä tapauksessa ei tarvitse synchronized.Jokainen säikeistä kirjoittaa eri
> jos lukkona ei ole this) koodiblokin eteen. Joskaan taulukon
kohtaan taulukkoa eikä mikään säie ole lukemassa taulukkoa.Säikeet eivät
tarvitse muuta dataa kuin taulukon pointterin joka ei muutu.
(Eikä myöskään taulukon koko muutu joten sitäkään dataa ei tarviste lukita
syncronized)
Mietin tuota välimuistien toimintaa.Kaikki taulukon muodostava data sijaitsee
koodissa ,eli muistia ei lueta ollenkaan taulukkoa luotaessa.Itse koodi mahtuu
koodi-cacheen.
4 säiettä kirjoitaa ensin jokainen omiin L1 -data -cacheihinsä. Sitten prossa
varmaankin siirtää ne tietyn datamäärän täytyttyä L2 :een .Ja sitten siitä itse
päämuistiin.
Koska mikään säie ei lue päämuistia, ei sitä tarvitse päivittää välimuisteista
(L1 ,L2) ollenkaan.
Eli kaiken järjen mukaan pitäisi nopeuden oikeasti 4-kertaistua 4:ää säiettä
käyttämällä.
Tai ainakin nopeutuisi ellei Dalvik VM käyttäisi niin montaa omaa säiettänsä
välimuisteja trashäämässä ?
(Mitä mä luin siinä on useampi oma säie per ohjelma)
Näyttäisi olevan aika tykki tämä uusi ARM: 40% nopeuslisäystä ed. sukupolveen
verrattuna.
http://en.wikipedia.org/wiki/ARM_Cortex-A15_MPCore
Matti
Jouko Holopainen
Apr 8, 2013, 8:25:04 AM4/8/13
to
En ota kantaa Androidin moniprosessoritukeen enkä ehdota parempaa
vaihtoehtoa, Mutta minusta jotenkin tuntuu siltä, että jos muutaman
(tuhannen?) todennäköisyyden laskeminen kestää minuuttitolkulla on
algoritmi väärä.
--
@jhol
www.iki.fi/jhol
vaihtoehtoa, Mutta minusta jotenkin tuntuu siltä, että jos muutaman
(tuhannen?) todennäköisyyden laskeminen kestää minuuttitolkulla on
algoritmi väärä.
--
@jhol
www.iki.fi/jhol
Matti Lehtiniemi
Apr 8, 2013, 10:18:21 AM4/8/13
to
> vaihtoehtoa, Mutta minusta jotenkin tuntuu siltä, että jos muutaman
> (tuhannen?) todennäköisyyden laskeminen kestää minuuttitolkulla on
> algoritmi väärä.
Kirjoitin hieman heikosti. Sitä taulukkoa tarvitaan siihen,että tod.näk.
> (tuhannen?) todennäköisyyden laskeminen kestää minuuttitolkulla on
> algoritmi väärä.
laskeminen muuttuu huippunopeaksi.
Se lasketaan siis vain kerran.
Tietysti sen voisi kytkeä valmiina siihen ohjelmaan.
2.5 Megatavua on siitä hassua että se 2G puhelintiedonsiirrossa erittäin paljon,
3G:ssä jonkin verran ja 4G:ssä erittäin vähän.
En tiedä miten paljon se on google-play ajattelumaailmassa.
Matti
Anssi Saari
Apr 9, 2013, 11:05:21 AM4/9/13
to
"Matti Lehtiniemi" <matti.le...@remove-me.kolumbus.fi> writes:
> Tietysti sen voisi kytkeä valmiina siihen ohjelmaan.
> 2.5 Megatavua on siitä hassua että se 2G puhelintiedonsiirrossa
> erittäin paljon, 3G:ssä jonkin verran ja 4G:ssä erittäin vähän.
> En tiedä miten paljon se on google-play ajattelumaailmassa.
Hm. Firefox = 11 MB. BeyondPod 5 MB. K-9 Mail = 3,4 MB. Pakattuna
> Tietysti sen voisi kytkeä valmiina siihen ohjelmaan.
> 2.5 Megatavua on siitä hassua että se 2G puhelintiedonsiirrossa
> erittäin paljon, 3G:ssä jonkin verran ja 4G:ssä erittäin vähän.
> En tiedä miten paljon se on google-play ajattelumaailmassa.
asennuspakettina siis.
Isommat pelit on satoja megatavuja. En ressaisi pienen taulukon viemän
tilan takia varsinkin jos se vielä pakkautuu.
Petteri Kangaslampi
Apr 9, 2013, 1:27:50 PM4/9/13
to
"Matti Lehtiniemi" <matti.le...@remove-me.kolumbus.fi> writes:
> Softassa on 2.5 Megatavun taulukko.Taulukon generointi vie 5 minuuttia
> aikaa C++ :lta.(Core 2 duo 2.13 Ghz)
> (T�m� ei ole optimoitu Visual C++:n CThread -luokalla)
> Softassa on 2.5 Megatavun taulukko.Taulukon generointi vie 5 minuuttia
> aikaa C++ :lta.(Core 2 duo 2.13 Ghz)
> Jos konveroitoin softan Androidille ja monis�ikeist�n sen javan Thread
> -luokalla niin saanko tehot ulos ?
> Eli osaako Android monis�ikeist�� my�s pikku applettien sis�ll� ?
> (eik� pelk�st��n sovellusten v�lill�)
> (Siis tarkalleen ottaen Dalvik VM)
Androidiin on my�s Native Development Kit, jolla
suorituskykykriittisen osan voi tehd� edelleen C++:lla eik� sit�
tarvitse muuttaa Javaksi. Java- ja C-maailman yhteensovittamisessa on
hieman tekemist� mutta ei se mahdottoman vaikeaa ole.
Toinen vaihtoehto on tosiaan toimittaa taulukko valmiina sovelluksen
mukana kuten ehdotettiin, varsinkin jos se pakkautuu. Ensit�ikseen
kannattaa vain kirjoittaa taulukko softasta ulos ja katsoa mink�
kokoinen zip-paketti siit� tulisi...
Petteri
Matti Lehtiniemi
Apr 9, 2013, 2:25:30 PM4/9/13
to
> Androidiin on my�s Native Development Kit, jolla
> suorituskykykriittisen osan voi tehd� edelleen C++:lla eik� sit�
Eli Androidissa on menty siihen ,ett� ARM on oikeasti liitetty Androidiin.
> suorituskykykriittisen osan voi tehd� edelleen C++:lla eik� sit�
Mun mielest� alkuaikoina ei ollut niin, ett� Android olisi ollut ARM -kytketty.
Joku tuollainen sielt� my�s l�ytyy:
Jazelle RCT for JIT compilation.
http://en.wikipedia.org/wiki/ARM_Cortex-A15_MPCore
Jotain absoluuttista tehostusta Javaan ?
"Jazelle DBX (Direct Bytecode eXecution) is a technique that allows Java
Bytecode to be executed directly in the ARM architecture as a third execution
state (and instruction set) alongside the existing ARM and Thumb-mode."
Matti
Jussi Hagman
Apr 10, 2013, 6:41:43 AM4/10/13
to
Matti Lehtiniemi <matti.le...@remove-me.kolumbus.fi> provided the following
for the eyes of sfnet.atk.ohjelmointi:
käynnistyksen jälkeen. Ihmisillä on odotusarvo, että internet voi olla
hidas, mutta kun he starttaavat softan ensimmäistä kertaa on hyvä jos
siinä ei tarvitse odotella laskentaa.
Ja kuten aiempi postaaja sanoi, 2.5MB ei ole paljon mitään suhteessa
nykyisten softien kokoon.
--
Jussi Hagman, jhagman ÄT infa.fi
for the eyes of sfnet.atk.ohjelmointi:
>
> Tietysti sen voisi kytkeä valmiina siihen ohjelmaan. 2.5 Megatavua on
> siitä hassua että se 2G puhelintiedonsiirrossa erittäin paljon, 3G:ssä
> jonkin verran ja 4G:ssä erittäin vähän. En tiedä miten paljon se on
> google-play ajattelumaailmassa.
Mielummin sen muutaman minuutin odottaa kun softa ladataan kuin
> Tietysti sen voisi kytkeä valmiina siihen ohjelmaan. 2.5 Megatavua on
> siitä hassua että se 2G puhelintiedonsiirrossa erittäin paljon, 3G:ssä
> jonkin verran ja 4G:ssä erittäin vähän. En tiedä miten paljon se on
> google-play ajattelumaailmassa.
käynnistyksen jälkeen. Ihmisillä on odotusarvo, että internet voi olla
hidas, mutta kun he starttaavat softan ensimmäistä kertaa on hyvä jos
siinä ei tarvitse odotella laskentaa.
Ja kuten aiempi postaaja sanoi, 2.5MB ei ole paljon mitään suhteessa
nykyisten softien kokoon.
--
Jussi Hagman, jhagman ÄT infa.fi
Akseli M�ki
Apr 10, 2013, 1:40:47 PM4/10/13
to
Matti Lehtiniemi wrote:
>Softassa on 2.5 Megatavun taulukko.Taulukon generointi vie 5 minuuttia aikaa C++
>:lta.(Core 2 duo 2.13 Ghz)
>(T�m� ei ole optimoitu Visual C++:n CThread -luokalla)
>Softassa on 2.5 Megatavun taulukko.Taulukon generointi vie 5 minuuttia aikaa C++
>:lta.(Core 2 duo 2.13 Ghz)
>Jos konveroitoin softan Androidille ja monis�ikeist�n sen javan Thread -luokalla
>niin saanko tehot ulos ?
Core2duo on huomattasti mobiiliprosessoreja tehokkaampi per kellojakso (per
ydin).
Tuossa on jonkimmoinen taulukko. Nuo on vaan niin erilaisia ett�
kunnollinen vertailu on hankalaa.
https://en.wikipedia.org/wiki/Instructions_per_second
>Eli jos heit�n karkean arvion ett� 1 ghz Android suoriutuu 10 minuutissa
T�ll� viittaat ilmeisesti tuohon omaan k�nnykk��si jossa on ilmeisesti
huomattasti hitaampi Cortex-A5, niin sill� menisi kyll� jotain 15-20
minuuttia. (ZTE Blade II)
>taulukkoni generoinnista niin k�yk� niin ett� 4-ytiminen Android suoriutuu siit�
>2.5 minuutissa ? (nelj�sosalla ajasta)
Taulukon mukaan menisi ehk� tuplasti enemm�n, tai enemm�n. (neliytimiselt�
Cortex-A9 1,4 GHz kuten Samsung Galaxy S III)
Mainittu uusin Cortex-A15 on tuota nopeampi.
Matti Lehtiniemi
Apr 11, 2013, 2:02:22 AM4/11/13
to
> Core2duo on huomattasti mobiiliprosessoreja tehokkaampi per kellojakso (per
> ydin).
Oletko varma ?
> ydin).
Aikanaan Commodore 64:ssa oli moni k�sky 1 kellojakso/k�sky ja Z80 /
086 -arkkitehtuurissa sama k�sky oli 4 kellojaksoa, jolloin 1 Mhz kuusnepa
toimi yht� nopeasti monissa teht�viss� kuin 4.77 Mhz Z80 -prossa.
Kun ensimm�inen ARM -prossa tuli (1987 ?) , niin mun muistini mukaan Acorn
Archimedes koneesta puhuttiin ett� se on RISC -kone, eli suorittaa monet k�skyt
1 kellojaksossa.
En ole sen tarkemmin tutkinut ARM -prossia,mutta jos olen oikein ymm�rt�nyt niin
siin� on paljon rekistereit� ja nopeat k�skyt.
Core 2 duo varmasti j�rjestelee k�skyj� ja suorittaa niit� samaan aikaan ,mutta
eik�s niin tee my�s ARM ?
> https://en.wikipedia.org/wiki/Instructions_per_second
Tietysti jos nopeuteen pyrit��n ,koodataan vain C/C++:lla.
Javassa ongelmia aiheuttaa olioiden luominen ja roskienkeruu.Olen lukenut ett�
peliohjelmoijat k�ytt�v�t ns.oliofarmeja javassa, eli olioita ei ollenkaan
luoda/tuhota pelisilmukassa.
Se mik� t�ss� olisi mielenkiintoista tiet�� on se, ett� toimiiko v�limuistit ja
miten.
Voinko todella luottaa siihen,ett� jos kirjoitan eri s�ikeill� eri kohtiin
taulukkoa ett� L2 cache ei ala trashaam��n.
Eli miten �lykk��sti nuo v�limuistit on toteutettu ?
Matti
Jukka Marin
Apr 11, 2013, 2:25:44 AM4/11/13
to
On 2013-04-11, Matti Lehtiniemi <matti.le...@remove-me.kolumbus.fi> wrote:
>> Core2duo on huomattasti mobiiliprosessoreja tehokkaampi per kellojakso (per
>> ydin).
>
> Oletko varma ?
> Aikanaan Commodore 64:ssa oli moni k�sky 1 kellojakso/k�sky ja Z80 /
> 086 -arkkitehtuurissa sama k�sky oli 4 kellojaksoa, jolloin 1 Mhz kuusnepa
> toimi yht� nopeasti monissa teht�viss� kuin 4.77 Mhz Z80 -prossa.
C64:ss� ei yksik��n k�sky mennyt yhdess� kellojaksossa. Nopeimmat veiv�t 2
>> Core2duo on huomattasti mobiiliprosessoreja tehokkaampi per kellojakso (per
>> ydin).
>
> Oletko varma ?
> Aikanaan Commodore 64:ssa oli moni k�sky 1 kellojakso/k�sky ja Z80 /
> 086 -arkkitehtuurissa sama k�sky oli 4 kellojaksoa, jolloin 1 Mhz kuusnepa
> toimi yht� nopeasti monissa teht�viss� kuin 4.77 Mhz Z80 -prossa.
kelloa, hitaimmat muistaakseni 7 kelloa. Z80:st� en muista, kun en sit�
ole juurikaan k�ytt�nyt.
-jm
Matti Lehtiniemi
Apr 11, 2013, 3:17:54 AM4/11/13
to
> C64:ss� ei yksik��n k�sky mennyt yhdess� kellojaksossa. Nopeimmat veiv�t 2
Niin se toinen kellojakso tulee siit� kun k�sky haetaan muistista.Itse suoritus
vie 1 kellojakson.
Matti
Jukka Marin
Apr 11, 2013, 3:42:07 AM4/11/13
to
On 2013-04-11, Matti Lehtiniemi <matti.le...@remove-me.kolumbus.fi> wrote:
niin jokaisen suoritus kaikkineen vie 2 kelloa eli vajaan 1 megan kellolla
(jolla C64 py�rii) CPU suorittaa alle 500000 k�sky� sekunnissa.
-jm
Matti Lehtiniemi
Apr 11, 2013, 4:32:25 AM4/11/13
to
> Ihan miten haluat ajatella, mutta jos ladot nopeimpia k�skyj� per�kk�in,
> niin jokaisen suoritus kaikkineen vie 2 kelloa eli vajaan 1 megan kellolla
> (jolla C64 py�rii) CPU suorittaa alle 500000 k�sky� sekunnissa.
Noinhan se tietysti on.
> niin jokaisen suoritus kaikkineen vie 2 kelloa eli vajaan 1 megan kellolla
> (jolla C64 py�rii) CPU suorittaa alle 500000 k�sky� sekunnissa.
Tuli ihan vanhat ajat mieleen t�st�. Muistan lukeneeni artikkeleitasi C-lehdest�
ja Mikrobitist�.
Kaveri , jonka kanssa keskustelin Z80:sta julkaisi pelin mikrobitiss�:
http://www.devili.iki.fi/library/author/733.en.html
H�nell� oli Spectrum ja mulla C64. Kyll� olin kateellinen kun h�n sai mit� 600
mk mik� oli iso raha siihen aikaan.
Matti Lehtiniemi
Anssi Saari
Apr 15, 2013, 9:48:15 AM4/15/13
to
"Matti Lehtiniemi" <matti.le...@remove-me.kolumbus.fi> writes:
>> Androidiin on my�s Native Development Kit, jolla
>> suorituskykykriittisen osan voi tehd� edelleen C++:lla eik� sit�
>
> Eli Androidissa on menty siihen ,ett� ARM on oikeasti liitetty Androidiin.
> Mun mielest� alkuaikoina ei ollut niin, ett� Android olisi ollut ARM -kytketty.
Ei se olekaan pelk�st��n ARM-kytketty, NDK tukee muitakin prossuja,
>> Androidiin on my�s Native Development Kit, jolla
>> suorituskykykriittisen osan voi tehd� edelleen C++:lla eik� sit�
>
> Eli Androidissa on menty siihen ,ett� ARM on oikeasti liitetty Androidiin.
> Mun mielest� alkuaikoina ei ollut niin, ett� Android olisi ollut ARM -kytketty.
ainakin Mips ja
x86. http://developer.android.com/tools/sdk/ndk/overview.html
> "Jazelle DBX (Direct Bytecode eXecution) is a technique that allows
> Java Bytecode to be executed directly in the ARM architecture as a
> third execution state (and instruction set) alongside the existing ARM
> and Thumb-mode."
silmiss�. Muistelen ett� siit� vaahdottiin josku 10 vuotta sitten
ARM11:n hienoutena... Ongelma on ett� se ei nopeuta Dalvikin tavukoodia
p�tk��k��n. Eik� p�rj�� ilmeisesti edes JITille tavallisen tavukoodin
kanssa....
http://stackoverflow.com/questions/1153076/does-android-castrate-the-arms-jazelle-technology
Matti Lehtiniemi
Apr 15, 2013, 10:54:53 AM4/15/13
to
> Ei se olekaan pelk�st��n ARM-kytketty, NDK tukee muitakin prossuja,
> ainakin Mips ja
> x86. http://developer.android.com/tools/sdk/ndk/overview.html
Mietin vaan miten se k�yt�nn�ss� on.Jos mulla on x86 j�rjestelm�ss� Android,
> ainakin Mips ja
> x86. http://developer.android.com/tools/sdk/ndk/overview.html
niin voinko ostaa esim
Angry Birdsin googlen play -kaupasta ?
Vai kyyk��kk� se siihen ett� osa pelist� on tehty ARM:lle ?
Eli onko mit��n osia play -kaupan peleist� vain ARM:lle ja jos on, niin onko
siit� erillinen merkint� pelin oston yhteydess� ?
Matti
Anssi Saari
Apr 17, 2013, 3:28:31 AM4/17/13
to
yhteensopivuudelle mutta usein se vaikuttaa l�hinn�
kiusanteolta. Esim. talvilomakohteen Android-sovellus ei muka sopinut
tablettiini mutta kuitenkin asentui ja toimi ongelmitta. Toki siin� ei
mit��n tablettik�ytt�liittym�� ollut mutta eip� haitannut.
Ainoa ohjelma mink� tied�n erikseen kehuvan yhteensopivuutta eri
alustoilla on Titanium Backup mutta en toisaalta tied� onko siin�
natiivikoodia. Varmistusten salaukseen voisi tietysti olla.
Akseli Mäki
Apr 23, 2013, 11:51:42 AM4/23/13
to
Matti Lehtiniemi wrote:
>Mietin vaan miten se käytännössä on.Jos mulla on x86 järjestelmässä Android,
>Eli onko mitään osia play -kaupan peleistä vain ARM:lle ja jos on, niin onko
>siitä erillinen merkintä pelin oston yhteydessä ?
Luulis että Androidin kehitystyökalut pystyvät vääntämään sen mihin
tahansa, varsinkin kun tärkein on ARM ja x86 on sitä huomattasti laajempi
ja nopeampi.
Eri asia jos yritettäisiin toisinpäin, vääntää vaikka 64 bittiselle
Windowsille tehtyä ohjelmaa ARM pohjaiselle Androidille. Vois olla aika
hiljaista ruveta vääntämään tarvittavia Windowsin alikirjastoja
Androidille, tai kirjoittaa uusiksi koko ohjelmaa niin ettei se käytä
mitään Windowsin kirjastoja.
>Mietin vaan miten se käytännössä on.Jos mulla on x86 järjestelmässä Android,
>niin voinko ostaa esim
>Angry Birdsin googlen play -kaupasta ?
>Vai kyykääkkö se siihen että osa pelistä on tehty ARM:lle ?
>Angry Birdsin googlen play -kaupasta ?
>Eli onko mitään osia play -kaupan peleistä vain ARM:lle ja jos on, niin onko
>siitä erillinen merkintä pelin oston yhteydessä ?
Luulis että Androidin kehitystyökalut pystyvät vääntämään sen mihin
tahansa, varsinkin kun tärkein on ARM ja x86 on sitä huomattasti laajempi
ja nopeampi.
Eri asia jos yritettäisiin toisinpäin, vääntää vaikka 64 bittiselle
Windowsille tehtyä ohjelmaa ARM pohjaiselle Androidille. Vois olla aika
hiljaista ruveta vääntämään tarvittavia Windowsin alikirjastoja
Androidille, tai kirjoittaa uusiksi koko ohjelmaa niin ettei se käytä
mitään Windowsin kirjastoja.
Matti Lehtiniemi
Apr 23, 2013, 12:32:18 PM4/23/13
to
> Luulis että Androidin kehitystyökalut pystyvät vääntämään sen mihin
> tahansa, varsinkin kun tärkein on ARM ja x86 on sitä huomattasti laajempi
> ja nopeampi.
Androidin Dalvik VM:hän on rekisteri-pohjainen ja ARM:ssa on paljon rekistereitä
> tahansa, varsinkin kun tärkein on ARM ja x86 on sitä huomattasti laajempi
> ja nopeampi.
joten se sopii jopa paremmin kun x86.
Jos joku peli on vaikka google playssa joka käyttää Open GL ES:ää niin se Open
GL ES pitäisi saada sovitettua X86 Linux:iin.
Aika vaikeata-- muistelisin jotenkin ettei Linuxissa ole 3D ajureita vaan ne on
X-Windowsissa.
(Tosin tietoni ovat vanhoja)
Älykäs ihminenhän tekisi pelin ThinBasicilla ja sitten pelin valmistuttua
porttaisi sen Androidille.
Androidissa on Open GL ES ja ThinBasicissa Open GL.
(Nyt kun tämä peli-teollisuus on niin suosittua Suomessa)
Olen suunnittellut Raspberry PI:n ostamista varakoneeksi. Enpä tiedä, vähän
turhan vanha prossu siinä...
Pitäisi vielä saada selville toimiiko Pokerstarsin Android-versio siinä.
Matti
Jussi Hagman
Apr 23, 2013, 12:35:54 PM4/23/13
to
Akseli Mäki <akseli.n...@saunalahti.fi> provided the following
sirusta puhutaan.
Nopeimmat läppäreiden x86-sirut ovat 10x nopeampia kuin tyypillinen ARM,
mutta toisaalta nopeimmat ARM-sirut kilpailevat puhtaalla nopeudellakin
todella kovasti erinäisten Atom-sirujen kanssa.[1] Perinteisesti ARM on
suhteellisen hitauden vastapainoksi tarjonnut pientä virrankulutusta ja
lämmöntuottoa, Intel taasen perinteisesti ei.
Voisi sanoa että sekä Intel että ARM-pohjaiset sirut lähestyvät samaa
optimia eri suunnista.
[1] http://www.anandtech.com/show/6695/microsoft-surface-pro-review/5
for the eyes of sfnet.atk.ohjelmointi:
>
>
> Luulis että Androidin kehitystyökalut pystyvät vääntämään sen mihin
> tahansa, varsinkin kun tärkein on ARM ja x86 on sitä huomattasti
> laajempi ja nopeampi.
*Voi* olla huomattavasti nopeampi. Riippuu mistä Intelin ja ARM:n
> tahansa, varsinkin kun tärkein on ARM ja x86 on sitä huomattasti
> laajempi ja nopeampi.
sirusta puhutaan.
Nopeimmat läppäreiden x86-sirut ovat 10x nopeampia kuin tyypillinen ARM,
mutta toisaalta nopeimmat ARM-sirut kilpailevat puhtaalla nopeudellakin
todella kovasti erinäisten Atom-sirujen kanssa.[1] Perinteisesti ARM on
suhteellisen hitauden vastapainoksi tarjonnut pientä virrankulutusta ja
lämmöntuottoa, Intel taasen perinteisesti ei.
Voisi sanoa että sekä Intel että ARM-pohjaiset sirut lähestyvät samaa
optimia eri suunnista.
[1] http://www.anandtech.com/show/6695/microsoft-surface-pro-review/5
0 new messages