Hozzászólások
-
Bejegyzés
-
„-Os: nekem valahogy sokkal jobban bejött, mint az O2. Kisebb kódotállít elő, és nemigen észleltem még nagyobb progiknál sesebességkülönbséget.”
Hát, matematikai számítást igényő alkalmazásoknál (gimp, mplayer, stb) viszont lényegesebben lassabb az -Os.
Code:-ftree-vect-loop-version
Perform loop versioning when doing loop vectorization on trees. When a loop appears to be vectoriz-
able except that data alignment or data dependence cannot be determined at compile time then vector-
ized and non-vectorized versions of the loop are generated along with runtime checks for alignment or
dependence to control which version is executed. This option is enabled by default except at level
-Os where it is disabled.Forrás: man gcc
Érdemes ezt átnézni:
http://gcc.gnu.org/wiki/GCC_4.1_Projects„Ha vm86-os renccerhívásokat akarsz dos alatt futtatni, akkor valóban perverz vagy, mert ilyen nincsen, magadnak kell emulálni.
))) (Nyílván win98-cal kevered, ahol valóban vm86-ban fut a dos.)”
Ops, erről úgy vitatkozunk, hogy mindkét állítás igaz. Arra gondoltam, hogy – most nevezzük így – tisztán védett módba váltasz, amikor a valós módú dolgokat belecsapod egy VM86 taszkba (megfelelő deszkriptorok elkészítésével), és a processzor védett állapotban futtatja a 16 bites DOS-t. Igaz, nem írtam le pontosan mire gondolok. Szerintem az a perverzió, ha ebben az esetben egy 32 bites taszkból hívogatod a 16 bites „drájvereket”. Viszont – amire gondolsz – meg lehet hagyni a natív valós módot a DOS-nak, és gond nélkül lehet kapcsolgatni valós és védett mód között (ha jól tudom, az EMS és XMS membővítők is így működnek). Ezt nevezzük vegyes technikának.„Viszont, ha én elindítok egy programot (jelen esetben nyílván) valósmódban (majd átkapcsolok védett módba), ott indítok egy taskot, akkorszerintem az az eredeti os „keze alatt” dolgozik, mégha nem isközvetlenül. (Szerinted ez meg már nem az.)”
Azért gondolom így, mert a DOS-ban egy árva 386-os utasítás, vagy funkció sincs (task, prioritás, memvédelem). Szerintem a DOS-ban indított taszk analóg a virtualizációval meg a CPU emulációval (bochs). Az indított dolgoknak semmi köze az alaprendszerhez mert, architektúrálisan függetlenek (persze kommunikálhatnak).„Tehát a mondat helytálló:lehet taskot indítani.”
Ebben az értelemben igen.„Ha vm86-os renccerhívásokat akarsz dos alatt futtatni, akkor valóban perverz vagy, mert ilyen nincsen, magadnak kell emulálni.
))) (Nyílván win98-cal kevered, ahol valóban vm86-ban fut a dos.)”
Ops, erről úgy vitatkozunk, hogy mindkét állítás igaz. Arra gondoltam, hogy – most nevezzük így – tisztán védett módba váltasz, amikor a valós módú dolgokat belecsapod egy VM86 taszkba (megfelelő deszkriptorok elkészítésével), és a processzor védett állapotban futtatja a 16 bites DOS-t. Igaz, nem írtam le pontosan mire gondolok. Szerintem az a perverzió, ha ebben az esetben egy 32 bites taszkból hívogatod a 16 bites „drájvereket”. Viszont – amire gondolsz – meg lehet hagyni a natív valós módot a DOS-nak, és gond nélkül lehet kapcsolgatni valós és védett mód között (ha jól tudom, az EMS és XMS membővítők is így működnek). Ezt nevezzük vegyes technikának.„Viszont, ha én elindítok egy programot (jelen esetben nyílván) valósmódban (majd átkapcsolok védett módba), ott indítok egy taskot, akkorszerintem az az eredeti os „keze alatt” dolgozik, mégha nem isközvetlenül. (Szerinted ez meg már nem az.)”
Azért gondolom így, mert a DOS-ban egy árva 386-os utasítás, vagy funkció sincs (task, prioritás, memvédelem). Szerintem a DOS-ban indított taszk analóg a virtualizációval meg a CPU emulációval (bochs). Az indított dolgoknak semmi köze az alaprendszerhez mert, architektúrálisan függetlenek (persze kommunikálhatnak).„Tehát a mondat helytálló:lehet taskot indítani.”
Ebben az értelemben igen.„Azt sem értem, hogy minek a proci hozzá?”
Hát, a processzor itt nem CPU-t, hanem feldolgozót jelent. Mert pl. a ‘text processor’ sem célhardvert jelent.„Azt sem értem, hogy minek a proci hozzá?”
Hát, a processzor itt nem CPU-t, hanem feldolgozót jelent. Mert pl. a ‘text processor’ sem célhardvert jelent.Szakatt wrote:Én ezt javaslom alapos áttanulmányozásra.Köszönjük az értékes hozzászólást.
Szakatt wrote:Én ezt javaslom alapos áttanulmányozásra.Köszönjük az értékes hozzászólást.
bacsi2 wrote:Az alap-elképzelésem az volt, hogy a két futó program egymásnak interneten keresztül ad át string-eket.Ha már itt tartunk, erősen javaslom, rágd át at RPC (kb: távoli folyamatok kommunikációja) témakörét (pl. XML-RPC, de ez csak egy megvalósítás). Mert ha sikerül, akkor nem kell külön szerver, meg a kimenetek össze-vissza irányítása.
bacsi2 wrote:Az alap-elképzelésem az volt, hogy a két futó program egymásnak interneten keresztül ad át string-eket.Ha már itt tartunk, erősen javaslom, rágd át at RPC (kb: távoli folyamatok kommunikációja) témakörét (pl. XML-RPC, de ez csak egy megvalósítás). Mert ha sikerül, akkor nem kell külön szerver, meg a kimenetek össze-vissza irányítása.
Nem értem miért nem módostod a progit úgy, hogy parancssoros részeket meg a main részt (pas: progam deklarálás) beteszed egy commandline.pas (vagy cli.pas) fájlba, és azt fordítod le a többi forrással együtt CLI előállítására. A GUI-hoz meg írsz egy gui.pas fájlt (program deklarálás+GUI init/run/done) meg egy gui/ könyvtárat. A fordításnál meg kihagyod a cli.pas-t. Így egyszerűbb lenne, és nem kell foglalkozni a kimenet feldolgozásával. Ez 100%-ban platform független.
Vagy használhatsz meg multiplaformos konzol-kezelő libet, pl. a Qt libben van ilyen (C++).
))) (Nyílván win98-cal kevered, ahol valóban vm86-ban fut a dos.)”