Portál AbcLinuxu, 5. května 2025 23:01
17.11.2008 15:05
AsciiWolf | skóre: 41
| blog: Blog
/usr/lib/jvm/java-6-sun-1.6.0.07/jre/bin/java: ELF 64-bit LSB executable, x86-64Tak ti nevím...
BTW - pořád se nemohu zbavit dojmu, že jsem někde zahlédl nějaké udělátko, které umožňovalo spouště 32bit pluginy pod 64bit FF. Jen jsem si to nepoznačil a teď marně hledám (ale možná jsem si to jen popletl s IcedTea)
18.11.2008 14:14
Jardík | skóre: 40
| blog: jarda_bloguje
18.11.2008 14:18
Jardík | skóre: 40
| blog: jarda_bloguje
jo, jo. To je ono. Vyzkouším, zda to s tím pojede. Díky
17.11.2008 15:17
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
17.11.2008 15:25
randy | skóre: 21
| Hviezdoslavov
17.11.2008 19:33
xkucf03 | skóre: 49
| blog: xkucf03
18.11.2008 14:16
Jardík | skóre: 40
| blog: jarda_bloguje
18.11.2008 21:56
xkucf03 | skóre: 49
| blog: xkucf03
17.11.2008 19:04
vadimo | skóre: 14
| Liptovský Mikuláš
The following i386 packages will be installed: libcurl3 Installing libraries ... The following i386 packages will be installed: libnss3-1d Installing libraries ... The following i386 packages will be installed: libnspr4-0d Installing libraries ... “Installing Flash Player 10“
64bit Java browser plugin existuje uz pomerne davno a ako prvy sa objavil vo/pre FreeBSD 
17.11.2008 15:33
David Heidelberg | skóre: 46
| blog: blog_
17.11.2008 17:28
cezz | skóre: 24
| blog: dm6
17.11.2008 19:41
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
17.11.2008 23:20
qemu-i386 a kqemu?
17.11.2008 19:53
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
QEMU je úúúúžasně rychléTo je fakt, to už asi radši i ten swfdec nebo gnash, ale jde to a to je hlavní.
a KQEMU je pouze pro x86.Aha.
ale jde to a to je hlavní.Po pravdě řečeno si chůzi představuju jinak, než že v Linuxu na PowerPC budu emulovat i386, na kterém spustím Windows, do kterých si nainstaluji Flash a Operu, ve kterých se budu dívat na web. Jeden snímek videa nebo hry za dvě minuty mě vážně neuspokojuje.
17.11.2008 15:53
zr3zo
| blog: zr3zo_blog
| Žilina
17.11.2008 15:56
tsLnox | skóre: 31
| blog: Blog jednoho ukecaného Gentoolemana
| Žďár nad Sázavou
17.11.2008 16:03
zr3zo
| blog: zr3zo_blog
| Žilina
17.11.2008 20:52
otula | skóre: 45
| blog: otakar
| Adamov
Konečně funkční flash pro Konqueror. I když - na druhou stranu - aspoň mne doteď neotravovaly v Konqueroru žádné flashové reklamy, a když jsem flash potřeboval, spustil jsem FF nebo Operu ;)
17.11.2008 16:17
Jakub Lucký | skóre: 40
| Praha
17.11.2008 16:22
vogo | skóre: 34
| blog: "Skládat papír"
17.11.2008 16:33
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
17.11.2008 16:51
Rezza | skóre: 25
| blog: rezza
| Brno
17.11.2008 18:06
saly | skóre: 23
| blog: odi_et_amo
17.11.2008 21:31
saly | skóre: 23
| blog: odi_et_amo
17.11.2008 18:05
saly | skóre: 23
| blog: odi_et_amo
17.11.2008 18:11
David Watzke | skóre: 74
| blog: Blog...
| Praha
17.11.2008 18:15
saly | skóre: 23
| blog: odi_et_amo
17.11.2008 18:17
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
17.11.2008 18:23
saly | skóre: 23
| blog: odi_et_amo
17.11.2008 18:40
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
17.11.2008 18:42
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
17.11.2008 18:55
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
17.11.2008 18:55
David Watzke | skóre: 74
| blog: Blog...
| Praha
17.11.2008 19:21
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
.
17.11.2008 19:17
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
17.11.2008 19:24
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
17.11.2008 19:42
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
18.11.2008 11:06
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
18.11.2008 14:28
Jardík | skóre: 40
| blog: jarda_bloguje
18.11.2008 13:58
mkoubik | skóre: 5
| blog: lorem_ipsum
| Praha 8 - Bohnice
18.11.2008 14:26
Jardík | skóre: 40
| blog: jarda_bloguje
17.11.2008 18:41
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
No tak ono se do těch 4GB adresového prostoru počítá jak RAM, tak i paměť grafické karty a podobné věci.Ne tak úplně. Paměť grafické karty (po té změně) a podobné věci se musí vejít do 1GB (virtuálního) adresového prostoru. Společně s tím se tam musí vejít i paměť, kterou jádro spotřebovává samo pro sebe. U 256MB na grafice je to možná v pohodě, ale u 2×512MB ve SLI už zase tak v pohodě není.
Tou obezličkou myslíš PAE?V popisu toho API je to popsáno jako využití horní paměti - tipl bych si, že PAE se přitom používá, ale neručím za to.
Vsadím se, že "potenciální" nárůst výkonu zdaleka nevyrovná čas strávený rozcházením 32bitových aplikací a restartováním firefoxu :)Hmm, u mne je jedinou 32bit aplikaci Skype. A tomu stacilo jen dat potrebne 32bit knihovny a napsat wrapper, co mu pri startu zapne mikrofon a pri ukonceni ho opravdu ukonci.
17.11.2008 18:50
David Watzke | skóre: 74
| blog: Blog...
| Praha
Funguje to!
17.11.2008 19:14
David Heidelberg | skóre: 46
| blog: blog_
17.11.2008 19:22
Limoto | skóre: 32
| blog: Limotův blog
17.11.2008 20:47
Milan Vít | skóre: 23
| blog: about:linux
| Orlová
17.11.2008 19:27
Ilfirin | skóre: 32
| blog: ilfblog
| Liberec
Swfdec je v pohodě, přehraje téměř všechno a rychlost je jen o něco slabší, než u Flash playeru.Kéž bych s tebou mohl souhlasit. U mě to tvé "jen o něco slabší" znamenalo více než trojnásobné zpomalení (25% vs 87%).
17.11.2008 19:42
Konqui | skóre: 18
| blog: Konqui
| Rožnov pod Radhoštěm
17.11.2008 23:05
otula | skóre: 45
| blog: otakar
| Adamov
aneb co je horší - když to pojede pomalu nebo když to nepojede vůbec?Sice nevím, jak OSS implementace flashe, ale je celkem běžné, že programy, které se projevují tím, že jsou hrozně pomalé, zároveň žerou šílené systémové zdroje - potom může být lepší, když to nejede vůbec
17.11.2008 17:36
char *d1, *d2, *d3; //ukazatele na char[KONSTANTA]
for (a = 0; a < KONSTANTA;a++) {
d3[a] = d1[a] ^ d2[a];
}
vs. tohle:
quint64 a, i1, i2, y; //quint64 je neznaménkový 64bitový int
char *d1, *d2, *d3;
for (a = 0; a < KONSTANTA;) { // KONSTANTA je dělitelná nejméně 8
i1 = *((quint64 *)(d1+a));
i2 = *((quint64 *)(d2+a));
y = i1 ^ i2;
*((quint64 *)(d3+a)) = y;
a+=sizeof(quint64);
}
To první vypadá hezky a naprosto jasně je vidět, co to dělá, to druhé vypadá podivně, zběsile se tam přetypovává, je to delší a běží to sedmkrát rychleji, protože místo 8bitového AL se při počítání využije celý 64bitový RAX.
.
A bude to rychlejší třeba i na 32bitovém DSP?Přelož to pro 32bitový DSP a podívej se sám. Zkoušel jsem to pro 32bit i386, ale nějak se mi to nepodařilo přeložit. I tak bych ale řekl, že to rychlejší bude, pokud bude slušný překladač. XOR nemá žádné přenosy mezi bity, takže zpracovat 64bit slovo znamená zpracovat postupně 2 32bit slova. Furt by to mělo být o něco rychlejší, než brát to po 1 bytu.
Je to opravdu prasárna, protože výsledek optimalizace závisí na typu cílového procesoru.Radši budu provozovat programy, které obsahují takovouhle prasárnu, ale poběží rychle, než abych tu měl pomalé šmejdy, které mají čistý a úhledný kód. V tomto konkrétním případě bych navíc rád viděl cílový procesor, kde ten výsledek optimalizace bude horší, než původní varianta.
Další optimalizace by byla přičítat ve smyčce i d1, d2 a d3.
No můžeme vyhlásit soutěž, kdo napíše rychlejší XOR
Zkuste místo quint64 použít size_t, na 32 bit architektuře by to mělo být lepší než quint64, ale samozřejmě záleží na překladači.Co se týče řídící proměnné toho cyklu, tak tam určitě (při tom testu jsem to přehodil). Pokud jde o ty výpočetní proměnné, tak tam to tak žhavé není.
Pokud vyvíjíte pro amd64, tak ještě rychlejší to uděláte tím, že použijete SSE2, prefetch a sfence, ale to by muselo být opravdu kritické, a to není, že joNení a beztak nevím jak. (Chtělo by to něco jako SSE snadno a rychle)
Další optimalizace by byla přičítat ve smyčce i d1, d2 a d3.Jako takhle?
quint64 a, i1, i2, y; //quint64 je neznaménkový 64bitový int
char *d1, *d2, *d3;
for (a = 0; a < KONSTANTA;) { // KONSTANTA je dělitelná nejméně 8
i1 = *((quint64 *)(d1));
i2 = *((quint64 *)(d2));
y = i1 ^ i2;
*((quint64 *)(d3)) = y;
a+=sizeof(quint64);
d1+=sizeof(quint64);
d2+=sizeof(quint64);
d3+=sizeof(quint64);
}
Je to jedno, vygenerovaný kód je v obou případech stejný:
0x0000000000401310 <checksum+0>: xor %r8d,%r8d 0x0000000000401313 <checksum+3>: nopl 0x0(%rax,%rax,1) 0x0000000000401318 <checksum+8>: mov (%rsi,%r8,1),%rax 0x000000000040131c <checksum+12>: xor (%rdi,%r8,1),%rax 0x0000000000401320 <checksum+16>: mov %rax,(%rdx,%r8,1) 0x0000000000401324 <checksum+20>: add $0x8,%r8 0x0000000000401328 <checksum+24>: cmp $0x1000,%r8 0x000000000040132f <checksum+31>: jne 0x401318 <checksum+8> 0x0000000000401331 <checksum+33>: mov %rcx,%rax 0x0000000000401334 <checksum+36>: retqV obou případech dojde na adresování s offsetem, kde offset je zároveň řídící proměnná.
Chtělo by to něco jako SSE snadno a rychleTo chce zkusit, uvidíte, že na tom nic není
Něco takového vám udělá 128bitový XOR:
static inline void xor128(void* dest, const void* src)
{
__m128i t = _mm_loadu_si128(&((__m128i *)src)[0]);
_mm_storeu_si128(&((__m128i *)dest)[0], _mm_xor_si128(t));
}
Místo _mm_storeu_si128() lze použít lepší instrukce a místo _mm_loadu_si128() taky. Výhoda tohoto zápisu je ta, že vám to poběží jak na 32 bitech, tak na 64 bitech a nebudete mít problém ani s překladačem (gcc, msvc, icc bez problémů). Navíc MSVC při generování kódu pro x64 už neumožňuje asm{}, takže toto je jediná možnost.
Pokud jde o ty výpočetní proměnné, tak tam to tak žhavé neníOno asi hodně záleží na překladači. Pokud se udělá jen XOR, tak by to teoreticky na 32 bit architektuře měl rozložit na 2 instrukce (což je de fakto jemný loop unrolling), ale věřím, že existují překladače, které z toho těch instrukcí udělají víc;)
V obou případech dojde na adresování s offsetem, kde offset je zároveň řídící proměnnáV tom lepším případě by to tak mělo být, ale já jsem si nějak navykl nevěřit překladači, a tyto věci dělám už jen ručně
Něco takového vám udělá 128bitový XOR:Nějak se mi nepodařilo vygooglit, jak zajistit, aby _m128i nebyl pro gcc neexistující typ.
Ono asi hodně záleží na překladači. Pokud se udělá jen XOR, tak by to teoreticky na 32 bit architektuře měl rozložit na 2 instrukce (což je de fakto jemný loop unrolling), ale věřím, že existují překladače, které z toho těch instrukcí udělají víc;)Což byl důvod, proč jsem se pouštěl do disasemblování výsledku...
V tom lepším případě by to tak mělo být, ale já jsem si nějak navykl nevěřit překladači, a tyto věci dělám už jen ručněNo když vidím, co občas překladač je schopen vymyslet, tak se nedivím, u jednočipů to dost často dělám taky tak.
_m128i nebyl pro gcc neexistující typPozor
je to __m128i (2 podtržítka) a je potřeba includovat soubor <emmintrin.h>.
Pro SSE je potřeba zase <xmmintrin.h> a pro SSE3 <intrin.h> (MSVC) nebo <pmmintrin.h> (GCC).
Pokud chcete dokumentaci, tak docela dobrá se dá najít na MSDN.
Jedinný problém při používání intrinsics je, že pokud chcete například v gcc mít některý kód v MMX a některý v SSE, dává se do samostatných souborů, protože pro překlad pro MMX/SSE/... potřebujete nastavit flagy gcc.
Pokud budete mít problémy, klidně se ozvěte přes PM ať to tu nespamujem :)
PozorJasně, špatně jsem to sem opsal. Ve zdrojáku to bylo dobře.
a je potřeba includovat soubor <emmintrin.h>.To jsem hledal. Bohužel jsem hledal v
/usr/include a ono je to někde v /usr/lib/.../include, takže jsem nenašel.
Pokud chcete dokumentaci, tak docela dobrá se dá najít na MSDN.Koukám, ten příklad nahoře nešel přeložit a dokumentace na MSDN bylo první, co z Googlu vypadlo, když jsem mu zadal jméno té funkce.
Pokud budete mít problémy, klidně se ozvěte přes PM ať to tu nespamujem :)Nevykat, děkuji
Osobně dávám přednost - když už se tu něco začne řešit - tomu dořešit to tady, aby z toho měli něco i další zájemci.
Dopracoval jsem se k tomuhle kódu:
__m128i t1, t2;
unsigned int a;
for (a = 0; a < BLOCKSIZE/sizeof(__m128i); ) {
t1 = _mm_loadu_si128(&((__m128i *)d1)[a]);
t2 = _mm_loadu_si128(&((__m128i *)d2)[a]);
_mm_storeu_si128(&((__m128i *)d3)[a], _mm_xor_si128(t1, t2));
a += 1;
}
Funguje, trvá pouze 75% času oproti variantě uvedené výše, tedy zpracování po 64bitech. Hezké, děkuji.
(Hm, to, že něco funguje teď, neznamená, že to bude fungovat za všech okolností. Proto se radši ptám, nedělám takhle něco špatně?)
Kód je správně.
Ještě by se to dalo pekelně zrychlit, ale to už by ten kód asi trochu narostl. Pokud si budete jist, že ukazatel d3 je zarovnaný na 128 bitů, tak se místo _mm_storeu_si128() dá použít _mm_store_si128(). Tato instrukce by měla být rychlejší, protože jakoby garantujete zarovnání adresy. Pokud adresa není zarovnaná, vyhodí to nějaký signál (teď si ale nepamatuju jaký, dlouho se mi to nestalo:) ).
Pak existuje ještě jedna instrukce, která se dá použít místo _mm_storeu_si128() a to _mm_stream_si128(). Tato instrukce patří do kategorie "cache control" a je rychlejší než _mm_store_si128() v případě, že pracujete s daty, které se nevlezou do cache (ve zkratce, bude rychlejší ve většině podobných smyček). Po vykonání kódu je potřeba zavolat _mm_sfence().
Toto by mělo rychlejší:
static size_t mymin(size_t a, size_t b)
{ return a < b ? a : b; }
static void xorarray(
const uint8_t* d1, const uint8_t* d2, uint8_t* d3, size_t size)
{
if (!size) return;
// sse2 registers
__m128i t1, t2;
// loop register (ideally ecx/rcx)
size_t i;
// align to 128 bits
if ((size_t)d3 & 15)
{
i = mymin((size_t)d3 & 15, size);
size -= i;
do { *d3++ = *d1++ ^ *d2++; } while(--i);
}
// 128 bits per time
for (i = size/16; i; i--, d1 += 16, d2 += 16, d3 += 16)
{
t1 = _mm_loadu_si128((__m128i *)d1);
t2 = _mm_loadu_si128((__m128i *)d2);
_mm_stream_si128((__m128i *)d3, _mm_xor_si128(t1, t2));
}
// tail < 128 bits
for (i = size&15; i; i--)
{
*d3++ = *d1++ ^ *d2++;
}
// cleanup from SSE2 code
_mm_sfence();
}
PS: Napsal jsem to v prohlížeči, takže tam může být nějaká drobnost :)
PPS: To vykání je prostě zvyk :)
(Děkuji velice)
Funguje to dobře, na 16MB blocích je to o třetinu rychlejší
Když si zarovnám i vstupní data a použiju _mm_load_si128 místo _mm_loadu_si128, tak se to ještě o kapánek zrychlí - sice jenom o cca 5%, ale cenou za to je 45B paměti alokovaných navíc, což není tolik.
Jo, to se to optimalizuje, škoda jen, že to budu krmit datama z disku a procesor stejně bude trávit víc času čekáním než počítáním
Já jsem se MMX a SSE naučil, když jsem začal zrychlovat vykreslování grafiky, tam jsem schopen zrychlit průběh v některých případech i 4x. Největší zrychlení se ale koná na starších procesorech, které umí jen MMX, popřípadě 3dNow (tam je to zrychlení fakt paráda).
PS: Ještě mě napadlo toto:
static size_t mymin(size_t a, size_t b)
{ return a < b ? a : b; }
static void xorarray(
const uint8_t* d1, const uint8_t* d2, uint8_t* d3, size_t size)
{
if (!size) return;
// sse2 registers
__m128i t1_0;
__m128i t2_0;
__m128i t1_1;
__m128i t2_1;
// loop register (ideally ecx/rcx)
size_t i;
// align to 128 bits
if ((size_t)d3 & 15)
{
i = mymin((size_t)d3 & 15, size);
size -= i;
do { *d3++ = *d1++ ^ *d2++; } while(--i);
}
// 512 bits per time
for (i = size/64; i; i--, d1 += 64, d2 += 64, d3 += 64)
{
t1_0 = _mm_loadu_si128((__m128i *)(d1 + 0));
t2_0 = _mm_loadu_si128((__m128i *)(d2 + 0));
t1_1 = _mm_loadu_si128((__m128i *)(d1 + 16));
t2_1 = _mm_loadu_si128((__m128i *)(d2 + 16));
_mm_stream_si128((__m128i *)(d3 + 0 ), _mm_xor_si128(t1_0, t2_0));
_mm_stream_si128((__m128i *)(d3 + 16), _mm_xor_si128(t1_1, t2_1));
t1_0 = _mm_loadu_si128((__m128i *)(d1 + 32));
t2_0 = _mm_loadu_si128((__m128i *)(d2 + 32));
t1_1 = _mm_loadu_si128((__m128i *)(d1 + 48));
t2_1 = _mm_loadu_si128((__m128i *)(d2 + 48));
_mm_stream_si128((__m128i *)(d3 + 32), _mm_xor_si128(t1_0, t2_0));
_mm_stream_si128((__m128i *)(d3 + 48), _mm_xor_si128(t1_1, t2_1));
}
// 128 bits per time
for (i = (size&63)/16; i; i--, d1 += 16, d2 += 16, d3 += 16)
{
t1_0 = _mm_loadu_si128((__m128i *)(d1 + 0));
t2_0 = _mm_loadu_si128((__m128i *)(d2 + 0));
_mm_stream_si128((__m128i *)(d3 + 0 ), _mm_xor_si128(t1_0, t2_0));
}
// tail < 128 bits
for (i = size&15; i; i--)
{
*d3++ = *d1++ ^ *d2++;
}
// cleanup from SSE2 code
_mm_sfence();
}
Největší zrychlení se ale koná na starších procesorech, které umí jen MMX, popřípadě 3dNow (tam je to zrychlení fakt paráda).Takovej tu jeden mám, ale nepředpokládám, že bych pro něj ještě někdy něco psal.
PS: Ještě mě napadlo toto:To mi funguje pomaleji. Tipuju, že na překladač už je to příliš složité...
18.11.2008 14:32
Jardík | skóre: 40
| blog: jarda_bloguje
18.11.2008 03:25
the.max | skóre: 46
| blog: Smetiště
18.11.2008 07:07
belisarivs | skóre: 22
| blog: Psychobláboly
18.11.2008 14:39
Jardík | skóre: 40
| blog: jarda_bloguje
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.