Mikä kieli ja/tai kehitysväline foorumialustan ohjelmointiin?

Avaajalle vaan sinolia, kun ei osaa mitään koodata.

Anonyymi kirjoitti:

Avaajalle vaan sinolia, kun ei osaa mitään koodata.

Hyvin humaloitua olutta mieluummin, kiitos!

Riippuu mitä osaamisella tarkoitetaan. Aloitin 80-luvulla useammalla BASIC-murteella, mukana myös Amstrad-PC:n mukana tullut graafisessa ympäristössä toimiva Locomotive BASIC. Sitten siirryin askeettisempaan merkkipohjaiseen ohjelmointiin C-kielellä. Seuraavaksi opiskelin tutkinnon, jossa opetuskielenä oli vanha perinteinen Pascal. Sitten palasin graafiseen ohjelmointiin, nyt Delphin avulla (moderni versio Pascalista). Sitten taas opiskelemaan ja nyt opetuskielenä oli Java vuosituhannen vaihteessa.

Ai niin, oli välissä joskus 90-luvulla yksi olio-ohjelmointikurssi tulkkipohjaisessa graafisessa ympäristössä, joka ei jäänyt mieleeni (olisikohan ollut Eiffel). Enpä tullut kurssilta hullua hurskaammaksi.

Yliopisto-opintoni venyivät sen verran pitkiksi että on tullut useamman vuosikymmenen aikana seurattua alaa, mutta varsinaisesti ohjelmoijana/ohjelmistosuunnittelijana en ole työskennellyt. Omat kaupalliset ohjelmani tein jo ennen varsinaista alan opiskelua (yrittäjänä). Käytännön ohjelmointi ei vaan innosta, siis jatkuva tietojen metsästys ja kaivelu. Ennen oli paremmin kun ohjelmistovälineiden (kieli + rajapinnat) dokumentaatio mahtui kirjaan, opetteli välineen käytön ja alkoi sen jälkeen naputtelemaan koodia. Toki suunnitella piti ensin ja siihen mulla on tupannut projektini tyssätä kun ei enää ole toteuttaminen innostanut. :)

Suorituskyvystä:

1. Tehdään Javalla: Tarvitaan useita palvelimia ja kuormantasausjärjestelmä. Ja yksittäinen käyttäjä voi silti joutua odottelemaan.

2. Tehdään Delphillä: 1 palvelin riittää niin kauan, kun palvelua ei käytetä rikollisella tavalla (tässä viitataan erityisesti rikoslain pykälään "Tietoliikenteen häirintä").
Delphin suorituskyky on niin ylivoimainen, että useita palvelimia tai kuormantasausjärjestelmää ei tarvita.

Anonyymi kirjoitti:

Suorituskyvystä:

1. Tehdään Javalla: Tarvitaan useita palvelimia ja kuormantasausjärjestelmä. Ja yksittäinen käyttäjä voi silti joutua odottelemaan.

2. Tehdään Delphillä: 1 palvelin riittää niin kauan, kun palvelua ei käytetä rikollisella tavalla (tässä viitataan erityisesti rikoslain pykälään "Tietoliikenteen häirintä").
Delphin suorituskyky on niin ylivoimainen, että useita palvelimia tai kuormantasausjärjestelmää ei tarvita.

Lue lisää

"Delphin suorituskyky on niin ylivoimainen, että useita palvelimia tai kuormantasausjärjestelmää ei tarvita."

Höpöhöpö.

Useampi palvelin tarvitaan mikäli halutaan vikasietoisuutta.

Sen lisäksi et selvästikään ymmärrä, että jos jotain foorumia tekee niin suorituskyvyn kannalta kriittisintä on se miten toteuttaa tietokannan. Joku service hakee kannasta tai tekee postauksia on tässä hyvin yksinkertainen.

Oman asiansa tekee tietenkin se, että halutaanko foorumipostausten näkyvän vaikka hakutuloksissa jolloin olisi hyvä tietenkin renderöidä näkymä palvelimella Tämäkään ei ole vaativaa.

Mutta sitten kun siinä kokonaisuudessa on autentikoinnit, sessionhallinnat, cache, renderöinti, kantaliittimet, access control API kutsuille jne. mitä tässä nyt tarvitseekaan, siisti toteutus edellyttää web frameworkkia.

Delphille ei löydy niin hyvää web frameworkkia kuin Javalle, eikä varmasti niin suorituskykyistä joten Delphillä ei tässä tee yhtään mitään.

Valmispohjia on vaikka kuinka paljon. Miksi siis kannattaa aloittaa kaikkea alusta ja sairastaa kaikki lastentaudit ennen kuin loppukäyttäjät on tyytyväisiä?

Anonyymi kirjoitti:

Valmispohjia on vaikka kuinka paljon. Miksi siis kannattaa aloittaa kaikkea alusta ja sairastaa kaikki lastentaudit ennen kuin loppukäyttäjät on tyytyväisiä?

Riippuu osaamistasosta ja kuinka suuren käyttäjämäärän palvelua tekemässä.

Noin esimerkkinä kyllä Mark Zuckerbergiä saattoi jossain kohtaa vähän vituttaa kun Facebook oli jonkun PHP:n varassa.

Anonyymi kirjoitti:

Valmispohjia on vaikka kuinka paljon. Miksi siis kannattaa aloittaa kaikkea alusta ja sairastaa kaikki lastentaudit ennen kuin loppukäyttäjät on tyytyväisiä?

Niinhän sitä luulisi, mutta en ole ihan varma päätellen siitä, etten täysin tyydyttävään foorumiin vielä ole törmännyt.

1) tärkeintä uudelle foorumille olisi tehokkaasti toimiva moderointi, joka toimisi ilman ylläpitäjän aktiviteettia (eli se olisi joukkoistettu kirjoitusten lukijoille ja algoritmille); ne foorumisoftat joista yhtään mitään tiedän, vaikuttavat vaativan sen verran ylläpitäjältä, että he valkkaavat/valtuuttavat moderaattoreita käyttäjien joukosta ja sitten "sosialiseeraavat" heidän kanssaan, mikä puuha ei itseäni kiinnosta yhtään . Uskoakseni ratkaisu löytyisi viestikohtaisista arviointi-/palautepainikkeista ja käyttäjien "maineenhallinnasta" (eli sellaisten käyttäjien arvioinneilla annetaan vähemmän arvoa, joiden "peukkualas-sormi" on kovin herkässä ja toki toisinpäinkin).

2) viestiketju- ja viestinäkymät olisi kiva saada ergonomisemmiksi seurattaviksi kuin olemassa olevissa; pitkistä Suomi24:n ketjuista on todella työlästä löytää viestien väleihin lisätyt uudet vastaukset (tiedä josko kirjautumalla olisi toisin)

3) eri foorumi- ja blogialustat tuntuvat kaatuilevan ja olevan ajoittain suht työläitä toimivaksi palautettavia: alustan olisi syytä toimia kuin se kuuluisa (vanhan) junanvessa, mikä tarkoittanee että jotain on tehtävä toisin

Teoriassa varmaan olisi nopeinta ottaa joku avoin foorumisofta pohjaksi ja lähteä sitä virittämään.

Hyviä kysymyksiä. Jotta foorumi menestyisi, täytyy siellä joko olla entuudestaan runsaasti kiinnostavaa keskustelua ja riittävän vähän "kohinaa" tai vaihtoehtoisesti laajan porukan olla tietoinen uuden foorumin tuloillaan olemisesta ja valmiina ottamaan areena haltuunsa kun se valmistuu. Jälkimmäinen tilanne taitaa olla varsin harvinainen, mutta näin kävi taannoin tiedepalsta.fi-foorumin kanssa Tiede.fi-palvelun lopettaessa (ilmoittivat onneksi etukäteen palstan lopettamisesta ja foorumilla kerittiin käydä keskustelua uuden foorumin perustamisesta ja polkaista kaksikin kilpailevaa foorumia, joista em. sitten voitti skaban).

En mene vannomaan oikeaan-osuvuudesta, mutta käsitykseni on, että ilmaiset foorumisoftat eivät taida selvitä kovinkaan hyvin suuren käyttäjämäärän tuottamasta kuormasta, ja siksi kaupalliset keskustelufoorumit (isojen sanomalehtien nettikommentoinnit ja varmaan tämä Suomi24:kin) pohjannevat kaupallisiin softiin ellei peräti omin voimin koodattuihin palveluihin. Tosin, syynä voi toki olla sekin, että epäkaupallisia foorumeita pyöritetään pienin resurssein eikä niille vain yksinkertaisesti ole varaa ostaa tarpeeksi suoritusvoimaa pilvestä. Olisi mahtavaa jos joku tietävä haluaisi tätä puolta, tai muutakin liittyvää, valottaa tässä keskustelussa.

Ilmeisesti suurella volyymillä toimivan foorumin pitäisi luopua relaatiotietokannan käyttämisestä ja käyttää jotain non-sql-järjestelmää (tai koodata sellainen itse), jolloin voisi selvitä murto-osalla siitä laiteresurssista mitä tavanomaiset foorumialustat tarvitsevat. Videoiden välittämisen mukaan ottaminen toisi myös kaistan kustannuksen relevantiksi tekijäksi.

Tuohon auttaisi se, että liitetiedostojen liittäminen, ellei sitten ylipäätään viestien lähettäminen, vaatisi rekisteröitymisen, jolloin moderointi voisi jakaa jäähyjä tai lukita käyttäjätilin asiattomuuksista. Tietoturvamielessä ehkä liitetiedostojen tiedostomuotoja voisi ehkä rajata. Liitetiedostoja ongelmallisempana pitäisi linkkejä ulkopuolisille saiteille, niiden turvallisuutta kun käsittääkseni olisi lähes mahdotonta valvoa.

Itseasiassa tarkennuksena se, että kyseessä ei ollut pelkkä webbifoorumiohjelmisto, vaan ennemminkin täysi yleiskäyttöinen webbiportaali- ja foorumiohjelmisto. Eli keskustelufoorumiominaiisuudet oli vain osa sitä mitä kehitin. Mutta sille kävi sitten tosiaan huonosti kovalevyn hajottua jne.

T. miksuh

Anonyymi kirjoitti:

Itseasiassa tarkennuksena se, että kyseessä ei ollut pelkkä webbifoorumiohjelmisto, vaan ennemminkin täysi yleiskäyttöinen webbiportaali- ja foorumiohjelmisto. Eli keskustelufoorumiominaiisuudet oli vain osa sitä mitä kehitin. Mutta sille kävi sitten tosiaan huonosti kovalevyn hajottua jne.

T. miksuh

Lue lisää

Kiitoksia kokemuksesi jakamisesta! Itse aikoinaan menetin sähköposteja useamman vuoden ajalta kun olin ottanut varmuuskopion imagena, muistaakseni vieläpä RAID-0-järjestelmästä, jota sitten en saanutkaan palautettua. Jos olisinkin käyttänyt kaupallista imagenotto-ohjelmaa, niin olisi imagebrowserilla voinut palautella yksittäin tiedostot imagesta, mutta kun käytin ilmaisohjelmaa, josta itselläni ei pahemmin ollut kokemusta, niin siinä ei moista toimintoa ollut. Tuo oli aikaa jolloin pidin viestit omalla koneellani ja vain siellä. Tuon jälkeen meni maku sähköpostiviestinnästä ja siirryin yksityisviestinnässäni sosiaaliseen mediaan ja "yritysviestinnässä" monikansallisiin web-pohjaisiin sähköpostipalveluihin, vaikkakin POP/IMAP-laatikko vielä itseltäni löytyy kotimaisella palvelutarjoajalla. Koodauksessa ja dokumenttien tuotosten varmuuskopioinnissa olenkin sitten ollut aina tarkkana - lienenkö joskus alussa menettänyt muutaman tunnin työn tulokset ja siitä jäänyt tarkkuus päälle.

Tällä hetkellä vaikuttaisi parhaimmin uuden foorumialustan kehittämiseen soveltuvan Rust-ohjelmointikieli, jolla onnistuisi niin asiakas- kuin palvelinpään softan teko. Asiakaspäässä voisi ohjelman kääntää WebAssemblyksi ja palvelinpäässä suoraan binääriksi. Välistä kun jättäisi pois kaiken ylimääräisen ja pitäisi tietoliikenteen minimaalisena, niin eiköhän suorituskykyä saisi suhteessa kaistaan ja rautaan kertaluokalla lisää.

Anonyymi kirjoitti:

Kiitoksia kokemuksesi jakamisesta! Itse aikoinaan menetin sähköposteja useamman vuoden ajalta kun olin ottanut varmuuskopion imagena, muistaakseni vieläpä RAID-0-järjestelmästä, jota sitten en saanutkaan palautettua. Jos olisinkin käyttänyt kaupallista imagenotto-ohjelmaa, niin olisi imagebrowserilla voinut palautella yksittäin tiedostot imagesta, mutta kun käytin ilmaisohjelmaa, josta itselläni ei pahemmin ollut kokemusta, niin siinä ei moista toimintoa ollut. Tuo oli aikaa jolloin pidin viestit omalla koneellani ja vain siellä. Tuon jälkeen meni maku sähköpostiviestinnästä ja siirryin yksityisviestinnässäni sosiaaliseen mediaan ja "yritysviestinnässä" monikansallisiin web-pohjaisiin sähköpostipalveluihin, vaikkakin POP/IMAP-laatikko vielä itseltäni löytyy kotimaisella palvelutarjoajalla. Koodauksessa ja dokumenttien tuotosten varmuuskopioinnissa olenkin sitten ollut aina tarkkana - lienenkö joskus alussa menettänyt muutaman tunnin työn tulokset ja siitä jäänyt tarkkuus päälle.

Tällä hetkellä vaikuttaisi parhaimmin uuden foorumialustan kehittämiseen soveltuvan Rust-ohjelmointikieli, jolla onnistuisi niin asiakas- kuin palvelinpään softan teko. Asiakaspäässä voisi ohjelman kääntää WebAssemblyksi ja palvelinpäässä suoraan binääriksi. Välistä kun jättäisi pois kaiken ylimääräisen ja pitäisi tietoliikenteen minimaalisena, niin eiköhän suorituskykyä saisi suhteessa kaistaan ja rautaan kertaluokalla lisää.

Lue lisää

Siis verrattuna tavanomaisiin LAMP-ympäristön toteutuksiin.

Anonyymi kirjoitti:

Kiitoksia kokemuksesi jakamisesta! Itse aikoinaan menetin sähköposteja useamman vuoden ajalta kun olin ottanut varmuuskopion imagena, muistaakseni vieläpä RAID-0-järjestelmästä, jota sitten en saanutkaan palautettua. Jos olisinkin käyttänyt kaupallista imagenotto-ohjelmaa, niin olisi imagebrowserilla voinut palautella yksittäin tiedostot imagesta, mutta kun käytin ilmaisohjelmaa, josta itselläni ei pahemmin ollut kokemusta, niin siinä ei moista toimintoa ollut. Tuo oli aikaa jolloin pidin viestit omalla koneellani ja vain siellä. Tuon jälkeen meni maku sähköpostiviestinnästä ja siirryin yksityisviestinnässäni sosiaaliseen mediaan ja "yritysviestinnässä" monikansallisiin web-pohjaisiin sähköpostipalveluihin, vaikkakin POP/IMAP-laatikko vielä itseltäni löytyy kotimaisella palvelutarjoajalla. Koodauksessa ja dokumenttien tuotosten varmuuskopioinnissa olenkin sitten ollut aina tarkkana - lienenkö joskus alussa menettänyt muutaman tunnin työn tulokset ja siitä jäänyt tarkkuus päälle.

Tällä hetkellä vaikuttaisi parhaimmin uuden foorumialustan kehittämiseen soveltuvan Rust-ohjelmointikieli, jolla onnistuisi niin asiakas- kuin palvelinpään softan teko. Asiakaspäässä voisi ohjelman kääntää WebAssemblyksi ja palvelinpäässä suoraan binääriksi. Välistä kun jättäisi pois kaiken ylimääräisen ja pitäisi tietoliikenteen minimaalisena, niin eiköhän suorituskykyä saisi suhteessa kaistaan ja rautaan kertaluokalla lisää.

Lue lisää

"Tällä hetkellä vaikuttaisi parhaimmin uuden foorumialustan kehittämiseen soveltuvan Rust-ohjelmointikieli, jolla onnistuisi niin asiakas- kuin palvelinpään softan teko. Asiakaspäässä voisi ohjelman kääntää WebAssemblyksi ja palvelinpäässä suoraan binääriksi. Välistä kun jättäisi pois kaiken ylimääräisen ja pitäisi tietoliikenteen minimaalisena, niin eiköhän suorituskykyä saisi suhteessa kaistaan ja rautaan kertaluokalla lisää."

Itseasiassa ei.

Backendin suorituskyvyssä ohjelmointikielen tasolla ratkaisee älyttömän paljon kuinka nopeasti käsittelee requesteja. Suorituskyvyn puolesta Java ja C# saadaan helposti nopeammaksi.

Ohjelmointikieltä enemmän merkitsee se missä muodossa data on. Eli onko relaatiodataa vai dokumenttidataa vai jotain muuta, ja miten skaalata tätä.

Suorituskykyä enemmän merkitsee käytännössä hostauskustannukset. Siellä se kanta juurikin on se mikä tekee kulua ja kevyemmissä jutuissa joku pieni relaatiokanta tulee helposti halvimmaksi. Tässä pitää huomioida myös kahdennus että kantapalvelimen vikaantuminen ei aiheuta ongelmia.

Toinen erittäin kiinnostava asia kulujen kannalta on se, että onko kuormitus tasaista vai ajoittaista, eli jos on ajoittaista niin helposti mieltä rakentaa serverlessiä ja suurin osa palvelimista pois käytöstä kun ei ole käyttöä.

Asiakaspäässä webassembly hidastaa, sillä ei taida vielä päästä suoraan tekemään kyselyjä palvelimelle jota suuri osa suorituksesta on. Ja koko webassembly ympäristön käynnistys ja kaikki venkslaus sen kanssa jokseenkin varmasti vain hidastaa ja tekee hankalammaksi. Foorumsofta todennäköisesti kannattaa tehdä backend painotteisesti, etenkin jos haluaa hakukoneiden pääsevän näkemään sisälle.

Anonyymi kirjoitti:

"Tällä hetkellä vaikuttaisi parhaimmin uuden foorumialustan kehittämiseen soveltuvan Rust-ohjelmointikieli, jolla onnistuisi niin asiakas- kuin palvelinpään softan teko. Asiakaspäässä voisi ohjelman kääntää WebAssemblyksi ja palvelinpäässä suoraan binääriksi. Välistä kun jättäisi pois kaiken ylimääräisen ja pitäisi tietoliikenteen minimaalisena, niin eiköhän suorituskykyä saisi suhteessa kaistaan ja rautaan kertaluokalla lisää."

Itseasiassa ei.

Backendin suorituskyvyssä ohjelmointikielen tasolla ratkaisee älyttömän paljon kuinka nopeasti käsittelee requesteja. Suorituskyvyn puolesta Java ja C# saadaan helposti nopeammaksi.

Ohjelmointikieltä enemmän merkitsee se missä muodossa data on. Eli onko relaatiodataa vai dokumenttidataa vai jotain muuta, ja miten skaalata tätä.

Suorituskykyä enemmän merkitsee käytännössä hostauskustannukset. Siellä se kanta juurikin on se mikä tekee kulua ja kevyemmissä jutuissa joku pieni relaatiokanta tulee helposti halvimmaksi. Tässä pitää huomioida myös kahdennus että kantapalvelimen vikaantuminen ei aiheuta ongelmia.

Toinen erittäin kiinnostava asia kulujen kannalta on se, että onko kuormitus tasaista vai ajoittaista, eli jos on ajoittaista niin helposti mieltä rakentaa serverlessiä ja suurin osa palvelimista pois käytöstä kun ei ole käyttöä.

Asiakaspäässä webassembly hidastaa, sillä ei taida vielä päästä suoraan tekemään kyselyjä palvelimelle jota suuri osa suorituksesta on. Ja koko webassembly ympäristön käynnistys ja kaikki venkslaus sen kanssa jokseenkin varmasti vain hidastaa ja tekee hankalammaksi. Foorumsofta todennäköisesti kannattaa tehdä backend painotteisesti, etenkin jos haluaa hakukoneiden pääsevän näkemään sisälle.

Lue lisää

Olipas siinä taas mutuilua jolta kulta millä ei ole mitään tietoa asiasta.

Anonyymi kirjoitti:

Olipas siinä taas mutuilua jolta kulta millä ei ole mitään tietoa asiasta.

Piti tarkistaa.

Nähtävästi Rustilla työnalla ollut ntex tullut tuotantovalmiiksi 2kk sitten. Tietyntyyppisissä, synteettisissä testeissä näkyy siinä olevan erinomaisen hyvät tulokset mutta Javapuoli sitten on näissä normaaleissa JSON serialisoinneissa kovempi.

Foorumiin nyt kuitenkin sitten tarvitaan vähän muitakin komponentteja kuin webservice, että käytännössä kaivataan joku autentikointi vaikka ja tosiaankin se on se tietokanta mikä tässä merkitsee enemmän.

Webassemblyyn on tulossa HTTP (wasi-http) mutta ei ole valmis, ja webassemblyssä siten on omat haittansa miksi se on väärä tekniikka foorumin tekoon.

Anonyymi kirjoitti:

"Tällä hetkellä vaikuttaisi parhaimmin uuden foorumialustan kehittämiseen soveltuvan Rust-ohjelmointikieli, jolla onnistuisi niin asiakas- kuin palvelinpään softan teko. Asiakaspäässä voisi ohjelman kääntää WebAssemblyksi ja palvelinpäässä suoraan binääriksi. Välistä kun jättäisi pois kaiken ylimääräisen ja pitäisi tietoliikenteen minimaalisena, niin eiköhän suorituskykyä saisi suhteessa kaistaan ja rautaan kertaluokalla lisää."

Itseasiassa ei.

Backendin suorituskyvyssä ohjelmointikielen tasolla ratkaisee älyttömän paljon kuinka nopeasti käsittelee requesteja. Suorituskyvyn puolesta Java ja C# saadaan helposti nopeammaksi.

Ohjelmointikieltä enemmän merkitsee se missä muodossa data on. Eli onko relaatiodataa vai dokumenttidataa vai jotain muuta, ja miten skaalata tätä.

Suorituskykyä enemmän merkitsee käytännössä hostauskustannukset. Siellä se kanta juurikin on se mikä tekee kulua ja kevyemmissä jutuissa joku pieni relaatiokanta tulee helposti halvimmaksi. Tässä pitää huomioida myös kahdennus että kantapalvelimen vikaantuminen ei aiheuta ongelmia.

Toinen erittäin kiinnostava asia kulujen kannalta on se, että onko kuormitus tasaista vai ajoittaista, eli jos on ajoittaista niin helposti mieltä rakentaa serverlessiä ja suurin osa palvelimista pois käytöstä kun ei ole käyttöä.

Asiakaspäässä webassembly hidastaa, sillä ei taida vielä päästä suoraan tekemään kyselyjä palvelimelle jota suuri osa suorituksesta on. Ja koko webassembly ympäristön käynnistys ja kaikki venkslaus sen kanssa jokseenkin varmasti vain hidastaa ja tekee hankalammaksi. Foorumsofta todennäköisesti kannattaa tehdä backend painotteisesti, etenkin jos haluaa hakukoneiden pääsevän näkemään sisälle.

Lue lisää

Rust on erään testin mukaan viisi kertaa nopeampi kuin Java mitä tulee JWT-sovelluksiin (https://medium.com/deno-the-complete-reference/java-vs-rust-how-faster-is-machine-code-compared-to-interpreted-code-for-jwt-sign-verify-fa6aeeabff58). Rustilla tehdyt ongelmat ovat nopeudeltaan periaatteessa c:n luokkaa, joskin teoriassa mahdollistaa jopa nopeamman koodin (ainakin kääntäjän kehittyessä: https://kornel.ski/rust-c-speed).

Noin minäkin olen ymmärtänyt, että tietokantakulut ovat yksi keskeisimmistä kuluista, ja siksi tällaisen kuluttajalle päin ilmaisen palvelun toteuttamisessa tärkeä minimoitava kulu. Mikäli palvelu rajoittuisi vain suomenkielisille käyttäjille, niin kuormitus olisi varsin epätasaista ja siten palvelua todennäköisesti kannattaisi pyörittää pilvessä, jossa kuormitus skaalautuisi alas- ja ylöspäin tarpeen mukaan.

Tuo heittoni WebAssemblyn käytöstä asiakaspäässä tuli lähinnä vain siitä, että Rustilla tuo onnistuisi. Sinällään asiakaspäässä suorituskyky ei tällaisessa sovellutuksessa ole mitenkään kriittinen, enemmänkin tietoturva ja tietoliikenteen minimointi. Tietoliikenteen minimointi onnistuu JavaScriptillä, vaan sen tietoturvapuolta jotkut ovat kyseenalaistaneet. Käyttäjäkokemus toki on erittäin tärkeää ja jos WebAssemblyn kanssa on samoin kuin aikoinaan Javan kanssa että JVM:n käynnistys kestää häiritsevän pitkään (tiedä mikä tilanne tänä päivänä, jos joku vielä Javaa käyttää asiakaspäässä), niin ei se sitten tulisi kyseeseen. Oma arvioni on, että WebAssembly tulee pikkuhiljaa saamaan merkittävän aseman - ellei peräti perusalustaksi asiakaspään sovellusten suorittamiseen ja selaimet tehdään sen mukaan.

Anonyymi kirjoitti:

Rust on erään testin mukaan viisi kertaa nopeampi kuin Java mitä tulee JWT-sovelluksiin (https://medium.com/deno-the-complete-reference/java-vs-rust-how-faster-is-machine-code-compared-to-interpreted-code-for-jwt-sign-verify-fa6aeeabff58). Rustilla tehdyt ongelmat ovat nopeudeltaan periaatteessa c:n luokkaa, joskin teoriassa mahdollistaa jopa nopeamman koodin (ainakin kääntäjän kehittyessä: https://kornel.ski/rust-c-speed).

Noin minäkin olen ymmärtänyt, että tietokantakulut ovat yksi keskeisimmistä kuluista, ja siksi tällaisen kuluttajalle päin ilmaisen palvelun toteuttamisessa tärkeä minimoitava kulu. Mikäli palvelu rajoittuisi vain suomenkielisille käyttäjille, niin kuormitus olisi varsin epätasaista ja siten palvelua todennäköisesti kannattaisi pyörittää pilvessä, jossa kuormitus skaalautuisi alas- ja ylöspäin tarpeen mukaan.

Tuo heittoni WebAssemblyn käytöstä asiakaspäässä tuli lähinnä vain siitä, että Rustilla tuo onnistuisi. Sinällään asiakaspäässä suorituskyky ei tällaisessa sovellutuksessa ole mitenkään kriittinen, enemmänkin tietoturva ja tietoliikenteen minimointi. Tietoliikenteen minimointi onnistuu JavaScriptillä, vaan sen tietoturvapuolta jotkut ovat kyseenalaistaneet. Käyttäjäkokemus toki on erittäin tärkeää ja jos WebAssemblyn kanssa on samoin kuin aikoinaan Javan kanssa että JVM:n käynnistys kestää häiritsevän pitkään (tiedä mikä tilanne tänä päivänä, jos joku vielä Javaa käyttää asiakaspäässä), niin ei se sitten tulisi kyseeseen. Oma arvioni on, että WebAssembly tulee pikkuhiljaa saamaan merkittävän aseman - ellei peräti perusalustaksi asiakaspään sovellusten suorittamiseen ja selaimet tehdään sen mukaan.

Lue lisää

Voi se jonkun JWT:n tekeminen tosiaankin CPU:ssa tuntua mutta käytännössä se on kokonaissuorituskyvyssä vähäistä.

C myös sellainen kieli, että kyllä se matalalla tasolla on nopea mutta käytännössä webservicejä tehdessä, ei ole. On itseasiassa tyyliin hitain se että palvelin käynnistä jotain cgi-bin kikkareita kun tehdään kyselyjä kun jokainen request käynnistää oman prosessin niin tehot menee siihen sitten.

Tietokantakulut tosiaankin on se mikä maksaa että edullisin tapa on yhden serverin vehje ja etenkin jos sinne ei kirjoiteta mitään vaan lähinnä luetaan niin 5€/kk SQLite palvelin mikä ei skaalaudu. Mutta kun pitää kirjoittaakin kuten foorumiviestit (kirjoitusoperaatiot lukitsee koko SQLite kannan) niin seuraava hintataso olisi vaikka joku PostgreSQL kanta ja se on muutenkin hyvä jos haluaa relaatioita. 10€/kk tms. minimissään hitain mahdollinen kantapalvelin ja sen keulilla sitten voi ajaa web palvelimia. Siihen vaan tarvitsee helposti vauhtia siihen ettei halvin riitä vauhtia voi hakea laittamalla siihen joku redis cachettamaan ettei tarvitse lukuoperaatioilla turhaan kuormittaa kantaa. SQL kannoilla horisontaalinen skaalaus hankalempaa.

NoSQL:t lähtee jostain 50€/kk minimissään mutta niitä skaalailee helposti. Relaatiot näissä sitten se hankaluus.

Ja riippuen mitä tekee niin voi tarvita useita kantoja riippuen mitä dataa niissä on. Ihan normaalia vaikka se että PostgreSQL missä käyttäjät ja relaatiomuotoinen data ja NoSQL sitten dokumenteille.

Tuossa tilanteen mukaan skaalautuvassa suorituksessa Java on sitten hyvä, helposti paras, ja JVM:n käynnistys ei ole ongelma koska skaalautuviin vehkeisiin Javaa saa käännettyä natiiviksi. Jatkuvasti päällä roksottavissa koneissa JVM saakin käynnistyä ja JVM toimii helposti tehokkaammin kuin natiiviksi käännetty kun siellä ei tehdä muistinvapausta muulloin kuin idlellä.

Javascriptin tietoturvassa ei ole ongelmaa mutta webassemblyn ongelmat asiakaspäässä sitten sitä, että accessibility vaiketa. Siinä myöskin ladataan client binäärinä mutta tällä hetkellä suorituskyvyt hukkautuisi siihen kun HTTP kyselyt tapahtuisi JS puolella kun se on vasta kehitysasteella webassemblyssä. Webassembly siis hidastaisi. Webassemly sitten on erittäin hyvä vaikka peleissä missä koko peli pyörii webassemblyssä ja piirtää canvasille, tai jos tekee jonkun moduulin mikä tekee raskaampaa laskentaa client puolella niin sen voi kääntää webassemblylle ja JS kutsuu sitä.

Eli itse tekisin niin että pääasiassa renderöisi tavaran palvelimessa mutta JS:ää voisi käyttää asiakaspuolella siihen että vähentää sivulatauksia. Esimerkiksi kun kirjoittaa viestin niin JS:llä lisää sen viestiketjuun samalla kun lähettää palvelimelle mutta ei sitten tee tähän turhaa sivulatausta.

Olennainen optimointi on se sivulatausten määrän vähentäminen mutta kun sieltä palvelimelta jotain tarvitsee ladata niin sivulataus itsessään ei ole ongelma vaan voi olla hyvinkin nopeata.

Suomi24:ssä sitten viestin lähetys mielestäni tekee sivulatauksen missä se kirjoitettu viesti tulee näkyviin niin tuo nyt tarpeettomasti tekee kuormaa joka viestinlähetyksessä.

Anonyymi kirjoitti:

Rust on erään testin mukaan viisi kertaa nopeampi kuin Java mitä tulee JWT-sovelluksiin (https://medium.com/deno-the-complete-reference/java-vs-rust-how-faster-is-machine-code-compared-to-interpreted-code-for-jwt-sign-verify-fa6aeeabff58). Rustilla tehdyt ongelmat ovat nopeudeltaan periaatteessa c:n luokkaa, joskin teoriassa mahdollistaa jopa nopeamman koodin (ainakin kääntäjän kehittyessä: https://kornel.ski/rust-c-speed).

Noin minäkin olen ymmärtänyt, että tietokantakulut ovat yksi keskeisimmistä kuluista, ja siksi tällaisen kuluttajalle päin ilmaisen palvelun toteuttamisessa tärkeä minimoitava kulu. Mikäli palvelu rajoittuisi vain suomenkielisille käyttäjille, niin kuormitus olisi varsin epätasaista ja siten palvelua todennäköisesti kannattaisi pyörittää pilvessä, jossa kuormitus skaalautuisi alas- ja ylöspäin tarpeen mukaan.

Tuo heittoni WebAssemblyn käytöstä asiakaspäässä tuli lähinnä vain siitä, että Rustilla tuo onnistuisi. Sinällään asiakaspäässä suorituskyky ei tällaisessa sovellutuksessa ole mitenkään kriittinen, enemmänkin tietoturva ja tietoliikenteen minimointi. Tietoliikenteen minimointi onnistuu JavaScriptillä, vaan sen tietoturvapuolta jotkut ovat kyseenalaistaneet. Käyttäjäkokemus toki on erittäin tärkeää ja jos WebAssemblyn kanssa on samoin kuin aikoinaan Javan kanssa että JVM:n käynnistys kestää häiritsevän pitkään (tiedä mikä tilanne tänä päivänä, jos joku vielä Javaa käyttää asiakaspäässä), niin ei se sitten tulisi kyseeseen. Oma arvioni on, että WebAssembly tulee pikkuhiljaa saamaan merkittävän aseman - ellei peräti perusalustaksi asiakaspään sovellusten suorittamiseen ja selaimet tehdään sen mukaan.

Lue lisää

"Rustilla tehdyt ongelmat ovat nopeudeltaan periaatteessa c:n luokkaa, joskin teoriassa mahdollistaa jopa nopeamman koodin"

Tarkoittanet OHJELMIA kuitenkin? Hyvä Rust-kääntäjä voi tuottaa koodia, joka vastaa nopeudeltaan C-kielestä käännettyä, uskon tämän. Mutta teoriasi jopa nopeammasta koodista on yhtä uskottava kuin raketti, joka lentää valoa nopeammin.

Anonyymi kirjoitti:

Voi se jonkun JWT:n tekeminen tosiaankin CPU:ssa tuntua mutta käytännössä se on kokonaissuorituskyvyssä vähäistä.

C myös sellainen kieli, että kyllä se matalalla tasolla on nopea mutta käytännössä webservicejä tehdessä, ei ole. On itseasiassa tyyliin hitain se että palvelin käynnistä jotain cgi-bin kikkareita kun tehdään kyselyjä kun jokainen request käynnistää oman prosessin niin tehot menee siihen sitten.

Tietokantakulut tosiaankin on se mikä maksaa että edullisin tapa on yhden serverin vehje ja etenkin jos sinne ei kirjoiteta mitään vaan lähinnä luetaan niin 5€/kk SQLite palvelin mikä ei skaalaudu. Mutta kun pitää kirjoittaakin kuten foorumiviestit (kirjoitusoperaatiot lukitsee koko SQLite kannan) niin seuraava hintataso olisi vaikka joku PostgreSQL kanta ja se on muutenkin hyvä jos haluaa relaatioita. 10€/kk tms. minimissään hitain mahdollinen kantapalvelin ja sen keulilla sitten voi ajaa web palvelimia. Siihen vaan tarvitsee helposti vauhtia siihen ettei halvin riitä vauhtia voi hakea laittamalla siihen joku redis cachettamaan ettei tarvitse lukuoperaatioilla turhaan kuormittaa kantaa. SQL kannoilla horisontaalinen skaalaus hankalempaa.

NoSQL:t lähtee jostain 50€/kk minimissään mutta niitä skaalailee helposti. Relaatiot näissä sitten se hankaluus.

Ja riippuen mitä tekee niin voi tarvita useita kantoja riippuen mitä dataa niissä on. Ihan normaalia vaikka se että PostgreSQL missä käyttäjät ja relaatiomuotoinen data ja NoSQL sitten dokumenteille.

Tuossa tilanteen mukaan skaalautuvassa suorituksessa Java on sitten hyvä, helposti paras, ja JVM:n käynnistys ei ole ongelma koska skaalautuviin vehkeisiin Javaa saa käännettyä natiiviksi. Jatkuvasti päällä roksottavissa koneissa JVM saakin käynnistyä ja JVM toimii helposti tehokkaammin kuin natiiviksi käännetty kun siellä ei tehdä muistinvapausta muulloin kuin idlellä.

Javascriptin tietoturvassa ei ole ongelmaa mutta webassemblyn ongelmat asiakaspäässä sitten sitä, että accessibility vaiketa. Siinä myöskin ladataan client binäärinä mutta tällä hetkellä suorituskyvyt hukkautuisi siihen kun HTTP kyselyt tapahtuisi JS puolella kun se on vasta kehitysasteella webassemblyssä. Webassembly siis hidastaisi. Webassemly sitten on erittäin hyvä vaikka peleissä missä koko peli pyörii webassemblyssä ja piirtää canvasille, tai jos tekee jonkun moduulin mikä tekee raskaampaa laskentaa client puolella niin sen voi kääntää webassemblylle ja JS kutsuu sitä.

Eli itse tekisin niin että pääasiassa renderöisi tavaran palvelimessa mutta JS:ää voisi käyttää asiakaspuolella siihen että vähentää sivulatauksia. Esimerkiksi kun kirjoittaa viestin niin JS:llä lisää sen viestiketjuun samalla kun lähettää palvelimelle mutta ei sitten tee tähän turhaa sivulatausta.

Olennainen optimointi on se sivulatausten määrän vähentäminen mutta kun sieltä palvelimelta jotain tarvitsee ladata niin sivulataus itsessään ei ole ongelma vaan voi olla hyvinkin nopeata.

Suomi24:ssä sitten viestin lähetys mielestäni tekee sivulatauksen missä se kirjoitettu viesti tulee näkyviin niin tuo nyt tarpeettomasti tekee kuormaa joka viestinlähetyksessä.

Lue lisää

"C myös sellainen kieli, että kyllä se matalalla tasolla on nopea mutta käytännössä webservicejä tehdessä, ei ole. On itseasiassa tyyliin hitain se että palvelin käynnistä jotain cgi-bin kikkareita kun tehdään kyselyjä kun jokainen request käynnistää oman prosessin niin tehot menee siihen sitten."

Tuohan ei ole C-kielen heikkous lainkaan. Jos "palvelin käynnistä jotain cgi-bin kikkareita", vika on C-koodin kirjoittajassa. Siis jos se on vika eikä ominaisuus.

C-kieli tuottaa assemblerin jälkeen todennäköisesti tehokkainta koodia millä tahansa "tasolla". Tehokkainta eli nopeinta, tiiveintä tai mitä tahansa halutaankaan siltä väliltä. Mutta eihän kukaan kirjoita mitään tietokantakyselyjä C-kielellä tai assemblerilla varsinkaan, jos siihen on tuottavampia työkaluja käytettävissä.

Kuten totesit, C-kieli on matalan tason ohjelmointikieli. Tietokantakyselyjen teko sillä onnistuu kuten millä tahansa muulla kielellä, mutta koodaaminen on piinallisen työlästä ja aikaaviepää. Kokemusta on!

Anonyymi kirjoitti:

"C myös sellainen kieli, että kyllä se matalalla tasolla on nopea mutta käytännössä webservicejä tehdessä, ei ole. On itseasiassa tyyliin hitain se että palvelin käynnistä jotain cgi-bin kikkareita kun tehdään kyselyjä kun jokainen request käynnistää oman prosessin niin tehot menee siihen sitten."

Tuohan ei ole C-kielen heikkous lainkaan. Jos "palvelin käynnistä jotain cgi-bin kikkareita", vika on C-koodin kirjoittajassa. Siis jos se on vika eikä ominaisuus.

C-kieli tuottaa assemblerin jälkeen todennäköisesti tehokkainta koodia millä tahansa "tasolla". Tehokkainta eli nopeinta, tiiveintä tai mitä tahansa halutaankaan siltä väliltä. Mutta eihän kukaan kirjoita mitään tietokantakyselyjä C-kielellä tai assemblerilla varsinkaan, jos siihen on tuottavampia työkaluja käytettävissä.

Kuten totesit, C-kieli on matalan tason ohjelmointikieli. Tietokantakyselyjen teko sillä onnistuu kuten millä tahansa muulla kielellä, mutta koodaaminen on piinallisen työlästä ja aikaaviepää. Kokemusta on!

Lue lisää

"C-kieli tuottaa assemblerin jälkeen todennäköisesti tehokkainta koodia millä tahansa "tasolla". Tehokkainta eli nopeinta, tiiveintä tai mitä tahansa halutaankaan siltä väliltä. "

Tuota pitäisi arvioida niin, että kun kirjoittaa koodin mahdollisimman siististi että mikä se suorituskyky on silloin, eikä niin että kirjoitetaan koodista epäselvempää optimoimalla nopeutta.

Kun työvälineistä puuttuu tietyt helpottavat asiat niin sellainen selkeän näköinen C toteutus ei mitenkään selvästi ole enää nopein. Usein esimerkiksi Haskellilla tehdyt ohjelmat toimivat nopeammin kuin mitä C:llä tehty vastaava siisti koodi on, kun Haskell mahdollistaa rajumpia optimointeja automaattisesti mistä ohjelmoijan ei tarvitse välittää.

Anonyymi kirjoitti:

"C-kieli tuottaa assemblerin jälkeen todennäköisesti tehokkainta koodia millä tahansa "tasolla". Tehokkainta eli nopeinta, tiiveintä tai mitä tahansa halutaankaan siltä väliltä. "

Tuota pitäisi arvioida niin, että kun kirjoittaa koodin mahdollisimman siististi että mikä se suorituskyky on silloin, eikä niin että kirjoitetaan koodista epäselvempää optimoimalla nopeutta.

Kun työvälineistä puuttuu tietyt helpottavat asiat niin sellainen selkeän näköinen C toteutus ei mitenkään selvästi ole enää nopein. Usein esimerkiksi Haskellilla tehdyt ohjelmat toimivat nopeammin kuin mitä C:llä tehty vastaava siisti koodi on, kun Haskell mahdollistaa rajumpia optimointeja automaattisesti mistä ohjelmoijan ei tarvitse välittää.

Lue lisää

Kirjoitit: "Tuota pitäisi arvioida niin, että kun kirjoittaa koodin mahdollisimman siististi että mikä se suorituskyky on silloin, eikä niin että kirjoitetaan koodista epäselvempää optimoimalla nopeutta."

Sinulla saattaa olla hyvää kokemusta Haskellista ja ehkä muistakin korkean tason ohjelmointikielistä. Mutta C-kielen tuntemuksesi ei vakuuta.

Koodista puheenollen, siisti on ylläpidon kannalta ilman muuta parempi kuin epäselvä. Siistillä C-koodilla vain ei ole mitään tekemistä suorituskyvyn kanssa. Äärimmäisen suorituskykyinen C-koodi voi olla supersiistiä ja vastaavasti siistiltä näyttävä koodi voi olla kelvotonta kökköä.

C-koodaajan täytyy yleensä tietää miten kääntäjä koodin tulkitsee. Esimerkiksi osoittimen käytöllä tietyssä tilanteessa versus indeksoinnilla saattaa olla merkittävä vaikutus lopputulokseen. Erityisen tärkeää tämä on sulautetuissa koodeissa, joissa resurssit ovat niukat. Jollei C-koodaaja osaa lukea kääntäjän tuottamaa listausta, kökköä syntyy väistämättä.

C on siis matalan tason ohjelmointikieli, "symbolinen assembler", joka häviää koodaamisen helppoudessa ja tuottavuudessa jokseenkin kaikille korkean tason ohjelmointikielille. Mutta parempaan, siis tehokkaampaan lopputulokseen - millä mittarilla tahansa - yltäviä ohjelmointikieliä on vain yksi: Assembler.

Ole ystävällinen ja kerro esimerkki vaikkapa Haskell-koodista, joka "rajusti optimoituna" tuottaa nopeammin toimivaa koodia kuin "selkeän näköinen C toteutus" niin osoitan mielelläni luulosi vääräksi. Pidetään koodi inhimillisessä mitassa kuitenkin.

Anonyymi kirjoitti:

Kirjoitit: "Tuota pitäisi arvioida niin, että kun kirjoittaa koodin mahdollisimman siististi että mikä se suorituskyky on silloin, eikä niin että kirjoitetaan koodista epäselvempää optimoimalla nopeutta."

Sinulla saattaa olla hyvää kokemusta Haskellista ja ehkä muistakin korkean tason ohjelmointikielistä. Mutta C-kielen tuntemuksesi ei vakuuta.

Koodista puheenollen, siisti on ylläpidon kannalta ilman muuta parempi kuin epäselvä. Siistillä C-koodilla vain ei ole mitään tekemistä suorituskyvyn kanssa. Äärimmäisen suorituskykyinen C-koodi voi olla supersiistiä ja vastaavasti siistiltä näyttävä koodi voi olla kelvotonta kökköä.

C-koodaajan täytyy yleensä tietää miten kääntäjä koodin tulkitsee. Esimerkiksi osoittimen käytöllä tietyssä tilanteessa versus indeksoinnilla saattaa olla merkittävä vaikutus lopputulokseen. Erityisen tärkeää tämä on sulautetuissa koodeissa, joissa resurssit ovat niukat. Jollei C-koodaaja osaa lukea kääntäjän tuottamaa listausta, kökköä syntyy väistämättä.

C on siis matalan tason ohjelmointikieli, "symbolinen assembler", joka häviää koodaamisen helppoudessa ja tuottavuudessa jokseenkin kaikille korkean tason ohjelmointikielille. Mutta parempaan, siis tehokkaampaan lopputulokseen - millä mittarilla tahansa - yltäviä ohjelmointikieliä on vain yksi: Assembler.

Ole ystävällinen ja kerro esimerkki vaikkapa Haskell-koodista, joka "rajusti optimoituna" tuottaa nopeammin toimivaa koodia kuin "selkeän näköinen C toteutus" niin osoitan mielelläni luulosi vääräksi. Pidetään koodi inhimillisessä mitassa kuitenkin.

Lue lisää

"Sinulla saattaa olla hyvää kokemusta Haskellista ja ehkä muistakin korkean tason ohjelmointikielistä. Mutta C-kielen tuntemuksesi ei vakuuta."

Olen ohjelmoinut C:llä 29 vuotta. Tunnen sen läpeensä.

"Siistillä C-koodilla vain ei ole mitään tekemistä suorituskyvyn kanssa."

Sitten et ole ymmärtänyt ohjelmoinnin perusteita.

Ei lähdekoodia kirjoiteta tietokonetta varten vaan ihmisiä varten. Se että käydään tekemään sotkuisemmin asioita jonkun suorituskyvyn takia on hyvin poikkeuksellista ja silloin on syytä epäillä onko työkalu edes oikein valittu.

Suorituskyky kun ei ole tietokoneissa mikään ongelma.

"Ole ystävällinen ja kerro esimerkki vaikkapa Haskell-koodista, joka "rajusti optimoituna" tuottaa nopeammin toimivaa koodia kuin "selkeän näköinen C toteutus" niin osoitan mielelläni luulosi vääräksi."

Siis jos tehdään lähdekoodi niin, että sitä on mahdollisimman selkeätä lukea, mikä on täysin normaalia ohjelmointia, tekemällä samoja asioita C:llä ja Haskellilla antaa Haskell suorituskykyetua joissakin tilanteissa.

Syynä on yksinkertaisesti se, että C:llä ohjelmointi on sitä, että on varmistin pois päältä ja sillä voi ampua jalkaan. Sen sijaan Haskellissa kieli mahdollistaa sen, että kääntäjä pystyy tekemään turvallisia oletuksia rikkomatta toiminallisuutta.

Noin esimerkkinä, C:llä on mahdollista tehdä vaikka miljoonan alkion tietorakenne ja tehdä siitä kopio ja muokata kopiota. C:ssä on kopiointia varten esimerkiksi kutsu memcpy()

Kääntäjä tietenkin tekee sen kopioinnin kun ohjelmoija on niin käskenyt koska ohjelman oikea toiminta edellyttää sitä. Haskellissa kääntäjä voi käsitellä asioita automaattisesti viittauksina kopioimatta mitään. Kääntäjä tietää aina milloin missäkin muistipaikassa muutoksella on väliä.

Toinen esimerkki liittyisi suoritusjärjestykseen. C kielisissä ohjelmissa aika normaalisti funktion alussa tehdään alustuksia, avataan tiedosto että saa tiedostokahvan ja jne. ja käännettäessä ne tehdään pääpiirteissään näin.

Haskell sen sijaan evaluoi mitä tahansa lauseketta vasta silloin kun tarvitaan ja tuo tapahtuu automaattisesti. Kun käsitellään suurempia datamääriä, tuo Haskellin tapa voi olla automaattisesti tehokkaampi mutta tuo ei ole niin selkeä tilanne.

Tässä näistä vähän tarkemmin selitetty: https://www.dremio.com/wiki/eager-evaluation/

Haskell siis toimii automaattisesti lazy evaluationilla.

En minä nyt sano, että Haskell olisi aina parempi ja helposti Haskellilla voi tehdä hitaammankin softan, että lähtökohta olisi se, että pyritään kirjoittamaan softa niin selkeästi luettavaksi kuin mahdollista. Työkalu sitten valitaan tilanteen mukaan, että mikä siihen sopii parhaiten.

C ei ole automaattisesti tee nopeinta koodia.. Eihän sitä tarvitse kuin tehdä C++:lla niin voi lopputulos voi olla helpommin nopeampi kun tässä on nimiavaruudet, että ei tee mieli samalla tavalla palastella ohjelmia erillisiin prosesseihin. Tietenkin se C:n tapa tehdä ohjelmia taas rinnakkaistuu automaattisesti mutta se että palasteltu useaan prosessiin voi viedä tehoja.

Ei ne eri välineiden suorituskykyerot oikeasti tule vastaan kun tekee pikkuohjelmia. Hyvin yksinkertaisissa Hello Worldeissa C nyt onkin hyvä mutta sitten kun on kompleksisuutta niin pitää ymmärtää se miten se tehdään välineellä yksinkertaisimmin ja millaiset asiat tekee häviötä suorituskyvyssä. Joissakin välineissä kun nimenomaisesti on ratkottu jotain tarvetta.

Ei C oikein kivasti esimerkiksi sovellu myöskään kaikentyyppisiin asioihin. Hyvä esimerkki vaikka on Whatsappin koneisto millä niitä viestiä välitetään. 140 miljardia viestiä päivässä. Ja se lisäksi on toimii niin, että vaikka raudassa olisi ollut pieni häiriö niin toiminta ei keskeydy. Tai että kaatuisi kun paljon käyttäjiä.

Temppu on ratkottu tavukoodikoneella jossa jokainen yhteys on oma prosessi ja jos se mistä tahansa syystä toimii väärin niin kyseisen yhteyden prosessi vaan tapetaan ja käynnistetään uusiksi. C:llä tuollaisen rakentaminen vaatii aika paljon enemmän koodirivejä kuin käyttää kieltä joka tuollaisen mahdollistaa kielen ominaisuutena.

Eli ei tässä mitään ihmeellsitä ole, että valitsee vaan työkalun sen mukaan mitä sillä on tarkoitus tehdä että saa koodin kirjoitettua siististi.

Anonyymi kirjoitti:

Voi se jonkun JWT:n tekeminen tosiaankin CPU:ssa tuntua mutta käytännössä se on kokonaissuorituskyvyssä vähäistä.

C myös sellainen kieli, että kyllä se matalalla tasolla on nopea mutta käytännössä webservicejä tehdessä, ei ole. On itseasiassa tyyliin hitain se että palvelin käynnistä jotain cgi-bin kikkareita kun tehdään kyselyjä kun jokainen request käynnistää oman prosessin niin tehot menee siihen sitten.

Tietokantakulut tosiaankin on se mikä maksaa että edullisin tapa on yhden serverin vehje ja etenkin jos sinne ei kirjoiteta mitään vaan lähinnä luetaan niin 5€/kk SQLite palvelin mikä ei skaalaudu. Mutta kun pitää kirjoittaakin kuten foorumiviestit (kirjoitusoperaatiot lukitsee koko SQLite kannan) niin seuraava hintataso olisi vaikka joku PostgreSQL kanta ja se on muutenkin hyvä jos haluaa relaatioita. 10€/kk tms. minimissään hitain mahdollinen kantapalvelin ja sen keulilla sitten voi ajaa web palvelimia. Siihen vaan tarvitsee helposti vauhtia siihen ettei halvin riitä vauhtia voi hakea laittamalla siihen joku redis cachettamaan ettei tarvitse lukuoperaatioilla turhaan kuormittaa kantaa. SQL kannoilla horisontaalinen skaalaus hankalempaa.

NoSQL:t lähtee jostain 50€/kk minimissään mutta niitä skaalailee helposti. Relaatiot näissä sitten se hankaluus.

Ja riippuen mitä tekee niin voi tarvita useita kantoja riippuen mitä dataa niissä on. Ihan normaalia vaikka se että PostgreSQL missä käyttäjät ja relaatiomuotoinen data ja NoSQL sitten dokumenteille.

Tuossa tilanteen mukaan skaalautuvassa suorituksessa Java on sitten hyvä, helposti paras, ja JVM:n käynnistys ei ole ongelma koska skaalautuviin vehkeisiin Javaa saa käännettyä natiiviksi. Jatkuvasti päällä roksottavissa koneissa JVM saakin käynnistyä ja JVM toimii helposti tehokkaammin kuin natiiviksi käännetty kun siellä ei tehdä muistinvapausta muulloin kuin idlellä.

Javascriptin tietoturvassa ei ole ongelmaa mutta webassemblyn ongelmat asiakaspäässä sitten sitä, että accessibility vaiketa. Siinä myöskin ladataan client binäärinä mutta tällä hetkellä suorituskyvyt hukkautuisi siihen kun HTTP kyselyt tapahtuisi JS puolella kun se on vasta kehitysasteella webassemblyssä. Webassembly siis hidastaisi. Webassemly sitten on erittäin hyvä vaikka peleissä missä koko peli pyörii webassemblyssä ja piirtää canvasille, tai jos tekee jonkun moduulin mikä tekee raskaampaa laskentaa client puolella niin sen voi kääntää webassemblylle ja JS kutsuu sitä.

Eli itse tekisin niin että pääasiassa renderöisi tavaran palvelimessa mutta JS:ää voisi käyttää asiakaspuolella siihen että vähentää sivulatauksia. Esimerkiksi kun kirjoittaa viestin niin JS:llä lisää sen viestiketjuun samalla kun lähettää palvelimelle mutta ei sitten tee tähän turhaa sivulatausta.

Olennainen optimointi on se sivulatausten määrän vähentäminen mutta kun sieltä palvelimelta jotain tarvitsee ladata niin sivulataus itsessään ei ole ongelma vaan voi olla hyvinkin nopeata.

Suomi24:ssä sitten viestin lähetys mielestäni tekee sivulatauksen missä se kirjoitettu viesti tulee näkyviin niin tuo nyt tarpeettomasti tekee kuormaa joka viestinlähetyksessä.

Lue lisää

Itseäni houkuttaisi ajatus, että varsinaista sessionhallintaa ei olisi, vaan vain uusien viestien lisääminen (poistaminen yms.) vaatisi "kirjautumisen" toiminnon suorittamiseksi. Kirjautuminen edellä siis tarkoittaa vain käyttäjätunnuksen ja salasanan syöttämistä sen varmistamiseksi, että kyseisellä käyttäjällä on oikeus kyseiseen toimintoon. Mitään sessiota ei kuitenkaan muodostettaisi ja sama "kirjautuminen" pitäisi muodostaa vaikka heti perään, jos käyttäjä haluaa tehdä uuden lisäyksen tai poiston. Ehkäpä tämä "kirjautuminen" hoituisi käytännöllisemmin JavaScriptillä muodostettavalla yksittäisellä merkkijonolla, joka muodostettaisiin käyttäjätunnuksesta ja salasanasta, ja jota säilytettäisiin session ajan asiakaspäässä eli käytössä olisi tosiasiallisesti asiakaspään sessionhallinta. Tuo merkkijono pitäisi toki salakirjoittaa turvallisella tavalla, mikä puolestaan kävisi kätevimmin SSL-yhteyden kanssa, mikä taasen vaatisi oikean sessionhallinnan, ja hupsista, ollaan aika raskaassa järjestelmässä, ja ristiriidassa viestin ensimmäisessä lauseessa ilmaistun kanssa. :D Toki SSL-yhteyskin voisi olla uusi jokaista sivun latausta ja lähetystä kohti, vaan olisiko siinä sitten juurikaan järkeä...

Anonyymi kirjoitti:

"Rustilla tehdyt ongelmat ovat nopeudeltaan periaatteessa c:n luokkaa, joskin teoriassa mahdollistaa jopa nopeamman koodin"

Tarkoittanet OHJELMIA kuitenkin? Hyvä Rust-kääntäjä voi tuottaa koodia, joka vastaa nopeudeltaan C-kielestä käännettyä, uskon tämän. Mutta teoriasi jopa nopeammasta koodista on yhtä uskottava kuin raketti, joka lentää valoa nopeammin.

Lue lisää

Heh, toki; tiedä mistä 'ongelmat' tupsahti sijaan. Kun tarkemmin luin linkkaamaani artikkelia, niin pitänee tulkita niin päin, että teoriassa c:llä voi päästä samaan nopeuteen kuin Rustilla, mutta käytännössä kuka jaksaa viilata koodia niin pitkälle. Tekstissä https://kornel.ski/rust-c-speed kerrottiin lukuisia esimerkkejä tilanteista joissa Rust-koodi on nopeampaa, mutta oli mukana myös esimerkkejä niistä joissa Rust puolestaan ei ole vahvoilla. Tässä muutama esimerkki:

"Strings have their size encoded in their "fat" pointer. This makes length checks fast, eliminates risk of accidental O(n²) string loops, and allows making substrings in-place (e.g. splitting a string into tokens) without modifying memory or copying to add the \0 terminator."

"Like C++ templates, Rust generates copies of generic code for each type they're used with, so functions like sort() and containers like hash tables are always optimized for their type. In C I have to choose between hacks with macros or less efficient functions that work on void* and run-time variable sizes."

"Rust iterators can be combined into chains that get optimized together as one unit. So instead of a series of calls buy(it); use(it); break(it); change(it); mail(upgrade(it)); that may end up rewriting the same buffer many times, I can call it.buy().use().break().change().upgrade().mail() that compiles to one buy_use_break_change_mail_upgrade(it) optimized to do all of that in a single combined pass. (0..1000).map(|x| x*2).sum() compiles to return 999000."

"Similarly, there are Read and Write interfaces that allow functions to stream unbuffered data. They combine nicely, so I can write data to a stream that calculates CRC of the data on the fly, adds framing/escaping if needed, compresses it, and writes it to the network, all in one call. And I can pass such combined stream as an output stream to my HTML templating engine, so now each HTML tag will be smart enough to send itself compressed. The underlying mechanism is just a pyramid of plain next_stream.write(bytes) calls, so technically nothing stops me from doing the same in C, except the lack of traits and generics in C means it's very hard to actually do that in practice, other than with callbacks set up at run time, which isn't as efficient."

"These days everything seems to require JSON. Rust's serde is one of the fastest JSON parsers in the world, and it parses directly into Rust structs, so use of the parsed data is very fast and efficient, too."

Kommentteja valikoiden edellisii postauksiin.

Kirjoitit: "Olen ohjelmoinut C:llä 29 vuotta. Tunnen sen läpeensä."

Kommentointisi ei tue väitettä. C-kieli on helppo osata, mutta vaikea täysin hallita. Aina löytyy jokin uusi ahaa-elämys ja tämän totean ainakin yhtä pitkällä kokemuksella. Enkä voi vieläkään väittää tuntevani C-kieltä läpeensä ja siksi pyrinkin pitämään mieleni avoinna uusille näkökulmille ja jopa kritiikille.

Kirjoitit: "Ei lähdekoodia kirjoiteta tietokonetta varten vaan ihmisiä varten. [--] Suorituskyky kun ei ole tietokoneissa mikään ongelma."

Oikein ja väärin. Jos koodia täytyy ylläpitää tai uudelleenkäyttää, luettavuus on kaikki kaikessa. PC-ympäristössä suorituskyky harvoin on ongelma. Joskus kuitenkin on. Ja jos kirjoitat esimerkiksi uudelleenkäytettävää kirjastokoodia, huonon koodin suorituskyky voi nousta ongelmaksi arvaamattomalla tavalla myöhemmin. Sulautetussa maailmassa suorituskyky on aina huomioitava tekijä, koska rautaa ei haluta mitoittaa yhtään tehokkaammaksi eli kalliimaksi kuin on välttämätöntä.

Kirjoitit: "Syynä on yksinkertaisesti se, että C:llä ohjelmointi on sitä, että on varmistin pois päältä ja sillä voi ampua jalkaan."

En löytänyt pointtiasi. C on matalan tason ohjelmointikieli, siinä ei ole varmistinta. Rajattoman vallan mukana tulee vastuu, koodaajan täytyy tietää mitä tekee,

Kirjoitit: "Haskell sen sijaan evaluoi mitä tahansa lauseketta vasta silloin kun tarvitaan ja tuo tapahtuu automaattisesti."

C-kielessä koodaaja päättää mitä ohjelma tekee ja hyvä niin. Nykyiset kääntäjät ovat kuitenkin erittäin fiksuja ja jos annat kääntäjälle valtuudet esimerkiksi muuttaa suoritusjärjestystä, se toimii kokemusteni mukaan erittäin hyvin. Suoritusjärjestystä ei tietenkään saa muuttaa niin, että sillä on toiminnallista vakutusta tai edes sivuvaikutuksia. Esimerkiksi semaforin varaamisen ja jaettuun resurssiin sattumisen järjestystä ei pidä muuttaa. Kääntäjällähän ei välttämättä ole mitään tietoa tällaisten objektien luonteesta tai suhteesta toisiinsa.

En tunne Haskellia, mutta uskon, että lazy evaluation saattaa toimia tiettyjen järjestelmäresurssien kanssa, mutta merkittävää etua tästä optimoinnista on kovin vaikeaa nähdä.

Kirjoitit: "Ei C oikein kivasti esimerkiksi sovellu myöskään kaikentyyppisiin asioihin."

Tämä on päivänselvää. C-kielessä ja sillä koodaamisessa on heikkoutensa ja siksi meillä on laaja kirjo erilaisia haskelleita. Mutta keskustelumme lähti suoritustehokkuusnäkökulmasta, jos muistan, ja siinä suhteessa C-kielelle ei ole voittajaa. Extremistien assembleria lukuunottamatta.

Kirjoitit: "teoriassa c:llä voi päästä samaan nopeuteen kuin Rustilla".

Mitähän ovat tämän mielipiteen perustelut? Olisi hauska nähdä onko tässä vertailtu omenoita ja appelsiineja, mutta mikään tiedossani oleva ei tue väitettä.

Kirjoitit: ""Strings have their size encoded in their "fat" pointer. This makes length checks fast, eliminates risk of accidental O(n²) string loops, and allows making substrings in-place (e.g. splitting a string into tokens) without modifying memory or copying to add the \0 terminator.""

Merkkijonot voidaan toteuttaa monella tavoin. Kaksi tavanomaisinta tapaa ovat C-string ja P-string. Ensinmainitussa käytetään terminointimerkkiä ja jälkimmäisessä talletettua pituustietoa. Haskellissa on tietääkseni oma toteutuksensa (linkitetty lista), mutta kaikilla näillä on hyvät ja huonot puolensa, ei ole yksiselitteisesti yhtä voittajaa.

On totta, että C-string aiheuttaa tehottomuutta tietyisä tilanteissa. Esimerkiksi qsort() funktiota käytettäessä, jolloin jokaisen vertailuoperaation yhteydessä täytyy laskea toisen merkkijonon pituus. Tämä koskee mm. Intel-yhteensopivia prossuja, kun vertailu tehdään sinänsä tehokasta REP-käskyä käyttäen. Pituustieto tarvitaan ennen vertaluun ryhtymistä.

Jos sovellus käyttää runsaasti merkkijonoja, C-koodaajan tulee harkita käyttää P-string totetusta. Tässä onkin se C-kielen tehokkuuden salaisuus: ohjelmointikieli asettaa hyvin vähän rajoituksia. Koodaajalla on vapaus valita tehokkain tai nopein totetustapa tai mitä tahansa näiden väliltä.

C-standardi ei tunne merkkijonotyyppiä. On vain "array of char" ja sen terminointimerkillä varustettu muoto, jota standardikirjasto tukee. Mikään ei estä määrittelemästä omaa datatyyppiä, esimerkiksi...

typedef struct { size_t len; char s[]; } myString_t;

...ja sille funktioita. Jos merkkijono s[] talletaan edelleen C-string muodossa, saavutetaan lisäetua mm. merkkijonojen vertalussa. Tällöin esimerkiksi qsort() kutsuisi strcmp() funktion sijaan funktiota (tässä tapauksessa makroa):

#define myStrcmp(a,b) memcmp((a)->s, (b)->s, ((a)->len + 1) * sizeof(char))

Kirjoitit: ""Like C++ templates, Rust generates copies of generic code for each type they're used with, so functions like sort() and containers like hash tables are always optimized for their type [--]""

Tuo sekä muut vertailut C- ja Rust-kielen välillä ontuvat. Kielten suorituskyvystä oli kyse, kirjastojen kattavuus on eri asia.

Anonyymi kirjoitti:

Itseäni houkuttaisi ajatus, että varsinaista sessionhallintaa ei olisi, vaan vain uusien viestien lisääminen (poistaminen yms.) vaatisi "kirjautumisen" toiminnon suorittamiseksi. Kirjautuminen edellä siis tarkoittaa vain käyttäjätunnuksen ja salasanan syöttämistä sen varmistamiseksi, että kyseisellä käyttäjällä on oikeus kyseiseen toimintoon. Mitään sessiota ei kuitenkaan muodostettaisi ja sama "kirjautuminen" pitäisi muodostaa vaikka heti perään, jos käyttäjä haluaa tehdä uuden lisäyksen tai poiston. Ehkäpä tämä "kirjautuminen" hoituisi käytännöllisemmin JavaScriptillä muodostettavalla yksittäisellä merkkijonolla, joka muodostettaisiin käyttäjätunnuksesta ja salasanasta, ja jota säilytettäisiin session ajan asiakaspäässä eli käytössä olisi tosiasiallisesti asiakaspään sessionhallinta. Tuo merkkijono pitäisi toki salakirjoittaa turvallisella tavalla, mikä puolestaan kävisi kätevimmin SSL-yhteyden kanssa, mikä taasen vaatisi oikean sessionhallinnan, ja hupsista, ollaan aika raskaassa järjestelmässä, ja ristiriidassa viestin ensimmäisessä lauseessa ilmaistun kanssa. :D Toki SSL-yhteyskin voisi olla uusi jokaista sivun latausta ja lähetystä kohti, vaan olisiko siinä sitten juurikaan järkeä...

Lue lisää

No siis, JWT on keksitty. Haittansa siinäkin jos tokenin saa joku muu käsiinsä, että kaiksissa tilanteissa ei toimi.

Anonyymi kirjoitti:

Kommentteja valikoiden edellisii postauksiin.

Kirjoitit: "Olen ohjelmoinut C:llä 29 vuotta. Tunnen sen läpeensä."

Kommentointisi ei tue väitettä. C-kieli on helppo osata, mutta vaikea täysin hallita. Aina löytyy jokin uusi ahaa-elämys ja tämän totean ainakin yhtä pitkällä kokemuksella. Enkä voi vieläkään väittää tuntevani C-kieltä läpeensä ja siksi pyrinkin pitämään mieleni avoinna uusille näkökulmille ja jopa kritiikille.

Kirjoitit: "Ei lähdekoodia kirjoiteta tietokonetta varten vaan ihmisiä varten. [--] Suorituskyky kun ei ole tietokoneissa mikään ongelma."

Oikein ja väärin. Jos koodia täytyy ylläpitää tai uudelleenkäyttää, luettavuus on kaikki kaikessa. PC-ympäristössä suorituskyky harvoin on ongelma. Joskus kuitenkin on. Ja jos kirjoitat esimerkiksi uudelleenkäytettävää kirjastokoodia, huonon koodin suorituskyky voi nousta ongelmaksi arvaamattomalla tavalla myöhemmin. Sulautetussa maailmassa suorituskyky on aina huomioitava tekijä, koska rautaa ei haluta mitoittaa yhtään tehokkaammaksi eli kalliimaksi kuin on välttämätöntä.

Kirjoitit: "Syynä on yksinkertaisesti se, että C:llä ohjelmointi on sitä, että on varmistin pois päältä ja sillä voi ampua jalkaan."

En löytänyt pointtiasi. C on matalan tason ohjelmointikieli, siinä ei ole varmistinta. Rajattoman vallan mukana tulee vastuu, koodaajan täytyy tietää mitä tekee,

Kirjoitit: "Haskell sen sijaan evaluoi mitä tahansa lauseketta vasta silloin kun tarvitaan ja tuo tapahtuu automaattisesti."

C-kielessä koodaaja päättää mitä ohjelma tekee ja hyvä niin. Nykyiset kääntäjät ovat kuitenkin erittäin fiksuja ja jos annat kääntäjälle valtuudet esimerkiksi muuttaa suoritusjärjestystä, se toimii kokemusteni mukaan erittäin hyvin. Suoritusjärjestystä ei tietenkään saa muuttaa niin, että sillä on toiminnallista vakutusta tai edes sivuvaikutuksia. Esimerkiksi semaforin varaamisen ja jaettuun resurssiin sattumisen järjestystä ei pidä muuttaa. Kääntäjällähän ei välttämättä ole mitään tietoa tällaisten objektien luonteesta tai suhteesta toisiinsa.

En tunne Haskellia, mutta uskon, että lazy evaluation saattaa toimia tiettyjen järjestelmäresurssien kanssa, mutta merkittävää etua tästä optimoinnista on kovin vaikeaa nähdä.

Kirjoitit: "Ei C oikein kivasti esimerkiksi sovellu myöskään kaikentyyppisiin asioihin."

Tämä on päivänselvää. C-kielessä ja sillä koodaamisessa on heikkoutensa ja siksi meillä on laaja kirjo erilaisia haskelleita. Mutta keskustelumme lähti suoritustehokkuusnäkökulmasta, jos muistan, ja siinä suhteessa C-kielelle ei ole voittajaa. Extremistien assembleria lukuunottamatta.

Kirjoitit: "teoriassa c:llä voi päästä samaan nopeuteen kuin Rustilla".

Mitähän ovat tämän mielipiteen perustelut? Olisi hauska nähdä onko tässä vertailtu omenoita ja appelsiineja, mutta mikään tiedossani oleva ei tue väitettä.

Kirjoitit: ""Strings have their size encoded in their "fat" pointer. This makes length checks fast, eliminates risk of accidental O(n²) string loops, and allows making substrings in-place (e.g. splitting a string into tokens) without modifying memory or copying to add the \0 terminator.""

Merkkijonot voidaan toteuttaa monella tavoin. Kaksi tavanomaisinta tapaa ovat C-string ja P-string. Ensinmainitussa käytetään terminointimerkkiä ja jälkimmäisessä talletettua pituustietoa. Haskellissa on tietääkseni oma toteutuksensa (linkitetty lista), mutta kaikilla näillä on hyvät ja huonot puolensa, ei ole yksiselitteisesti yhtä voittajaa.

On totta, että C-string aiheuttaa tehottomuutta tietyisä tilanteissa. Esimerkiksi qsort() funktiota käytettäessä, jolloin jokaisen vertailuoperaation yhteydessä täytyy laskea toisen merkkijonon pituus. Tämä koskee mm. Intel-yhteensopivia prossuja, kun vertailu tehdään sinänsä tehokasta REP-käskyä käyttäen. Pituustieto tarvitaan ennen vertaluun ryhtymistä.

Jos sovellus käyttää runsaasti merkkijonoja, C-koodaajan tulee harkita käyttää P-string totetusta. Tässä onkin se C-kielen tehokkuuden salaisuus: ohjelmointikieli asettaa hyvin vähän rajoituksia. Koodaajalla on vapaus valita tehokkain tai nopein totetustapa tai mitä tahansa näiden väliltä.

C-standardi ei tunne merkkijonotyyppiä. On vain "array of char" ja sen terminointimerkillä varustettu muoto, jota standardikirjasto tukee. Mikään ei estä määrittelemästä omaa datatyyppiä, esimerkiksi...

typedef struct { size_t len; char s[]; } myString_t;

...ja sille funktioita. Jos merkkijono s[] talletaan edelleen C-string muodossa, saavutetaan lisäetua mm. merkkijonojen vertalussa. Tällöin esimerkiksi qsort() kutsuisi strcmp() funktion sijaan funktiota (tässä tapauksessa makroa):

#define myStrcmp(a,b) memcmp((a)->s, (b)->s, ((a)->len 1) * sizeof(char))

Kirjoitit: ""Like C templates, Rust generates copies of generic code for each type they're used with, so functions like sort() and containers like hash tables are always optimized for their type [--]""

Tuo sekä muut vertailut C- ja Rust-kielen välillä ontuvat. Kielten suorituskyvystä oli kyse, kirjastojen kattavuus on eri asia.

Lue lisää

"Kommentointisi ei tue väitettä. C-kieli on helppo osata, mutta vaikea täysin hallita. Aina löytyy jokin uusi ahaa-elämys ja tämän totean ainakin yhtä pitkällä kokemuksella."

No ei kyllä löydy. Sehän on hyvin yksinkertainen kieli.

Ja optimointijutut liittyen C:n on enemmänkin sitä hardware tason juttua että viilailee koodia toimimaan sen mukaan miten rauta toimii.

Itse C on niin yksinkertainen kieli että se on hyvin helppo hallita läpeensä.

"Ja jos kirjoitat esimerkiksi uudelleenkäytettävää kirjastokoodia, huonon koodin suorituskyky voi nousta ongelmaksi arvaamattomalla tavalla myöhemmin."

Nimenomaan ei tule. Tekemällä koodin siististi, sitä on helppo muuttaa jos jotain tarvetta tulee ja ei sitten käytä aikaa hinkkaamaan jotain yksittäisen osan suorituskykyä vaan keskittyy tekemään koko ohjelman siististi, valmiiksi ja pyrkiä virheettömyyteen.

Yleensä se suorituskyky ei vaan ole mikään ongelma kun valitsee työkalut ja tavat tilanteen mukaan ja tekee siististi ja välttää tekemästä jotain hölmöä. Hölmöydet huomaa juurikin silloin paremmin kun tekee siististi.

"Sulautetussa maailmassa suorituskyky on aina huomioitava tekijä, koska rautaa ei haluta mitoittaa yhtään tehokkaammaksi eli kalliimaksi kuin on välttämätöntä."

No just parhaillaan teen sulautettuun koodia. Pythonilla. Koska helpoiten valmiiksi ja tässä kohtaa ei tarvitse kun ei ole massatuotantoa. Kerätään kaikki vaatimukset ensiksi ennen kuin aletaan tekemään parempaa versiota.

"En löytänyt pointtiasi. C on matalan tason ohjelmointikieli, siinä ei ole varmistinta. Rajattoman vallan mukana tulee vastuu, koodaajan täytyy tietää mitä tekee,"

Se myös tarkoittaa sitä, että kääntäjän on käännettävä koodi sillä tavalla kuin ohjelmoija on sen kirjoittanut, tekemällä vaikka memcpy:llä joku hillitön kopiointi.

"Suoritusjärjestystä ei tietenkään saa muuttaa niin, että sillä on toiminnallista vakutusta tai edes sivuvaikutuksia."

Nyt alat päästä jäljille. Haskellissa ei oletuksena koodia kirjoitettaessa tule mitään sivuvaikutuksia muualla kuin tarkoin määritetysti, tyyliin niin että eristetään koodissa vaikka tiedoston käyttö.

Sitten kaikki mitä lasketaan niin kääntäjällä on vapaat kädet optimoida hurjilla tavoilla kun sillä on tieto, että ei ole sivuvaikutuksia. C:stä tämä puuttuu.

"Mutta keskustelumme lähti suoritustehokkuusnäkökulmasta, jos muistan, ja siinä suhteessa C-kielelle ei ole voittajaa. "

Kyllä on kun lähtökohtana on se, että kirjoitetaan softa siististi.

Siksi niinkin tavallisen asian kuin web servicen tekeminen onkin C:llä tehotonta kun ei ole niin optimoitua toteutusta.

Yksi suorituskykyyn vaikuttava asia on esimerkiksi roskien kerääjä, että se toimii joissakin tilanteissa nopeammin kuin manuaalinen muistinhallinta. C:llä ei järkevästi onnistu se, että kutsut free() silloin kun kone on idlellä. Roskien kerääjää käyttävillä kielillä runtime osaa tehdä tuota. Ihan puhtaassa yksinkertaisessa suorituksessakin Zig kääntää tehokkaampaa koodia.

Oikeasti C:n vahvuus ei ole suorituskyvyssä vaan se on ennemminkin siinä, että optimoidaan muistin käyttöä suorituskyvyn sijasta tehdään jotain sellaista jossa voi käyttää C:n vahvuuksia, kuten tietyntasoiset verifioinnit.

"Tässä onkin se C-kielen tehokkuuden salaisuus: ohjelmointikieli asettaa hyvin vähän rajoituksia. Koodaajalla on vapaus valita tehokkain tai nopein totetustapa tai mitä tahansa näiden väliltä."

Ja sitten on tavukoodivehkeitä optimoivat automaattisesti kohderaudalle....

Anonyymi kirjoitti:

No siis, JWT on keksitty. Haittansa siinäkin jos tokenin saa joku muu käsiinsä, että kaiksissa tilanteissa ei toimi.

Ahaa, eipä ole tullutkaan aiemmin varsinaisesti tuohon tutustuttua, muutoin kuin että eräs sessionhallintatekniikka kyseessä. Kiitoksia infosta.

Anonyymi kirjoitti:

Kirjoitit: "Tuota pitäisi arvioida niin, että kun kirjoittaa koodin mahdollisimman siististi että mikä se suorituskyky on silloin, eikä niin että kirjoitetaan koodista epäselvempää optimoimalla nopeutta."

Sinulla saattaa olla hyvää kokemusta Haskellista ja ehkä muistakin korkean tason ohjelmointikielistä. Mutta C-kielen tuntemuksesi ei vakuuta.

Koodista puheenollen, siisti on ylläpidon kannalta ilman muuta parempi kuin epäselvä. Siistillä C-koodilla vain ei ole mitään tekemistä suorituskyvyn kanssa. Äärimmäisen suorituskykyinen C-koodi voi olla supersiistiä ja vastaavasti siistiltä näyttävä koodi voi olla kelvotonta kökköä.

C-koodaajan täytyy yleensä tietää miten kääntäjä koodin tulkitsee. Esimerkiksi osoittimen käytöllä tietyssä tilanteessa versus indeksoinnilla saattaa olla merkittävä vaikutus lopputulokseen. Erityisen tärkeää tämä on sulautetuissa koodeissa, joissa resurssit ovat niukat. Jollei C-koodaaja osaa lukea kääntäjän tuottamaa listausta, kökköä syntyy väistämättä.

C on siis matalan tason ohjelmointikieli, "symbolinen assembler", joka häviää koodaamisen helppoudessa ja tuottavuudessa jokseenkin kaikille korkean tason ohjelmointikielille. Mutta parempaan, siis tehokkaampaan lopputulokseen - millä mittarilla tahansa - yltäviä ohjelmointikieliä on vain yksi: Assembler.

Ole ystävällinen ja kerro esimerkki vaikkapa Haskell-koodista, joka "rajusti optimoituna" tuottaa nopeammin toimivaa koodia kuin "selkeän näköinen C toteutus" niin osoitan mielelläni luulosi vääräksi. Pidetään koodi inhimillisessä mitassa kuitenkin.

Lue lisää

Delphillä homman saisi tehtyä tietoturvallisesti (esim: ei YHTÄÄN puskurin ylivuotohaavoittuvuutta, eikä toki SQL -pistoksia myöskään).

C:llä jos koodaat saman, niin taatusti mukaan tulee puskurin ylivuotohaavoittuvuuksia.
Eli jos koodaat C:llä, on vain ajan kysymys, milloin joku hakkeri löytää koodista puskurin ylivuotohaavoittuvuuden, jonka avulla hakkeri voi syöttää systeemiin omaa koodiaan suoritettavaksi.

Ja mikä hakkerin kannalta parasta: ns. "No Execute" flag prosessorissa ei auta tietoturvaa yhtään (toki se tekee hyökkäyksestä hieman vaativamman toteuttaa, mutta ei tee siitä mahdotonta).

Miksi?

Jos et tiedä miksi, niin tutustu aiheeseen "ROP = Return Oriented Programming".

Käsittääkseni joku on tehnyt ROP -skannerin, joka osaa etsiä systeemikoodista sellaisia osia, jotka voi lukuisilla RET -käskyillä linkittää toisiinsa, ja josta hakkeri voi koota haluamansa kokonaisuuden.

Onko tuo systeemi jo täysautomaattinen, vai vieläkö ollaan puoliautomaattisen tasolla, sitä en ole ehtinyt seurata.

Anonyymi kirjoitti:

Delphillä homman saisi tehtyä tietoturvallisesti (esim: ei YHTÄÄN puskurin ylivuotohaavoittuvuutta, eikä toki SQL -pistoksia myöskään).

C:llä jos koodaat saman, niin taatusti mukaan tulee puskurin ylivuotohaavoittuvuuksia.
Eli jos koodaat C:llä, on vain ajan kysymys, milloin joku hakkeri löytää koodista puskurin ylivuotohaavoittuvuuden, jonka avulla hakkeri voi syöttää systeemiin omaa koodiaan suoritettavaksi.

Ja mikä hakkerin kannalta parasta: ns. "No Execute" flag prosessorissa ei auta tietoturvaa yhtään (toki se tekee hyökkäyksestä hieman vaativamman toteuttaa, mutta ei tee siitä mahdotonta).

Miksi?

Jos et tiedä miksi, niin tutustu aiheeseen "ROP = Return Oriented Programming".

Käsittääkseni joku on tehnyt ROP -skannerin, joka osaa etsiä systeemikoodista sellaisia osia, jotka voi lukuisilla RET -käskyillä linkittää toisiinsa, ja josta hakkeri voi koota haluamansa kokonaisuuden.

Onko tuo systeemi jo täysautomaattinen, vai vieläkö ollaan puoliautomaattisen tasolla, sitä en ole ehtinyt seurata.

Lue lisää

"Delphillä homman saisi tehtyä tietoturvallisesti (esim: ei YHTÄÄN puskurin ylivuotohaavoittuvuutta, eikä toki SQL -pistoksia myöskään)."

Delphin käyttämä kieli ei millään tavalla estä SQL injektioita.

Eikä mitään foorumialustoja tehdä sen enempää C:llä kuin Delphillä, aivan vääriä työkaluja.

"Eli jos koodaat C:llä, on vain ajan kysymys, milloin joku hakkeri löytää koodista puskurin ylivuotohaavoittuvuuden, jonka avulla hakkeri voi syöttää systeemiin omaa koodiaan suoritettavaksi."

C:llä voi kirjoittaa verifioitua koodia missä ei ole mahdollista tapahtua puskurin ylivuotoja.

Kyllä Rustille IDE:jä on tehty varmaan lähemmäs 10kpl.