Suomalainen Flow Computing väittää tekevänsä prosessoreista 100x nopeampia

[Kaakatus]

Suomalaisyhtiön teknologia 100-kertaistaa minkä tahansa tietokoneen prosessorin suorituskyvyn – Keräsi 4 miljoonan rahoituksen

Flow Computingin kehittämä teknologia on yhteensopiva kaikkien nykyisten palvelin-, mobiililaite- ja tietokoneohjelmistojen kanssa.

www.tekniikkatalous.fi

"Yhtiön lisensoima arkkitehtuuri on nimeltään Parallel Processing Unit (PPU). Ohjelmat käännetään PPU:lle, mikä parantaa niiden toiminnallisuutta muuttamatta itse ohjelmistoja. Mitä enemmän PPU-ytimiä integroidaan prosessoriin, sitä enemmän suorituskykyä voidaan myöhemmin parantaa. "

Yhtiön väittämän mukaan heidän teknologiansa voisi kaksinkertaistaa koodin murskaamisen suorituskyvyn ilman koodarien tekemiä optimointeja.
Yhtiö tähtää valmistamisen sijaan teknologiansa lisensoimiseen parnereille, kuten AMD, Apple, Intel, Nvidia tai Qualcomm. Toistaiseksi väittämien taustalla on oikeiden suorittimien sijaan FPGA-demoja ja simulointeja.

Flow Computinigin mukaan PPU yksiköistä voisivat hyötyä niin mobiilisuorittimet kuin supertietokoneetkin. Yhtiön mukaan viimeaikainen kehitys prosessoreissa on ollut hidasta ja niistä on tullut suorituskyvyn heikoin lenkki. PPU:t voisivat parantaa sekä laitteiden akunkestoa, että suorituskykyä siirtämällä laskentaa suorittimelta PPU:lle.

Vergen jutussa mukana firman whitepaper

Did startup Flow Computing just make CPUs 100x faster? Here’s the white paper and FAQs

Read for yourself.

www.theverge.com

 

[hkultala]

Suomalaisyhtiön teknologia 100-kertaistaa minkä tahansa tietokoneen prosessorin suorituskyvyn – Keräsi 4 miljoonan rahoituksen

Flow Computingin kehittämä teknologia on yhteensopiva kaikkien nykyisten palvelin-, mobiililaite- ja tietokoneohjelmistojen kanssa.

www.tekniikkatalous.fi

"Yhtiön lisensoima arkkitehtuuri on nimeltään Parallel Processing Unit (PPU). Ohjelmat käännetään PPU:lle, mikä parantaa niiden toiminnallisuutta muuttamatta itse ohjelmistoja. Mitä enemmän PPU-ytimiä integroidaan prosessoriin, sitä enemmän suorituskykyä voidaan myöhemmin parantaa. "

Vergen jutussa mukana firman whitepaper

Did startup Flow Computing just make CPUs 100x faster? Here’s the white paper and FAQs

Read for yourself.

www.theverge.com

Tuo hype on täyttä roskaa. Olin kuuntelemassa noiden esitelmän pari vuotta sitten ja tyypit olivat totaalisen pihalla
1) siitä, millaista koodia CPUlla normaalisti ajetaan.
2) miten normaalit rinnakkaistusmenetelmät ja koodin optimointimenetelmät toimivat.

Olivat ottaneet pari todella yksinkertaista äärimmäisen hyvin rinnakkaistuvaa workloadia, jotka olivat todella kaukana mistään tosimaailman ohjelmista, ja sitten onnistuivat ne joten kuten rinnakkaistamaan härvelilleen, silloin kun tähtien asento on oikea.

Mutta normaaliin CPUlla suoritettavaan kontrolliorientoituneseen koodin noiden tekniikka ei päde, ja sitä se suorittaa paljon hitaammin kuin normaalit prossut. Ja kun arkkitehtuuri on uusi, ei olemassaolevat binäärit toimi.

Ja mikäli data on esim. vähän huonosti alignoitu, nuo on ongelmissa.

Rautadesignia noilla on nyt ilmeisesti valmiina koska sanovat laittaneensa sen FPGA:lle, mutta vähän veikkaan että niiden FPGA-proto on ziljoona kertaa pienempi versio kuin mitä nuo hypettävät, ja datan reititys ei oikeasti toimisi siinä mittakaavassa kuin mitä nuo hypettävät ja kellotaajuudet isommalla designilla jäisi hyvin heikoiksi.

Ja edelleenkin tuolla whitepaperissa, softat tuntuu olevan samalla tasolla kuin pari vuotta sittenkin, kun katsoo tuota benchmark-settiä, memcopyä ja matriisien yhteenlaskua.

Ei varmuutta että rauta skaalautuu mittoihin mitä hypetetään, ei aja oikeita ohjelmia. Pelkkä lelukoodin ajelua simulaattorissa ja pienen hitaan version ajelua FPGA:lla.

Tuntien sen ammattitaidon mitä esittivät siinä esitelmässään pari vuotta sitten, voisin myös lyödä kohtalaisilla kertoimilla vetoa, että nuo noiden "verrokkibenchmarkit" Intelin prossulle on todella huonosti optimoituja, ja pyörisivät monta kertaa nopeammin kun ne koodaisi järkevästi optimoiden sille Intelin prosulle

edit:

Tuossa noiden tieteellinen paperi, jota itse en todellakaan olisi päästänyt vertaisarvioinnista läpi:

https://www.researchgate.net/journal/The-Journal-of-Supercomputing-1573-0484/publication/353355690_Performance_and_programmability_comparison_of_the_thick_control_flow_architecture_and_current_multicore_processors/links/60f7ae471e95fe241a7a4f6f/Performance-and-programmability-comparison-of-the-thick-control-flow-architecture-and-current-multicore-processors.pdf?_tp=eyJjb250ZXh0Ijp7ImZpcnN0UGFnZSI6InB1YmxpY2F0aW9uIiwicGFnZSI6InB1YmxpY2F0aW9uRG93bmxvYWQiLCJwcmV2aW91c1BhZ2UiOiJfZGlyZWN0In19

<--- ja joo, tuolta löytyi nuo benchmarkit. Intelin prossulla koodi ajettu ilman SIMD-optimointeja aivan kuten arvelinkin.

AVX-512lla tosiaan ajaisi 16aa laskuoperaatiota rinnakkain / käsky, tuossa ajettu vain yhtä.

Lisäksi tuo noiden matriisikertolasku on muutenkin todella huonosti optimoitu, ei mitään unrollausta muistikaistan säästämiseksi ja lisäksi siellä välitulos täysin turhaan tallennetaan joka välissä muistiin, ja käytössä vain yksi välisumma joka estää käskytason rinnakkaisuuden hyödyntämisen, sen sijaan että suoritettaisiin kahta FMA_käskyä rinnakkain, suoritetaan yksi FMA-käsky n. neljän kellojakson välein.

Tuon intel-koodin saisi Intelin prossulla pyörimään n. 100-300 kertaa nopeammin optimoimalla sen järkevästi.



Ja tosiaan kääntäjä niillä on ihan vaporwarea. Lupaavat ihan uuden tason yksisarvikääntäjää, vaikka ovat ihan alkutekijöissään sen kääntäjän suhteen. Käytännössä ovat dunning-krueger-huipulla sen kääntäjän suhteen, ymmärtävät kääntäjistä niin vähän etteivät vielä edes tajua mitä eivät ymmärrä, kun noita lupauksiaan tekevät.

 

[hsalonen]

Tuo hype on täyttä roskaa. Olin kuuntelemassa noiden esitelmän pari vuotta sitten ja tyypit olivat totaalisen pihalla
1) siitä, millaista koodia CPUlla normaalisti ajetaan.
2) miten normaalit rinnakkaistusmenetelmät ja koodin optimointimenetelmät toimivat.

Olivat ottaneet pari todella yksinkertaista äärimmäisen hyvin rinnakkaistuvaa workloadia, jotka olivat todella kaukana mistään tosimaailman ohjelmista, ja sitten onnistuivat ne joten kuten rinnakkaistamaan härvelilleen, silloin kun tähtien asento on oikea.

Mutta normaaliin CPUlla suoritettavaan kontrolliorientoituneseen koodin noiden tekniikka ei päde, ja sitä se suorittaa paljon hitaammin kuin normaalit prossut. Ja kun arkkitehtuuri on uusi, ei olemassaolevat binäärit toimi.

Ja mikäli data on esim. vähän huonosti alignoitu, nuo on ongelmissa.

Rautadesignia noilla on nyt ilmesesti valmiina koska sanovat laittaneensa sen FPGA:lle, mutta vähän veikkaan että niiden FPGA-proto on ziljoona kertaa pienempi versio kuin mitä nuo hypettävät, ja datan reititys ei oikeasti toimisi siinä mittakaavassa kuin mitä nuo hypettävät ja kellotaajuudet isommalla designilla jäisi hyvin heikoiksi.

Ja edelleenkin tuolla whitepaperissa, softat tuntuu olevan samalla tasolla kuin pari vuotta sittenkin, kun katsoo tuota benchmark-settiä, memcopyä ja matriisien yhteenlaskua.

Ei varmuutta että rauta skaalautuu mittoihin mitä hypetetään, ei aja oikeita ohjelmia. Pelkkä lelukoodin ajelua simulaattorissa ja pienen hitaan version ajelua FPGA:lla.

Tuntien sen ammattitaidon mitä esittivät siinä esitelmässään pari vuotta sitten, voisin myös lyödä kohtalaisilla kertoimilla vetoa, että nuo noiden "verrokkibenchmarkit" Intelin prossulle on todella huonosti optimoituja, ja pyörisivät monta kertaa nopeammin kun ne koodaisi järkevästi optimoiden sille Intelin prosulle

edit:

Tuossa noiden tieteellinen paperi, jota itse en todellakaan olisi päästänyt vertaisarvioinnista läpi:

https://www.researchgate.net/journal/The-Journal-of-Supercomputing-1573-0484/publication/353355690_Performance_and_programmability_comparison_of_the_thick_control_flow_architecture_and_current_multicore_processors/links/60f7ae471e95fe241a7a4f6f/Performance-and-programmability-comparison-of-the-thick-control-flow-architecture-and-current-multicore-processors.pdf?_tp=eyJjb250ZXh0Ijp7ImZpcnN0UGFnZSI6InB1YmxpY2F0aW9uIiwicGFnZSI6InB1YmxpY2F0aW9uRG93bmxvYWQiLCJwcmV2aW91c1BhZ2UiOiJfZGlyZWN0In19

<--- ja joo, tuolta löytyi nuo benchmarkit. Intelin prossulla koodi ajettu ilman SIMD-optimointeja aivan kuten arvelinkin.

AVX-512lla tosiaan ajaisi 16aa laskuoperaatiota rinnakkain / käsky, tuossa ajettu vain yhtä.

Lisäksi tuo noiden matriisikertolasku on muutenkin todella huonosti optimoitu, ei mitään unrollausta muistikaistan säästämiseksi ja lisäksi siellä välitulos täysin turhaan tallennetaan joka välissä muistiin, ja käytössä vain yksi välisumma joka estää käskytason rinnakkaisuduen hyödytämisen, sen sijaan että suoritettaisiin kahta FMA_käskyä rinnakkain, suoritetaan yksi FMA-käsky n. neljän kellojakson välein.

Tuon intel-koodin saisi Intelin prossulla pyörimään n. 100-300 kertaa nopeammin optimoimalla sen järkevästi.



Ja tosiaan kääntäjä niillä on ihan vaporwarea. Lupaavat ihan uuden tason yksisarvikääntäjää, vaikka ovat ihan alkutekijöissään sen kääntäjän suhteen. Käytännössä ovat dunning-krueger-huipulla sen kääntäjän suhteen, ymmärtävät kääntäjistä niin vähän etteivät vielä edes tajua mitä eivät ymmärrä, kun noita lupauksiaan tekevät.

Jos katsot tuota noiden paperia, niin siinä on kyllä Forsell kirjoittanut yli kymmenen tutkimuspaperia (alkaen vuodesta 1996), "Thick Control Flows" ollen 2011, että ei ole ihan uusi asia.

En vielä lukenut paperia. Tietotekniikan perusopetukseen yliopistotasolla kuuluivat vielä minun aikanani kääntäjät (ja olin siellä '96 jälkeen) ja olisi kovin outoa , että eivät niitä osaisi edes konseptitasolla. Lisäksi meillä oli Patterson-Hennessy tietokoneen arkkitehtuurissa ja noilla viite #3 on häneltä, niin jotain tutustumista tämäkin signaloi.

Mutta koetin lukea itse paperin; se vaan yleensä on , että lähdeluettelosta saa käsityksen kirjoittajan tietämyksestä ja akateemisen uran pituudesta (kun lainataan omia töitään pisteiden takia).

 

[hkultala]

Jos katsot tuota noiden paperia, niin siinä on kyllä Forsell kirjoittanut yli kymmenen tutkimuspaperia (alkaen vuodesta 1996), "Thick Control Flows" ollen 2011, että ei ole ihan uusi asia.

Tiedän, että kyseessä on pitkän uran tehnyt tutkija, joka on pitkän uransa aikana benchmarkkaillut runsaasti lelubenchmarkkeja.

Tietotekniikkapuolella vaan tutkimus on usein pahasti vieraantunut todellisuudesta, ja tämä porukka on siitä pahimmasta päästä.

Lisäksi käytännössä kaikissa niiden papereissa verrokeissa ei ole käytetty mitään SIMDiä mikä tekee näistä tuloksista ihan epärehellisiä. Hypetetään rinnakkaisuutta ja sitten cripplataan verrokit että niiden tärkeintä rinnakaistusmuotoa ei käytetä ollenkaan.

Käytännössä, tämä porukka on erikoistunut kirjoittamaan hype-papereita, joilla saa rahoitusta tosimaailmassa toimimattomien asioiden tutkimiseen. Josta heillä on paljon kokemusta. Mutta mitään yritystäkään saada näitä asioita toimimaan tosimaailmassa ei tunnu olevan. Melko samat lelubenchmarkit joka paperissa, ja ihan samalla tavalle epärehellisesti cripplataan verrokit joka paperissa.

En vielä lukenut paperia. Tietotekniikan perusopetukseen yliopistotasolla kuuluivat vielä minun aikanani kääntäjät (ja olin siellä '96 jälkeen) ja olisi kovin outoa , että eivät niitä osaisi edes konseptitasolla.

Kyllä kaikki tajuaa sen konseptitason, että kääntäjä ottaa sisään ohjelman korkean tason kielellä, ja tuottaa ulos assemblyä/binäärikoodia, saattaa jopa ymmärtää mitä eroa on kääntäjän frone-endillä ja backendillä, mutta suurella osalla porukasta joka raudan kanssa värkkää ei ole mitään käsitystä siitä miten esim. kääntäjän backendit oikeasti sisäisesti toimivat. Mitä kaikkia vaiheita siellä kääntäjässä pitää olla ja minkälaisia ongelmia on edessä kun yritetään tuottaa hyvin optimoitua koodia.

Esim. kääntäjän backendissä kolme tärkeintä vaihetta on käskynvalinta, rekisteriallokointi ja käskyjen skedulointi. Kaikki ovat jo yksinäänkin optimaalisesti tehtyinä hyvin monimutkaisia vaiheita, mutta käytännössä rekisteriallokointi ja käskyskedulointi molemmat vaikuttavat toisiinsa, ja jos rekisteriallokoinnin tekee ensin, rekisterin välille tulevat valeriippuvuudet rajoittavat pahasti käskyjen skedulointia. Jos taas käskyt skeduloi ensin ja rekisterit allokoi vasta sen jälken, sitten voi tulla tilanne, että rekisterit loppuu kesken ja väliin joudutaan lisäämään spillauskoodia, joka sitten sotkee skeduloidun koodin totaalisesti, hidastaen sitä hyvin merkittävästi.

Käytännössä optimaaliseen tulokseen pääsemiseksi nämä molemmat pitäisi tehdä yhdessä, mutta algoritmi joka tekee molemmat yhdessä tehden molemmat hyvällä laadulla sisältäen paljon optimointeja - algoritmin kompleksisuus räjähtää aivan totaalisesti käsille.

Ja hommaa sotkee vielä tuo käskyjenvalinta - käskyjä skeduloitaessa voi tulla ilmi, että käskyt olisi kannattanut valita toisella tavalla, jos vaikka meillä on yhdessä liukuhihnassa shifteri ja toisessa kertolaskuyksikkö, koodissa joka kertoo paljon lukuja vaikka vakiolla 4, n. puolet kertolaskuista kannattaa muuttaa shiftauskäskyiksi ja puolet pitää kertolaskuina, jolloin voidaan laskea kahta kertolaskua rinnakkain. Mutta mitkä kannattaa valita kertolaskuiksi ja mitkä shiftauksiksi käytännössä selviää vasta siinä vaiheessa, kun sitä käskyä skeduloidaan, että se olisikin pitänyt valita eri käskyksi.


Itse olin edellisessä työpaikassani n. 14 vuotta ja suurin osa työstäni oli kääntäjän backendin optimoimista - ja vuosien optimoinnin jälkeenkään se ei edelleenkään ollut kovin hyvä sieltä lähtiessäni. Kuten ei ollut Intelin Itanium-kääntäjäkään kovin hyvä vaikka Intelillä oli selvästi suurempi määrä taitavaa porukkaa koodaamassa sitä kymmenisin vuotta.

Hyvin optimoivan kääntäjän koodaaminen on vaan niitä oikeasti kaikkein vaikeimpia juttuja tietotekniikassa. Ziljoona hypetettyä "hienoa" prossuarkkitehtuuria on kaatunut siihen, että niiden vaatimaa maagista yksisarvikääntäjää ei koskaan saatu toteutettua. Ja elämään ja menestymään jäi ne prossuarkkitehtuurit, jotka jättävät kääntäjän vastuulle mahdollisimman vähän ja tekevät raudalla mahdollisimman paljon.


Näillä sen sijaan asenne tuntuu olevan se, sen kääntäjän tekeminen on pikkujuttu, ja vasta ihan hiljattain aloitettu parin hengen startupissa, tätä ennen kaikki kodattu assyllä ja porukka on ihan totaalisen pihalla siitä, kuinka vaikeaa se hyvän kääntäjän tekeminen on. Siellä vielä heitetään kaikkea hypeä binäärikäännöksestä ja automaattisesta rinnakkaistuksesta jotka molemmat monimutkaistavat sitä kääntäjää vielä ihan eri dimensioihin.

Mutta koetin lukea itse paperin; se vaan yleensä on , että lähdeluettelosta saa käsityksen kirjoittajan tietämyksestä ja akateemisen uran pituudesta (kun lainataan omia töitään pisteiden takia).

Akateemisen uran pituus ei vaan valitettavasti kerro mitään siitä, kuinka hyvin ymmärtää tosimaailman softien toimintaa. Päin vastoin, sitä pikemminkin vaan vieraantuu todellisuudesta kun vaan harrastaa akateemista puuhastelua lelukoodeilla ilman mitään tulosvastuuta siitä, että oikean tuotantokoodin pitäisi toimia.

 

[hsalonen]

Yleisesti: enpä lähde väittelemään ylläolevasta, kokemukseni aiheepiiristä on rajoittunut opintoihin ja niistä on aikaa
Eikä ollut tarkoitus väitellä, vaan vähän sivistyneesti keskustellen avata tieteellistä paperia ja sen sisältöä.

Näillä sen sijaan asenne tuntuu olevan se, sen kääntäjän tekeminen on pikkujuttu, ja vasta ihan hiljattain aloitettu parin hengen startupissa, tätä ennen kaikki kodattu assyllä ja porukka on ihan totaalisen pihalla siitä, kuinka vaikeaa se hyvän kääntäjän tekeminen on. Siellä vielä heitetään kaikkea hypeä binäärikäännöksestä ja automaattisesta rinnakkaistuksesta jotka molemmat monimutkaistavat sitä kääntäjää vielä ihan eri dimensioihin.

Minua enemmän häiritsee, että heillä ei ole vielä kunnon prototyyppiä, vaan ovat ajaneet tämän vertailun simulaattorilla:

We are also looking possibility to implement TPA on silicon to be able to run real-life benchmarks and to extend comparisons also to energy efficiency

Jäi vähän epäselväksi, että mikä niiden prototyyppi tulee lopulta edes olemaan.. Muutenkin näytti, että se tykkäisi erilaisesta prosessorisuunnittelusta, joka olisi enemmän GPU-mainen (monta yksinkertaista rinnakkaisyksikköä, jolla on pääsy nopeaan muistiin). Olisivat voineet tehdä CUDA-vertailuja, mutta niissä olisi varmaan tullut turpaan

edit: poistin ensimmäisen kommentin, kun katsoin väärää kuvaa, tässä TPA-kuva:

..mutta jos tuo tulee ennen fetch-yksikköä, se on edelleen muistin ja prosessorin välissä.

 

[kuoris]

Hyvät rahoittajat ovat ainakin saaneet. @hkultala kiitos asian avaamisesta selkokielellä.

Nyt vaan odottelemaan että saa omat prosessorit muutettua 100x nopeammaksi!

 

[masax]

Tuolla vergen kommenteissa myös avattu vähän asiaa. Ei kyllä nyt oikein uutinen vakuuta.

 

[hsalonen]

Tuolla vergen kommenteissa myös avattu vähän asiaa. Ei kyllä nyt oikein uutinen vakuuta.

Onkohan Vergen paperi sama, kun siinä on kommenttien mukaan käännetty SIMD pois päältä? Esimerkkinä SIMD-käskykannoista: MMX, AVX. Lisäksi siellä sanottiin, että käsin optimoitu käännös, verrattuna intel-käännettyyn koodin, jota ajettiin macbookilla ja kiellettiin käyttämästä optimoituja käskykantoja..

--

..ja alunperinkin oli ainakin minulle selvää, että tämä on moniajonopeutus. Ei tässä kukaan puhunut, että single threadia saataisiin mitenkään nopeammaksi..

Tämä on @hkultala linkkaamasta paperista:

In the case of matmul, the performance scales relatively well with the number of concurrent threads: A speedup of 9.23 relative to single core is achieved with 18 threads which is 51.3% of the linear speedup. On the contrary, as the number of parallel threads for matsum increases, the performance actually decreases giving a slowdown of a factor of 4.72 with 18 cores.

Eli käytännössä niiden matmul ajoi "9.23 ytimen nopeudella" oikealla, olemassa olevalla 18-ydin Xeonilla ja matsum "4.72 ytimen nopeudella" samalla 18-ytimellä. Ja niiden simulaattorissa päästiin tietenkin paljon parempiin tuloksiin.

--

..mutta joo, kuten @hkultala sanoi, tässä on haasteena kääntäjän tekeminen ja sen lisäksi minun mielestäni vielä kunnon prototyyppiprosessorin luominen, kun tämä ei edelleenkään näytä miltään erilliseltä yksiköltä, vaan on integroitu prosessoriin.

Taitaa pojilla vaan olla liikeideana tuottaa paljon pöhinää ja toivoa, että Intel / AMD ostaa pois ja vie kehityksen loppuun.

 

[hkultala]

Muutamia pointteja vielä:

Kuulin, että kääntäjää tekemään on palkattu yksi ihminen.


Ja keksin mielestäsi hyvän vertauksen tuosta mitä nuo tekee:

Tuo on kuin auto, jossa ei jousitusta, ei vaihdelaatikkoa, 1cm maavara, ja joka pitää työntää käyntiin, mutta sen jälkeen se liikkuu omalla moottorillaan, ja hypetetään sen polttoainetaloudellisuutta.

Jota verrataan siihen, että normaalia henkilöautoa ajetaan vain ykkösvaihteella(koska noiden logiikan mukaan olisi epäreilua ottaa vaihdelaatikko normaalissa autossa käyttöön, koska noillakaan ei sitä ole) (analogia SIMD-käskyjen käyttöön verrokeilla)

 

[jive]

Itselleni tuli mieleen myös IA64 sekä transmetan loppuvaiheen protoilut. Kerrankin ollaan jostain samaa mieltä Kultalan kanssa. En pidättäisi hengitystä sen suhteen että kääntäjä ikinä valmistuu.

 

[hkultala]

Itselleni tuli mieleen myös IA64 sekä transmetan loppuvaiheen protoilut. Kerrankin ollaan jostain samaa mieltä Kultalan kanssa. En pidättäisi hengitystä sen suhteen että kääntäjä ikinä valmistuu.

Itanium ja Transmeta tosin olivat ziljoona kertaa realistisempia arkkitehtuureita kuin tämä, ja niitä markkinoitiin ziljoona kertaa rehellisemmin kuin tätä

Itanium ja Transmeta olisivat kuitenkin olleet nopeita, jos se maaginen yksisarvikääntäjä olisi saatu toimimaan hyvin. Tässä taas sen yksisarvikääntäjänkin kanssa suorituskykyparannushype perustuu kusetukseen, jossa benchmarkeissa verrokkeja cripplataan älyttömästi optimoimalla niiden koodi todella huonosti.

 

[Joosuasd]

Aika hienoltahan tuo kuulostaa. Jos nuin hienoa tekniikkaa olisi itsellä, niin aika visusti pitäisin tiedon myös itselläni. Tarinahan ei kerro, että mitä he ovat esimerkiksi paljastaneet sijoittajille, jotka ovat tuohon mukaan lähteneet. Jos meillä ei ole tarkkaan tiedossa, koko paketin sisältöä, niin voidaan vain arvailla paketin todellista laatua

 

[maajussi]

On niin hienoa ja mullistavaa tekniikkaa, että ties vaikka olisi takana sama "tohtoritason mies" joka täälläkin forumilla haki koodaajaa ja tekijöitä maailmaa mullistavaan startuppiinsa, kunhan vaan uskoo konseptiin ja on aluks valmis tekee työtä melkein ilmaiseksi

 

[Kokkarinen Ville]

hyvä tarkoitus taitaa olla, mutta aika paljon luvattu.

eri asia sitten paljonko tuo tosiaan performanssia pystyy tuomaan tosielämän tilanteissa eikä fantasia benchmarkeissa, jotka rakennettu pelkästään tätä varten.