mingw-gcc:n hitauden syy paljastui - availee olemattomia tiedostoja ... esim cc1.exe.exe

Onhan se Helvettiä sinänsä! Mutta jotkut ei tiedä paremmasta!

On se sellaista tuskaa! Ei sitä uskoisi mutta kun käyttää jotai toimivaa OS:ää niin silloin huomaa miten ongelmallinen Windows on!

Onhan se kamala, jatkuvasti hypii jotain silmille, ei vaan mainoksia vaan ihan Windowsin tai edgen tai jonkun ohjelman ohjesivuja tai muita.
Windows 8 jäälkeen W7 hidastettiin oikeen huolella ennen w10 ilmestymistä, jotta w10 ei näyttäisi niin raskaalta, W11 on samaa luokaa raskaudeltaan mutta muistinkulutukseltaan ihan omaa luokaansa. W11 on otetty "moniajo pois" että se tuntuisi kevyemmältä.
Teet jotai työtä joka ottaa aikaa ja ajattelet mm lukea netistä uutiset silläaikaa.
Paska. se työ on sammutettu siellä takana eikä etene mihinkään kun sivu ei ole aktiivinen.

W11 ei kykene tekeen kuin yhtä asiaa kerrallaan!

Microsoft keskeytti Windows 11 -päivityksen automaattisen jakelun – ”Saattaa heikentää pc:n suorituskykyä rajusti”

Samalla se aiheuttaa lämmöntuottoa kun Windowsista tulee jatkuvasti raskaampi.
Levyllekin se kirjoitaa taukoamatta vaikket tekisi sillä mitään. Ei siis ihme että SSD paukahtaa.

BT ja Wlan on edeleen Windowsin ongelmalistalla, tahmaamisessa ja katkomisessa.
Kuvansumennus vaan jatkaa ja 4 ytimen ongelmaa ei saada korjattua.

Lisäksi windows ei lue ja kirjoita yhtäaikaa, edes että kopioisi levyltä toiselle.
Linuxit tekee niin että toista luetaan ja toista kirjoitetaan yhtäaikaa.
Windows ensin lukee ja sitten kirjoittaa. Ja se on hidasta.

Windowsilla tahkoaminen on muutosvastarintaa,.

Sellasita!

"Jos windowsin tiedostojärjestelmä on olemattomien tiedostojen kohdalla hidas, niin minkäs sille voi"

Kyse ei ole pelkästään esim. tekstitiedoston avaamisesta, vaan PROSESSIN luomisesta.
Ja tuo prosessin luominen on (suhteellisesti) hidasta.

Toki, jos yrittää suorittaa vaikkapa cc1.exe.exe, niin tuon luulisi olevan nopeaa, koska cc1.exe.exe -tiedostoa ei ole olemassa, ei olemattomalle EXE -tiedostolle tarvitse prosessiakaan luoda.

Mutta jos yritetään cc1.exe.bat tai cc1.exe.cmd, niin tuolle luodaan aina prosessi käyttäen cmd.exe - ja koska tuossa oikeasti luodaan prosessi, niin se ottaa aikansa.

prosessin luominen windowsissa on hitaampaa kuin linuxissa.

Sensijaan uuden säikeen luominen jo olemassaolevaan prosessiin windowsissa on erittäin nopeaa.

Linuxin kernelhän kärsii tässä tietynlaisesta myopiasta, eli linux kernelille prosessi ja säie on melkein sama asia (ainoa ero on siinä, että säie jakaa muistiavaruuden muiden saman prosessin säikeiden kanssa, mutta prosessi ei jaa muistiavaruuttaan).

Windowsissa säikeiden ja prosessien käsittely on täysin erilaista, eikä windowsissa ole tuollaista kummallista ongelmaa mikä linuxissa on.

Moni täällä kuvittelee, että linux = parempi kuin windows.

On tosiaan YKSI asia, missä linux on ihan oikeastikin parempi kuin windows, ja se on TCP/IP -pinon laadukkuus. Linuxissa on paremmin tehty TCP/IP -pino kuin windowsissa.

Oikeastaan kaikessa muussa nimenomaan windows on parempi kuin linux.
Aivan erityisesti muistinhallinta on asia, jonka Microsoft osaa erinomaisen hyvin.
Linuxissa taas koko muistinhallinta on surkea viritys.

Miksiköhän windowsissa ei tarvita OOM killeriä.

Windowsissa on asialliset muistinhallintafunktiot, kuten VirtualAlloc, VirtualFree, VirtualProtect jne.

Linuxissa teeskennellään, että C -kielen malloc() ja free() riitää kaikkeen.
No, tavallaan "riittää" mutta seuraukset ovat kaameat.
Linux kernel olettaa, että ohjelma käyttää vain pienen osan malloc():lla varaamastaan muistista.

JOS ohjelma varaa muistia PALJON käyttäen malloc() ja sitten ohjelma oikeasti käyttää kaiken malloc():lla varaamansa, linuxissa alkaa silloin OOM killer toimia.

Windowsissa osaava ohjelmoija ei tietenkään tee muistinhallintaa C -kielen malloc() ja free() -funktioilla, vaan käyttää VirtualAlloc, ja osaa käyttää oikein MEM_RESERVE ja MEM_COMMIT -lippuja.

Anonyymi kirjoitti:

"Jos windowsin tiedostojärjestelmä on olemattomien tiedostojen kohdalla hidas, niin minkäs sille voi"

Kyse ei ole pelkästään esim. tekstitiedoston avaamisesta, vaan PROSESSIN luomisesta.
Ja tuo prosessin luominen on (suhteellisesti) hidasta.

Toki, jos yrittää suorittaa vaikkapa cc1.exe.exe, niin tuon luulisi olevan nopeaa, koska cc1.exe.exe -tiedostoa ei ole olemassa, ei olemattomalle EXE -tiedostolle tarvitse prosessiakaan luoda.

Mutta jos yritetään cc1.exe.bat tai cc1.exe.cmd, niin tuolle luodaan aina prosessi käyttäen cmd.exe - ja koska tuossa oikeasti luodaan prosessi, niin se ottaa aikansa.

prosessin luominen windowsissa on hitaampaa kuin linuxissa.

Sensijaan uuden säikeen luominen jo olemassaolevaan prosessiin windowsissa on erittäin nopeaa.

Linuxin kernelhän kärsii tässä tietynlaisesta myopiasta, eli linux kernelille prosessi ja säie on melkein sama asia (ainoa ero on siinä, että säie jakaa muistiavaruuden muiden saman prosessin säikeiden kanssa, mutta prosessi ei jaa muistiavaruuttaan).

Windowsissa säikeiden ja prosessien käsittely on täysin erilaista, eikä windowsissa ole tuollaista kummallista ongelmaa mikä linuxissa on.

Moni täällä kuvittelee, että linux = parempi kuin windows.

On tosiaan YKSI asia, missä linux on ihan oikeastikin parempi kuin windows, ja se on TCP/IP -pinon laadukkuus. Linuxissa on paremmin tehty TCP/IP -pino kuin windowsissa.

Oikeastaan kaikessa muussa nimenomaan windows on parempi kuin linux.
Aivan erityisesti muistinhallinta on asia, jonka Microsoft osaa erinomaisen hyvin.
Linuxissa taas koko muistinhallinta on surkea viritys.

Miksiköhän windowsissa ei tarvita OOM killeriä.

Windowsissa on asialliset muistinhallintafunktiot, kuten VirtualAlloc, VirtualFree, VirtualProtect jne.

Linuxissa teeskennellään, että C -kielen malloc() ja free() riitää kaikkeen.
No, tavallaan "riittää" mutta seuraukset ovat kaameat.
Linux kernel olettaa, että ohjelma käyttää vain pienen osan malloc():lla varaamastaan muistista.

JOS ohjelma varaa muistia PALJON käyttäen malloc() ja sitten ohjelma oikeasti käyttää kaiken malloc():lla varaamansa, linuxissa alkaa silloin OOM killer toimia.

Windowsissa osaava ohjelmoija ei tietenkään tee muistinhallintaa C -kielen malloc() ja free() -funktioilla, vaan käyttää VirtualAlloc, ja osaa käyttää oikein MEM_RESERVE ja MEM_COMMIT -lippuja.

Lue lisää

Nettiselain on esimerkki parhaasta päästä ohjelmasta, jossa muistinhallinnalla on kriittinen rooli. Muistia käytetään paljon ja erikokoisia objekteja allokoidaan ja vapautetaan taajaan.

Jos esimerkiksi Firefoxin muistinhallinta perustuu C -kielen malloc()- ja free()-funktioiden käyttöön, en enää lainkaan ihmettele miksi selain toimii niin huonosti kuin se toimii.

VirtualAlloc() jne. eivät yksin ratkaisisi ongelmaa. Virtuaalimuistin sivut ovat liian isoja käytettäviksi yksittäisen objektin tallettamiseen.

Perustuu muistinhallinta virtuaalimuistin tai fyysisen muistin käyttöön, ongelma ratkeaa vain tehokkaalla muistinhallinta-algoritmilla, jolla muistin liiallinen pirstaloituminen estetään.

Jospa joku kirjoittaisi tuollaisen algoritmin mm. Firefoxiin, saisi ainakin täältä suuret kiitokset.

Anonyymi kirjoitti:

"Jos windowsin tiedostojärjestelmä on olemattomien tiedostojen kohdalla hidas, niin minkäs sille voi"

Kyse ei ole pelkästään esim. tekstitiedoston avaamisesta, vaan PROSESSIN luomisesta.
Ja tuo prosessin luominen on (suhteellisesti) hidasta.

Toki, jos yrittää suorittaa vaikkapa cc1.exe.exe, niin tuon luulisi olevan nopeaa, koska cc1.exe.exe -tiedostoa ei ole olemassa, ei olemattomalle EXE -tiedostolle tarvitse prosessiakaan luoda.

Mutta jos yritetään cc1.exe.bat tai cc1.exe.cmd, niin tuolle luodaan aina prosessi käyttäen cmd.exe - ja koska tuossa oikeasti luodaan prosessi, niin se ottaa aikansa.

prosessin luominen windowsissa on hitaampaa kuin linuxissa.

Sensijaan uuden säikeen luominen jo olemassaolevaan prosessiin windowsissa on erittäin nopeaa.

Linuxin kernelhän kärsii tässä tietynlaisesta myopiasta, eli linux kernelille prosessi ja säie on melkein sama asia (ainoa ero on siinä, että säie jakaa muistiavaruuden muiden saman prosessin säikeiden kanssa, mutta prosessi ei jaa muistiavaruuttaan).

Windowsissa säikeiden ja prosessien käsittely on täysin erilaista, eikä windowsissa ole tuollaista kummallista ongelmaa mikä linuxissa on.

Moni täällä kuvittelee, että linux = parempi kuin windows.

On tosiaan YKSI asia, missä linux on ihan oikeastikin parempi kuin windows, ja se on TCP/IP -pinon laadukkuus. Linuxissa on paremmin tehty TCP/IP -pino kuin windowsissa.

Oikeastaan kaikessa muussa nimenomaan windows on parempi kuin linux.
Aivan erityisesti muistinhallinta on asia, jonka Microsoft osaa erinomaisen hyvin.
Linuxissa taas koko muistinhallinta on surkea viritys.

Miksiköhän windowsissa ei tarvita OOM killeriä.

Windowsissa on asialliset muistinhallintafunktiot, kuten VirtualAlloc, VirtualFree, VirtualProtect jne.

Linuxissa teeskennellään, että C -kielen malloc() ja free() riitää kaikkeen.
No, tavallaan "riittää" mutta seuraukset ovat kaameat.
Linux kernel olettaa, että ohjelma käyttää vain pienen osan malloc():lla varaamastaan muistista.

JOS ohjelma varaa muistia PALJON käyttäen malloc() ja sitten ohjelma oikeasti käyttää kaiken malloc():lla varaamansa, linuxissa alkaa silloin OOM killer toimia.

Windowsissa osaava ohjelmoija ei tietenkään tee muistinhallintaa C -kielen malloc() ja free() -funktioilla, vaan käyttää VirtualAlloc, ja osaa käyttää oikein MEM_RESERVE ja MEM_COMMIT -lippuja.

Lue lisää

Windowsnistin paskanjauhantaa moinen linuxin mollaaminen!

Anonyymi kirjoitti:

Windowsnistin paskanjauhantaa moinen linuxin mollaaminen!

En usko, että windowsissakaan käytetään malloc:ia kernel-puolen kutsuissa - vaan siellä on joko Linuxia vastaava geneerinen kzalloc tai kernel taskin oma muistinvaraus.
Btw. OOM-Killerin ajoon tulo on lähinnä huolimattomuutta koodaajalta eli hän on aiheuttanut tilanteen, jossa koneesta on muisti loppunut - saa sen vapauttaakin!
Miksipä se windows luo prosessin, jos .cmd tiedostoa ei löydy? Siinä on selvä optimoinnin paikka.

Anonyymi kirjoitti:

En usko, että windowsissakaan käytetään malloc:ia kernel-puolen kutsuissa - vaan siellä on joko Linuxia vastaava geneerinen kzalloc tai kernel taskin oma muistinvaraus.
Btw. OOM-Killerin ajoon tulo on lähinnä huolimattomuutta koodaajalta eli hän on aiheuttanut tilanteen, jossa koneesta on muisti loppunut - saa sen vapauttaakin!
Miksipä se windows luo prosessin, jos .cmd tiedostoa ei löydy? Siinä on selvä optimoinnin paikka.

Lue lisää

"Miksipä se windows luo prosessin, jos .cmd tiedostoa ei löydy?"

Tästä syystä:

Windowsissa, kun prosessi A haluaa käynnistää vaikkapa jono1.BAT tai jono2.CMD, niin koska .BAT ja .CMD eivät kumpikaan ole binääriohjelmia, niin ongelmaksi tulee tämä:

Ensinnäkin, et voi ihan suoraan yrittää tätä: CreateProcess('jono1.BAT', ... );

Jos pitää käynnistää BAT -tiedosto omasta ohjelmastasi käsin, tähän on 2 keinoa:

joko:

1) CreateProcess('CMD.EXE', 'jono1.BAT', ... );
Tämä edellyttää, että oman ohjelman koodaaja itse ymmärtää, ettei BAT voi suoraan käynnistää prosessina, vaan avuksi tarvitaan CMD.EXE - samalla on hyvä selvittää, missä hakemistossa se CMD.EXE sijaitsee, ja antaa parametrina polkunimineen tuo CMD.EXE.

tai

2) Käyttää ShellExecute() eikä CreateProcess(). Tässä on omat haittapuolensakin, mutta ainakin olettaisi, että ShellExecute() on itse niin älykäs, että se itse ymmärtää tuon CMD.EXE:n tarpeen, joten ShellExecute():lle voi antaa parametriksi "jono1.bat" toisin kuin CreateProcess():lle, joka ei suoraan ymmärrä .bat tai .cmd -tiedostoja, vaan sille pitää itse kertoa, että käynnistetään itseasiassa CMD.EXE ja sille parametriksi joko /C jono1.bat tai /K jono1.bat. Molemmat tekevät muuten samaa, mutta erona on se, mitä tapahtuu, kun jono1.bat saadaan loppuun suoritettua. /C -optiolla myös CMD.EXE:n suoritus loppuu samalla, mutta /K -optiolla komentorivi-ikkuna jää auki ja sille voi manuaalisesti kirjoittaa näppäimistöltä uusia komentoja.

Mutta molemmissa tapauksissa: Vasta CMD.EXE itse huomaa, ettei parametrina annettua komentojonotiedostoa ole olemassa , mikä johtaa virheilmoitukseen.

Mutta käyttöjärjestelmällä itsellään ei ole erityistietoa CMD.EXE:n sisäisestä toiminnasta eikä komentojonoista, ja ShellExecutellakin on vain se rajoitettu tieto, että .BAT ja .CMD -loppuisia tiedostoja ei ajeta suoraan vaan CMD.EXE:n avulla.

Näinollen, ennen kuin CMD.EXE on jo käynnistynyt, mikää muu osa käyttöjärjestelmää ei ymmärrä komentojonoista mitään, joten CMD.EXE:n käynnistys on pakollista, löytyipä sitä haluttua komontojonotiedostoa tai ei löydy.

Ainoa, joka voisi korjata tilanteen, on se, että ohjelma A voisi itse tarkistaa, löytyykö komentojonotiedosto ennen kuin yrittää käynnistää CMD.EXE:n. Jos ohjelmoija ei ole tuota tarkistusta viitsinyt koodata ohjemaansa, niin hölmösti toimii !

Mutta:
Ihan samaa hölmöilyä (joskin eri tavalla) on myös Linuxissa.

Windowsissa, jos tekstitiedoston alussa ei ole BOM -merkkiä, niin merkkikoodauksen oletetaan olevan Windows-1252.

Ja jos ON BOM -merkki, koodaus on jokin UNICODE:n eri esitysmuodoista, ja mikä niistä, se päätellään siitä, miten tuo BOM -merkki itse on koodattu.

Aivan samoin *voisi* toimia linuxissakin, mutta ongelmana on se, että ilmeisesti Linus Torvalds ei halua näin toimia!

Siis, kun uudehkoissa linuxeissa moni tekstitiedosto on (mukamas) UTF-8 enkoodattua unicodea, niin komentokielitiedostot linuxissa voivat alkaa vaikkapa:

#!/bin/python

jos ko. skripti on koodattu pythonilla.

Mikään ei suoranaisesti estäisi sitä, etteikö LInux kerneliä voisi muokata siten, että perinteisen:

#!/bin/python


vaihtoehtona voisi olla myös:

<UTF-8 -enkoodattu BOM>#!/bin/python

ja tässäkin tapauksessa muokattu kernel osaisi käynnistää python -ohjelman ja antaa sille parametriksi ko. skriptitiedoston nimen.

Mutta tätä Linus Torvalds ei osaa/halua toteuttaa!

Muutenkin varoituksena teille, jotka kuvittelevat, että linux on kaikessa parempi:

Selittäkääpä, MIKSI linuxin "UTF-8" ei oikeasti ole se Unicode Consortiumin hyväksymä standardinmukainen UTF-8, vaan epämääräinen väärennös siitä, jota itse kutsun nimellä "Bastardized linux version of UTF-8".

JOS tiedoston sisältö on sellainen, että sen voisi tallentaa myös UCS-2 -enkoodauksella (standardin ISO/IEC 10646 mukaisesti), silloin tuo "Bastardized linux version of UTF-8" on käytännössä sama asia kuin se oikea UTF-8.

MUTTA:

Jos Unicode -tekstiä sisältävässä tiedostossa on YKSIKIN merkki, joka ei kuulu Basic Multilingual Planeen, silloin paljastuu, ettei linux käytä aitoa UTF-8 -enkoodausta, vaan sen sijasta "Bastardized linux version of UTF-8" -enkoodausta!

Esimerkiksi U+1084F -merkki (muistuttaa matematiikan "Unioni" -merkkiä, vaikka onkin yksi aramean kielen kirjoitusmerkeistä), aidolla UTF-8 -enkoodauksella tuo merkki esitetään silloin 4 tavun yhdistelmällä.

Mutta kun merkkikoodauksena onkin "Bastardized linux version of UTF-8", niin siinä tuo U+1084F -merkki enkoodataan standardinvastaisesti 6 tavun yhdistelmällä!

Miksi Linuxissa tuo asia on ollut jo yli 10 vuotta pielessä, eikä linuxkoodaajat saa (tai eivät halua) korjattua asiaa ?

Aidolla UTF-8 standardin mukaisella enkoodauksella kaikki UNICODE -merkit 0 .. U+10FFFF saadaan mahtumaan enintään 4 tavun yhdistelmään.

Nuo 6 -tavuiset enkoodaukset Basic Multilingual Planeen kuulumattomien merkkien osalta eivät ole osa aitoa UTF-8 enkoodausstandardia, vaan ovat linuxin oma kummajainen.