Programujeme ve Visual Basic .NET - 24. díl - práce s textovými řetězci

ako zmenit kodovanie textu z unicode do inej kodovej stranky napr. CP852?

ď.

Nejprve musíte řetězec převést na jednotný formát, kterým je pole bajtů. K tomu potřebujete vědět jeho výchozí kódování.
Vzniklé pole bajtů převedete na řetězec pomocí cílového kódování.
 Function EncodeFromUnicode(ByVal srcValue As String, ByVal srcEncCode As Integer) As String
Dim sourceEnc As System.Text.Encoding = System.Text.Encoding.Unicode
Dim targetEnc As System.Text.Encoding = System.Text.Encoding.UTF8
Dim srcBytes() As Byte = sourceEnc.GetBytes(srcValue)
Dim encBytes() As Byte = System.Text.Encoding.Convert(sourceEnc, targetEnc, srcBytes)
Return targetEnc.GetString(encBytes)
End Function nebo takříkajíc jedním vrzem... str_852$ = Encoding.GetEncoding(852).GetString(Encoding.Convert(Encoding .Unicode, Encoding.GetEncoding(852), Encoding.Unicode.GetBytes(str_unicode$))))

Tady ta diskuze je komedie :o) To se musí nechat. :o) A ani na to není co víc řici :o) Hádat se zdali je lepší/rychlejší python nebo VB. Fakt komedie :o) Pane Machu Váš python na začátek vůbec není vhodný a ani VB. Vždycky se začíná od primitivních programovacích jazyků, které popíšou základní věci. Když pochopíte tyto prim. prog. jazyky může se jít trpve na python a VB, c++, C# a tak dále :o) Takže Vaše hádka, či jak to nazvat, je tu o ničem....

Hádat se zdali je lepší/rychlejší python nebo VB. Fakt komedie :o)
Ja se nehadam, ja naopak chci zjistit jak je Python rychly, jenze nikdo zrejme moji,
mimochodem, zcela trivialni, ukazku, kdy se na obrazovce pohybuje par ctverecku,
nedovede ve VB.NET implementovat. Tim padem je i jasne, ktery jazyk je lepsi.

Vždycky se začíná od primitivních programovacích jazyků
Nejprimitivnejsi bude zcela urcite asembler a na tom se vyuka zrovna nezacina.
Vyuka se zacina na co nejjednodusim jazyku a dovoluji si tvrdit, ze Python je
velmi jednoduchy jazyk.

Ale souhlasim s tim, ze to je komedie. Clovek nechtene narazi na jednu z rady slabin
VB.NET a je prekvapen tarka nadlidskym usilim to zmaskovat a odvest pozornost jinam .

Pane Mach, když tvrdíte, že je VB.NET pomalý a že je v něm problém rozpohybovat pár čtverečků, zajímalo by mě, proč tedy ignorujete ukázku, ze které vyplývá, jednak že to žádný problém není, druhak, že je nejméně 10x rychlejší, než ta Vaše a s nadlidským úsilím se snažíte odvést pozornost jinam.... 
 
Jak vidíte, že VB.NET má v prostředí DirectX efektivní nástroj, kterým může za vteřínu několikatisíckrát překreslit celou obrazovku a miliony sprajtů, takže ve využití VB.NET pro realtime grafiku problém opravdu nevidím. Základní algoritmus, jak vykreslit na obrazovku pole čtverečků k dispozici máte a pokud Vás zajímá přesná analogie Vaší ukázky, jistě v mém seriálu najdete dostatek podkladů pro to, abyste si ji zreprodukoval sám - pokud Vás to srovnání skutečně zajímá a nechcete jen provokovat.
 
Jelikož mi je jasné, že Vám libovolný počet ukázek a odkazů nezabrání, abyste jako kolovrátek do omrzení nevedl svou, nerad bych nadále působil dojmem, že budu na Váš povel ztrácet čas reprodukováním Vašich ukázek jen proto, abych dokázal, že VB.NET "na to má". Máte vše potřebné k tomu, abyste si to ověřil sám.
 
Co se příspěvku pana Daniela týče, nejste sám, kdo se touto diskusí baví a debatou o rychlosti Pythonu versus VB bych na tomto místě skutečně nerozváděl - ale zajímalo by mě, co tedy považujete za primitivní programovací jazyk, vhodný pro výuku začátečníků, když ne Beginner's All-purpose Symbolic Instruction Code?

Ja tu ukazku neignoruji, na ceske skole jsem ti na ni odpovedel .
Me to z te ukazky nepripada jako ze to neni problem, tato ukazka
s tou mou nema nic spolecneho, ani s nicim se tam nepohybuje.
Takze prosimte predved ve VB.NET to co chci a s nadlidskym usilim
neodvadej pozornost jinam .




Jak vidíte, že VB.NET má v prostředí DirectX efektivní nástroj,
kterým může za vteřínu několikatisíckrát překreslit celou obrazovku
a miliony sprajtů, takže ve využití VB.NET pro realtime grafiku
problém opravdu nevidím. Základní algoritmus, jak vykreslit na obrazovku
pole čtverečků k dispozici máte a pokud Vás zajímá přesná analogie Vaší
ukázky, jistě v mém seriálu najdete dostatek podkladů pro to, abyste si
ji zreprodukoval sám - pokud Vás to srovnání skutečně zajímá a nechcete
jen provokovat.
Dobre tvrzeni, ted uz jen to dokazat . Ane, pochopil jsi to dobre,
zajima me presna analogie me ukazky. Ale nepochopil jsi dobre, jestli
si myslis, ze ji napisu za tebe, nevim jestli to vubec jde, asi ne,
kdyz se tomu vyhybas .

Jelikož mi je jasné, že Vám libovolný počet ukázek a odkazů nezabrání,
abyste jako kolovrátek do omrzení nevedl svou, nerad bych nadále působil
dojmem, že budu na Váš povel ztrácet čas reprodukováním Vašich ukázek jen
proto, abych dokázal, že VB.NET "na to má". Máte vše potřebné k tomu,
abyste si to ověřil sám.
Jo, ten VB.NET musi mit hodne velky problem, co?

Co se příspěvku pana Daniela týče, nejste sám, kdo se touto diskusí baví
a debatou o rychlosti Pythonu versus VB bych na tomto místě skutečně nerozváděl
- ale zajímalo by mě, co tedy považujete za primitivní programovací jazyk,
vhodný pro výuku začátečníků, když ne Beginner's All-purpose Symbolic Instruction
Code?
Ano, bavi se nas tu urcite vic. Jak uz jsem psal, pro vyuku neni vhodny primitivni
jazyk, ale jednoduchy, a to je treba Python. BASIC byl zatracovany uz v dobe sve
slavy, kdy byl uprednostnovan Pascal, protoze BASIC vedl ke spatnym navykum a
spatnemu programatorskemu stylu. Dnes je BASIC uz uplne mimo hru.

Pokud se nepletu, uvedl jste, že..
Python sam (s psyco) je oproti velmi rychlemu C pomalejsi 3-4x a diky temto knihovnam se rozdil stira. ....Slusnej clovek by priznal omyl a porazku, jsem zvedav, jak se zachovas ty.
Toto jste uvedl zde, na Živě - ukázku v C/OpenGL (přesná analogii té Vaší, hýbe sprajty) máte rovněž zde. Na ceskaskola.cz máte obojí, ačkoliv jsem tam, ani zde rychlost Pythonu s VB.NET nesrovnával, je to zbytečné - VB je kompilovaný, Python interpretovaný jazyk. 
O to se spíše neustále snažíte Vy - zřejmě v domnění, že když Vám neprojdou zjevné nesmysly Python versus C, že zabodujete aspoň u VB.NET. Je to celkem zbytečné, rychlost .NET koresponduje s  C++ mnohem lépe, než Python.¨
 
Ale jelikož já jsem Vám zde žádnou ukázku VB.NET neslíbil, rád bych si přečetl Vaše vyjádření k ukázce v C/OpenGL, kterou jsem reagoval na Vaše výroky. A rád bych ho viděl tam, kde jste se dopustil citovaného výroku, tj. zde, v této diskusi na Živě.
Jak myslíte - ale řekl bych, že jste na tahu...
 
Dnes je BASIC uz uplne mimo hru.
To tvrdíte Vy, ale zkuste se nejprve seznámit s klony BASICu jako je PowerBASIC (klon Basicu výkonem srovnatelný s assemblerem pro numerické výpočty), RealBasic pro MacOS, nebo DarkBasic (klon Basicu určený pro vývoj 3D her pod DirectX, mimochodem velmi zajímavý produkt). A BASIC samozřejmě pokračuje dál ve makrech MS Officce, Corelu, AutoCADu, SoftImage, VBScriptu a ASP, čili platforma od LotusNotes po průmyslové mikrokontroléry - a samozřejmě VB a VB.NET v .NET i mono, což jsou oficiálně podporovaná a neobyčejně rozšířená prostředí, důkazem čehož je i existence seriálu na Živě.
 http://www.thefreecountry.com/compilers/basic.shtml, http://www.theopensourcery.com/vbclones.htm
 
Ještě bych ten Basic úplně neodepisoval...

Vazeni, dovolil bych si pozadat o takovou malou akvizici. Hledám někoho kdo by  ve Visual Basicu umel neco naprogramovat. Jednalo by se o databázi, která je vedena v Excelu a potřebuji pro ně další funkce, které standardní metodou v Excelu nedosáhnu. Nejakou korunu bych taky pustil. Kdyztak se mi prosím ozvete na mispulin@volny.cz.

takze, prosim ta vyhod ztoho pythona te dve funkcie (blit & display) a napis cislo.
totok:
http://www.silovytrojboj.sk/out/sprites.cpp
(mam tam len x, y a smer, povyhadzuj si vsetko navyse)
umna robi vc debug 750fps a release okolo 18000fps. (p4 3ghz)
(racej to netestujem z intel kompilerom, co je dost ina liga)

nepovazujem to sice za bohviejake objektivne porovnanie, ale.. ked teda chces.

Jsi spadl z visne? Tohle ma byt benchmark, ktery ma zjistit,
jak je na tom Python s grafickym vykonem oproti VB.NET. To se ma
zjistit tak, ze se na obrazovce 768x768 px rozhyba 20 000 sprajtu
10x10 px a zmeri se, kolikrat za vterinu se vsechny sprajty pohnou.

Nevadi ze to delas v C++, to bude take zajimave srovnani, melo by
to byt jeste rychlejsi nez VB.NET, ktery by mel byt rychlejsi nez
Python, otazkou je o kolik. Ty programy ale musi delat to same.
Pritom ty vubec, ale vubec nic na obrazovku nevykreslujes, natoz
abys s tim pohyboval, tudiz vubec netestujes graficky vykon, takze
je to k nicemu.

Uprav prosim svou ukazku v tomto duchu a jestli to v C++ nezvladnes
(bude to v pravdepodobne mnohem slozitejsi nez Pythonu, to je cena
za vykon), tak se do toho prosim neplet. Dekuji .

ach jaj

pises ze python je porad rychlejsi jak c/c++, mame tu priklad, dokazes vyhodit te tvoje dve funkcie a pustit to? je to asi velmi tazke ze. alebo ze by to bolo priserne pomale? to asi urcite ne.

preco tam nedavam grafiku - bavime sa o porovnani python a c/c++, strkat tam nake volanie grafickych funkcii ktore robia 99% casu, a zo samotnym interpreterom nemaju nic spolocne, je jak merat rychlost .bat intrepreteru vo windoze tak, ze zneho pustis 3 500megove aplikacie. totalna demagogia.

svou ukazku upravovat nehodlam z nasledovnych dovodov:
1. nic to neukaze - pretoze sa bude porovnavat rychlost grafickych funkcii, ale nie samotneho interpretera/compilera (ktorou sa tu ty ohanas, rychlu blit funkciu ti nikdo nebere)
2. predpokladam ze by bolo vhodne pustit to na tom istom pocitaci, tebe staci zobrat zdrojak a pustit nato gcc, ak tam pridam grafiku, budes mat problem to skompilovat.

a co sa tyka toho grafickeho vykonu - to snad srandujes? toto je podla teba graficka aplikacia? snad vtom neches napisat este aj renderer ne?

takze to zhrniem takto:
pouzivaj si dalej tu tvjou (s)hracku, ale nekydaj na c/c++, pretoze pises totalne nezmysli.

tento priklad sice neni nijak uzasny (sam som to napisal), ale ak by si dokazal vyhodit te dve funkcie, asi by sme videli jak je natom interpreter a poriadny kompiler. no, ono vacsina normalnych ludi tusi jak by to dopadlo, ale tak zi dalej v sne ze python je pouzitelny aj na nieco ine jak ctverecky.

Jurgene, jen chudaci jako tluchuba vkladaji nekomu do ust neco co nerekli, a pak
jim to v zapeti vyvraceji. Verim ze v tvem pripade slo jen o omyl, za ktery se
omluvis a nebude se to opakovat.

Ja nikde nepisu, natoz porad, ze Python je rychlejsi nez C. Ja se jen branim narceni,
ze je 30x pomalejsi nez Java, protoze neni 30x pomalejsi nez java. To je jedna vec.

Druha vec je, ze tluchuba oznacil Python jako nevhodny pro realtime grafiku. Ja sam
nevim jestli je nebo neni ve srovnani s VB.NET vhodny pro realtime grafiku. Proto jsem
udelal benchmark, ktery otestoval realtime graficky vykon dosazitelny v Pythonu a
chci, aby nekdo to same udelal ve VB.NET pro srovnani. Ja si tu ukazku stahnu a porvnam
ji u sebe na pocitaci. Ty po me chces, abych z neho vyhodil graficke funkce. Snad si
proboha uvedomujes, ze tim by to cele ztratilo smysl, ne?

Treti vec je, a vyplyva to z druhe veci, ze se nesnazim porovnat vykon interpretu samotneho.
Vykon interpretu samotneho byl totiz jiz porovnan a to nekolikrat, takze zajima-li te vykon
interpretu samotneho, podivej se na prispevky:

Autor: neregistrovaný - Petr Mach [160.218.40.xxx] Datum: 31.01.2005 12:50
Autor: neregistrovaný - Petr Mach [160.218.40.xxx] Datum: 31.01.2005 18:42

Napr. v pripade vypoctu cisla PI je Python 1,6x (a ne 30x) pomalejsi nez Java a 3,7x pomalejsi
nez optimalizovane C. V pripade horni ukazky, kdy bylo nekolik ruznych testu se ukazalo, ze
v jednom je Python nejrychlejsi, nekolikrat je na druhem miste a ani v jednom ze neni
nejpomalejsi. Interpretr samotny je tedy otestovan dostatecne a me ted zajima, jak je na tom
Python s reltime grafikou ve srovnani s VB.NET. Jsi schopen to pochopit a nebo ne?

ad 1.) ja chci porovnat rychlost grafickych funkci, chapes, chci zjistit, jak je Python
pouzitelny na realtime grafiku ve srovnani s VB.NET, protoze sam netusim, jak si na tom
v tomto ohledu stoji.

ad 2.) to nejen ze neni vhodne, to je nutne. Jestli budu mit problem to zkompilovat, pak
to budeme muset udelat naopak, budes Pythoni reseni muset vyzkouset ty. Python je
multiplatformni a dobre prenositelny, takze to nebude zadny problem.

a co sa tyka toho grafickeho vykonu - to snad srandujes?
Ne, to je test vykonu realtime grafiky.

akze to zhrniem takto: pouzivaj si dalej tu tvjou (s)hracku, ale nekydaj na c/c++, pretoze
pises totalne nezmysli.

Zklidni nervy a nejdriv si poradne precti co pisu, nez proti tomu zase budes protestovat.
Ja proti C a C++ nerekl ani slovo, C je muj oblibeny jazyk a s Pythonem je ve ve velmi uzkem
vztahu .

tento priklad sice neni nijak uzasny (sam som to napisal), ale ak by si dokazal vyhodit
te dve funkcie, asi by sme videli jak je natom interpreter a poriadny kompiler. no, ono
vacsina normalnych ludi tusi jak by to dopadlo, ale tak zi dalej v sne ze python je pouzitelny
aj na nieco ine jak ctverecky.

Ted uz to snad vis, ale benchmerk samotneho interpretu jiz probehl, takze tuseni neni potreba,
staci se podivat na vysledky . Takze prosim, implementuj moji ukazku se ctverecky, protoze
co se tyce grafickeho vykonu, tak prave zde nikdo netusi, vcetne me, jak na tom Python je a
chtel bych to zjistit, OK? A jestli to nesvedes, tak to neni zadna ostuda, nikdo neumi
naprogramovat vsechno, tak se kvuli tomu nerozciluj, OK?

> Ja nikde nepisu, natoz porad, ze Python je rychlejsi nez C.

porad v slovencine znamena "skoro". pisal si ze te tvoje pythony idu vniektorych pripadoch skoro tak rychlo jak cecko.

ale ved sa o tom mozme lahko presvedcit, staci ked vyhodis te dva riadky. nebudem sa ti ani smiat, slubujem. ale ved ty si si to urcite odkomentoval a dobre vies ze nemas 18000 fps, ani tretinu ztoho.

> Druha vec je, ze tluchuba oznacil Python jako nevhodny pro realtime grafiku.

a ma pravdu.

> Ja sam nevim jestli je nebo neni ve srovnani s VB.NET vhodny pro realtime grafiku.

ne neni. ono totiz aby nieco bolo vhodne na realtime grafiku, nestaci mat rychlu blit funckiu.

> Vykon interpretu samotneho byl totiz jiz porovnan a to nekolikrat, takze zajima-li te vykon interpretu samotneho, podivej se na prispevky:

a ked ta nakolenach poprosim, nenapises mi prosim prosim kolko fps daju ctverecky bez tych dvoch funcki? prosiiiiiiiiiiim.

> > a co sa tyka toho grafickeho vykonu - to snad srandujes?
> Ne, to je test vykonu realtime grafiky.

ne, to je test rychlost blit funckie.
ked som bol maly, naku realtime grafiku som kodoval, este na 386kach.. hadaj vcom sa to robilo? python alebo cisty assembler? dneska mame nastastie GPU, ale aj tak ti nestaci rychla blit funkcia nato, aby si nakodoval nieco zlozitejsie jak ctverecky. to zda sa nedokazes pochopit.

> Ja proti C a C++ nerekl ani slovo, C je muj oblibeny jazyk a s Pythonem je ve ve velmi uzkem vztahu .

a preco sa teda branis vyhodit te dve funckie aby si tu ten velmi uzky vztah demonstroval? to mi prosim vysvetli, zajima ma porovnanie vtomto pripade jak rychly je python oproti cecku, mozes mi urobit tu laskavost, vyhodit te dve funcie a napisat cislo? ponizene prosim.

> A jestli to nesvedes, tak to neni zadna ostuda, nikdo neumi naprogramovat vsechno, tak se kvuli tomu nerozciluj, OK?

ja sa nerozcilujem, ja len zasnem, to je rozdiel. dokazes ty odkomentovat te 2 riadky? grafiku tam pridat nedokazem, nesom taky dobry programator, mna len zajima jak je rychli python vtomto pripade (bez grafiky). OK?

To je jak mluvit do dubu .

porad v slovencine znamena "skoro". pisal si ze te tvoje pythony idu vniektorych pripadoch skoro tak rychlo jak cecko.
Ano, to je pravda, v nekterych pripadech ano.

ale ved ty si si to urcite odkomentoval a dobre vies ze nemas 18000 fps, ani tretinu ztoho.
Spatny predpoklad, nezkousel, ale vim ze to dopadne nepriznive, protoze se u kazdeho jazyka
budou porovnavat dve ruzne veci. Python diky sve dynamicke povaze musi pokazde k danemu prvku
najit cestu, protoze se muze kdykoliv zmenit, u statickeho C++ se to stat nemuze a tak k tomu
pristupuje primo.

Druha vec je, ze tluchuba oznacil Python jako nevhodny pro realtime grafiku.
a ma pravdu.

Mozna, ja to chci dokazat.



ne neni. ono totiz aby nieco bolo vhodne na realtime grafiku, nestaci mat rychlu blit funckiu.
Mozna, ja o chci ale dokazat, chc se presvedcit na vlastni oci .

a ked ta nakolenach poprosim, nenapises mi prosim prosim kolko fps daju ctverecky bez tych dvoch funcki? prosiiiiiiiiiiim.
Napisu, az mi nekdo predvede implementaci toho co chci ve VB.NET .

ne, to je test rychlost blit funckie.
ked som bol maly, naku realtime grafiku som kodoval, este na 386kach.. hadaj vcom sa to robilo? python alebo cisty assembler? dneska mame nastastie GPU, ale aj tak ti nestaci rychla blit funkcia nato, aby si nakodoval nieco zlozitejsie jak ctverecky. to zda sa nedokazes pochopit.
Jasne ze v assembleru dosahnes vyssiho vykonu, zvlast na 386 . Blit funkce neni vsechno
souhlasim, ale je to aspon neco ja to aspon neco chci videt ve VB.NET, zda se,ze to nejsi
schpen pochopit.



a preco sa teda branis vyhodit te dve funckie aby si tu ten velmi uzky vztah demonstroval?
to mi prosim vysvetli, zajima ma porovnanie vtomto pripade jak rychly je python oproti cecku,
mozes mi urobit tu laskavost, vyhodit te dve funcie a napisat cislo? ponizene prosim.

V tomto pripade bude Python pomaly, protoze se bude jednat o test mezi dynamickym a statickym
pristupem k prvkum, kdy se staticky a dynamicky jazyk chovaji rozdilne, ale ja chci otestovat
graficky vykon.



ja sa nerozcilujem, ja len zasnem, to je rozdiel. dokazes ty odkomentovat te 2 riadky?
grafiku tam pridat nedokazem, nesom taky dobry programator, mna len zajima jak je rychli
python vtomto pripade (bez grafiky). OK?


Ty jsi otrava .-), tak tu svou ukazku zatim urav tak, aby bylo mozno ji prelozit na linuxu,
tj. nepouzivej conio.h a mereni casu udelej s presnosti aspon na milisekundy, ne sekundy,
to je prilis hrube zaokrouhlovani. OK?

> Spatny predpoklad, nezkousel, ale vim ze to dopadne nepriznive, protoze se u kazdeho jazyka
budou porovnavat dve ruzne veci. Python diky sve dynamicke povaze musi pokazde k danemu prvku
najit cestu, protoze se muze kdykoliv zmenit, u statickeho C++ se to stat nemuze a tak k tomu
pristupuje primo.

vyborne, takze mozme python uzavret ako absolutne nevyhovujuci jazyk na programovanie nieco zlozitejsieho jak ctverecky.

> Jasne ze v assembleru dosahnes vyssiho vykonu, zvlast na 386 .

no a kedze iste uznas ze cecko z dobrym kompilatorom ma k assembleru dost blizko, hlavne oproti nakemu interpreteru, mozes si sam odpovedat na otazku jak je python vhodny na realtime veci.

> tak tu svou ukazku zatim urav tak, aby bylo mozno ji prelozit na linuxu,
tj. nepouzivej conio.h a mereni casu udelej s presnosti aspon na milisekundy, ne sekundy, to je prilis hrube zaokrouhlovani. OK?

http://silovytrojboj.sk/out/sprites_linux.cpp
aj ked gcc nepovazujem zrovna za najlepsi kompilator na svete (ak to musi byt vlinuxe, odporucam intel kompiler, na nekomercne veci je zdarma), ale aj tak to z vykonom pythonu moc v sulade nebude.
(o zaokruhlovanie sa neboj, myslim ze nake desatinky vtomto pripade rozhodne nebudu hrat rolu )

bez toho kbhitu(), trva umna 500000 frames 23sekund a zhruba 21800 fps.
(v linuxe z g++ to bolo zhruba opolovicu pomalsie)

python uzavret ako absolutne nevyhovujuci jazyk na programovanie nieco zlozitejsieho jak ctverecky
Přesněji je tomu tak, že s dobrou grafickou knihovnou na výkonu jazyka nezáleží. Realtime 3D grafiku lze skriptovat i v ActionSriptu ve ShockWave nebo VBScriptu pro DirectAnimation.
 
http://vbnet.aspweb.cz/msie/laser.htm, http://vbnet.aspweb.cz/msie/tree.htm
 
V případě DirectAnimation ta knihovna zajišťuje veškerou 3D grafiku, včetně timeru renderovací smyčky. Je zřejmé, že za takových podmínek není benchmark žádným kritériem výkonu překladače jazyka, ani jeho vhodnosti pro tvorbu nativní realtime 3D grafiku - je to v nejlepším případě benchmark jazyka, ve kterém byla napsána ta knihovna.
Jestli by mě něco zajímalo, tak spíše srovnání gcc a toho překladače od Intelu. Bylo by možné to porovnat pro C ukázku (samozřejmě bez volání těch knihoven)?

> Přesněji je tomu tak, že s dobrou grafickou knihovnou na výkonu jazyka nezáleží. Realtime 3D grafiku lze skriptovat i v ActionSriptu ve ShockWave nebo VBScriptu pro DirectAnimation.

zalezi odtoho co si prectavujeme pod pojmom realtime 3d grafika. ak to ma byt tociaca kocka alebo ctverecky, ano, urcite sa da pouzit aj skript, ale pokial sa bavime o nakom slusnom 3d engine, nemusi to byt ani doom3, staci aj 3 roky stara hra, pouzivat nieco jako python je.. nevhodne.

> Jestli by mě něco zajímalo, tak spíše srovnání gcc a toho překladače od Intelu. Bylo by možné to porovnat pro C ukázku (samozřejmě bez volání těch knihoven)?

intel kompiler si mozte stahnut zde:
http://www.intel.com/software/products/compilers/index.htm

do windozu je len mesacna evaluation verzia a komercna, do linuxu je aj "free non-comercial" verzia:
http://www.intel.com/software/products/noncom/

benchmarkov je plno, nake starsie namatkovo napr:
http://www.open-mag.com/754088105111.htm
http://www.simulanalog.org/compiler.htm
http://www.willus.com/ccomp_benchmark.shtml?p11

z praxe mozem povedat ze gcc kod je najpomalsi, visual c/c++ je gut, niekedy dokonca lepsi jak icc, ale vacsinou icc generuje najrychlejsi kod, casto podstatne rychlejsi.

tak se do toho prosim neplet...
Já s Vámi v zásadě souhlasím, pane Mach. Pokud máte potřebu dokázat, že je Python rychlejší než VB.NET nebo C/C++, prostě odpovídající benchmarky vyrobte, publikujte a podrobte je veřejné diskusi sám - a nezatěžujte tím ostatní - tím spíš ty, kterým to chcete dokázat. 
Vidíte sám, že vaše příklady, používající SDL jsou do jiných prostředí v podstatě nepřenositelné. A pokud chcete naznačit, že příklad odpovídající pygame/SDL v C by byl mnohem složitější, myslím, že třeba DirectX by se Vám v Pythonu nejspíš také neprogramovalo úplně snadno.
 
Testovat rychlost a efektivitu jakéhokoliv skriptovacího jazyka na proprietárních knihovnách je zkrátka nesmysl. Jeslti mi nevěříte, zkuste v Pythonu pro změnu odladit podobnou aplikaci, jako je např. zde http://vbnet.aspweb.cz/msie/sound.htm. Ta aplikace je napsána ve VBScriptu a dokud mi nepředvedete něco rychlejšího, mohu stejně jako Vy s klidem tvrdit, že ten hloupý VBScript je mnohem rychlejší, než Python.
 
Mě osobně bude úplně stačit, když mi nalinkujete aspoň tři benchmarky, podle kterých je Python srovnatelně rychlý, jako C. Do té doby je zbytečné vykřikovat, že všechny testy na webu jsou špatné, jelikož nedokazují Vaše představy.

Já s Vámi v zásadě souhlasím, pane Mach. Pokud máte potřebu dokázat, že je Python
rychlejší než VB.NET nebo C/C++, prostě odpovídající benchmarky vyrobte, publikujte
a podrobte je veřejné diskusi sám - a nezatěžujte tím ostatní - tím spíš ty, kterým
to chcete dokázat.

Tuto potrebu nemam, uz proto, ze to neni pravda. Mam ale potrebu odmitnout tve nepravdive
tvrzeni, ze Python je 30x pomalejsi nez Java, ktere dokladas benchmarky jenz obsahuji
hrube chyby a na tyto chyby poukazuji. Rozumny clovek na tvem mist by rekl, jo, ty
benchmarky jsou fakt blbost a ten Python je rychlejsi, nez jsem si myslel. Protoze nedovedes
priznat omyl a trvas stale na tom, ze Python je 30x pomalejsi (i kdyz ted uz pro jistotu
uvadis C a ne Javu), ja stale trvam na tom, ze to neni pravda, to je cele.

Vidíte sám, že vaše příklady, používající SDL jsou do jiných prostředí v podstatě
nepřenositelné.

To tedy nevidim, Python je multiplatformni a pouzite knihovny taktez. Ve skutecnosti diky
menevrstve architekture windows by to na windows melo byt jeste rychlejsi, nez u me na
linuxu. Oproti tomu se domnivam, ze tve resenive VB.NET, dockam-li se ho nekdy, bude
neprenosne absolutne. Budiz to vnimano jako dalsi klad Pythonu.

A pokud chcete naznačit, že příklad odpovídající pygame/SDL v C by byl mnohem
složitější, myslím, že třeba DirectX by se Vám v Pythonu nejspíš také neprogramovalo
úplně snadno.

Nic takoveho nenaznacuju, tohle je snad vsem jasny jako facka. Python je jednoduchy
jazyk a i slozite veci se v nem delaji pomerne jednoduse. Kdyz to nebude nikdo popirat,
nemam potrebu to nekomu dokazovat ci jen tak otloukat o hlavu. Jak by se mi programovalo
v DirectX nevim. Je-li pristupne pres COM, predved ukazku ve VB.NET a ja ji zkusim emulovat
v Pythonu.

Testovat rychlost a efektivitu jakéhokoliv skriptovacího jazyka na proprietárních knihovnách
je zkrátka nesmysl.

Ale samozrejme ze ma. Ma to ten samy smysl, jako testovat rychlost a efektivitu jakehokoli
jazyka s knihovnama. Uzivateli vysledne aplikace je jedno v cem je aplikace napsana a proc
je rychla nebo pomala, jeho zajima vysledek a jak se mu dobre pouziva. A Python ma dnes v
tomto smeru co nabidnout.

Jeslti mi nevěříte, zkuste v Pythonu pro změnu odladit podobnou aplikaci, jako je
např. zde http://vbnet.aspweb.cz/msie/sound.htm. Ta aplikace je napsána ve VBScriptu
a dokud mi nepředvedete něco rychlejšího, mohu stejně jako Vy s klidem tvrdit, že ten
hloupý VBScript je mnohem rychlejší, než Python.

Ja zadnou aplikaci nevidim, jenom obrazek. Tvrdit muzes cokoli, to nic neznamena. Vem
si priklad ze me, ja nerikam ze je VB.NET pomaly, ja chci, abys predvedl funkcni ukazku,
abychom vykon mohli porovnat. Ta ukazka je trivialni, cloveku, ktery se chlubi tim, ze
chce ve VB.NET vyucovat realtime grafiku by nemela delat sebemensi problem. Jestlize ji
odmitas ukazat, vysvetluji si to tim, ze to pro VB.NET vypada tezce nepriznive, presto
neprohlasuji, ze je VB.NET pomalejsi nez Python, nemam to nicim podlozeno.

Mě osobně bude úplně stačit, když mi nalinkujete aspoň tři benchmarky, podle kterých
je Python srovnatelně rychlý, jako C. Do té doby je zbytečné vykřikovat, že všechny testy
na webu jsou špatné, jelikož nedokazují Vaše představy.

Benchmarky jsem ti sem dal osobne. O tech tvych nevykrikuji ze jsou spatne, protoze nevyhovuji
mym predstavam, ale protoze v nich jsou chyby. Chyby jsem konkretne identifikoval, odstranil
a provedl benchmarky znova a vysledky hovori v muj prospech. Kdkoli ma zajem si to muze sam
overit. Je zbytecne rikat, ze to je zbytecne, zadny soudny clovek ti na to neskoci.

Rozumny clovek na tvem mist by rekl...
Ty benchmarky byly čtyři, ve všech byl Python zdaleka poslední a rozumný člověk by si řekl, tak mi najděte lepší becnhmarky - a to jsem udělal.
Víte, pane Mach  já si myslím, že kdyby jste je měl k dispozici, tak by jste to už dávno vítězoslavně nalinkoval. Problém je, že se snažíte dokázat (zatím neúspěšně) na grafických knihovnách a dalších detailech, že Python je srovnatelně rychlý, jako C - ale přehledové benchmarky podobného typu na webu nenajdete, protože by jejich autor byl okamžitě po právu komunitou vývojářů C/Java/Net s posměchem vypráskán. Takže Vám nezbývá, než se tu snažit dokázat nedokazatelné a pracně vymýšlet případy, které by Vám ten důkaz usnadnily.  
Benchmarky jsem ti sem dal osobne.
V odborné praxi nemůžete svoje tvrzení dokazovat vlasntími experimenty, ale citacemi. O ty jsem Vás žádal, zatím neúspěšně.
 
Ja zadnou aplikaci nevidim, jenom obrazek. Tvrdit muzes cokoli, to nic neznamena.
Přesně tak a právě proto ani mě nezajímají Vaše obrázky a tabulky. Je zajímavé, jak odmítáte chápat přesně to, co požadujete ode mě...
 
Python je jednoduchy jazyk ... kdyz to nebude nikdo popirat, nemam potrebu to nekomu dokazovat ci jen tak otloukat o hlavu...
 Vy jste před časem prohlásil "Nemam problem se vyznat treba v 20 KB zdrojaku PHP, ale v 5 KB zdrojaku Pythonu ano".
Mohu Vám to tedy jen tak otlouct o hlavu?
 
Python je 30x pomalejsi nez Java 
Dobrá, dokažte mi citacemi, že to není pravda. Tvrdit můžete co chcete, vezměte si příklad ze mě...

Mimochodem 20 000 sprajtu velkych 10x10 px pri 18 000 fps predstavuje
datovy tok 36000000000 = 36 GPix/s. U 3 GHz procesoru to znamena prenos
12 pixelu (36 B) na jeden takt procesoru, to je vskutku pozoruhodne.

co to meles? kdo tu hovori ze je to 18000 fps z grafikou?

Pygame je wrapper SDL, který pracuje s GPU, podobně jako knihovny DirectX nebo OpenGL, které pracují přímo s videopamětí, datový tok zajišťovaný procesorem představuje jen tok GPU instrukcí.
Popravdě řečeno, nevím proč testovat nějaký wrapper pro SDL jen proto, že byl portován do Pythonu.

Ano to je pravda, to je v souladu s mym tvrzenim, ze Python pouziva
na vykonove narocne veci knihovny napsane v C a dosahuje tak odpovidajicich
tvrzeni. To je dukaz, ze neni pravda, ze Python je 30x pomalejsi oproti
jinym jazykum. Python sam (s psyco) je oproti velmi rychlemu C pomalejsi
3-4x a diky temto knihovnam se rozdil stira.

Popravdě řečeno, nevím proč testovat nějaký wrapper pro SDL jen proto,
že byl portován do Pythonu.

Abys dokazal, ze VB.NET je rychlejsi nez Python a narozdil od nej se hodi
na realtime grafiku. Vzhledem k tomu jak se cukas a nechapes se zda, ze je
to naopak a Python je rychlejsi nez VB.NET . Prizne barvu, kolikrat je
rychlejsi?

Python sam (s psyco) je oproti velmi rychlemu C pomalejsi 3-4x a diky temto knihovnam se rozdil stira.
C/OpenGL verze Vašeho programu je zde - vidíte, že není ani nijak zvlášť delší ani složitější, než Pythoní zdroják.
btw Číslo nahoře je FPS (cca 35x rychlejší, než uvádíte pro Python). Myslím, že si pěkně vymýšlíte.
 

 
 #include <glut.h>
#include <stdlib.h>
#include <time.h>
static int t, it = 0, iSize = 500;
static int x[20000], y[20000], dx[20000], dy[20000]; char cIter[20];
static void display() {
glClear(GL_COLOR_BUFFER_BIT);
for(int i = 0; i < 20000; i++){
glColor3f((GLfloat) rand() / RAND_MAX, (GLfloat) rand() / RAND_MAX, (GLfloat) rand() / RAND_MAX);
x[i] += dx[i]; if ((x[i] < 0) | (x[i] > iSize)) dx[i] = - dx[i];
y[i] += dy[i]; if ((y[i] < 0) | (y[i] > iSize)) dy[i] = - dy[i];
glBegin(GL_QUADS);
glVertex2i(x[i], y[i]);
glVertex2i(x[i] + 30, y[i]);
glVertex2i(x[i] + 30, y[i] + 30 );
glVertex2i(x[i], y[i] + 30);
glEnd( );
}
glFlush(); it++;
if (t != time(NULL)) {
_itoa(it, cIter, 10); it = 0;
glutSetWindowTitle(cIter);
} t = time(NULL);
}
void init () {
for(int i = 0; i < 2000; i++){
x[i] = iSize * rand() / RAND_MAX;
y[i] = iSize * rand() / RAND_MAX;
dx[i] = rand() * 5 / RAND_MAX - 2;
dy[i] = rand() * 5 / RAND_MAX - 2;
}
}
void main(int argc, char** argv ) {
init(); glutInit(&argc, argv);
glutInitDisplayMode(GLUT_SINGLE | GLUT_RGB);
glutInitWindowSize(iSize, iSize);
glutCreateWindow("");
glutDisplayFunc(display);
glutIdleFunc (display);
gluOrtho2D (0.0, iSize, 0.0, iSize);
glutMainLoop();
}


 

Vyborne, konecne snaha aspon o neco.

C/OpenGL verze Vašeho programu je zde - vidíte, že není ani nijak
zvlášť delší ani složitější, než Pythoní zdroják. btw Číslo nahoře je
FPS (cca 35x rychlejší, než uvádíte pro Python). Myslím, že si pěkně
vymýšlíte.

Ale kdepak, nevymyslim, udaj o rychlosti 3-4x se vztahoval k vypoctu PI
a tam tomu tak skutecne je. Jinak od pohledu ani tato ukazka neni funkcne,
natoz algoritmicky shodna s tou moji, tudiz je predcasne delat zavery.
Napr. okno do ktereho vykreslujes je mensi.

Ale urcite neprehlednu, ze ses chlubil vhodnosti pro realtime grafiku
u VB.NET, takze ja budu chtit implementaci ve VB.NET, jo, neboj, vsiml
jsem si, ze se ji vyhybas jak cert krizi a vyzyvas me, at si to naprogramuji
sam.

Ale beru to jako snahu alespon o neco. Srovnani s jazykem C bude take zajimave,
a to jak C-Python, tak C-VB.NET. Jake k tomu potrebuji knihovny a jake
jsou potreba parametry pro prekalad, at to muzu otestovat na vlastnim hw?

Zkusim tuto OpenGL verzi implementovat v Pythonu. Uvidime, jake budou
vysledky.

...udaj o rychlosti 3-4x se vztahoval k vypoctu PI...
To je pravda - napsal jste přece, že v případě použití grafických knihoven se rozdíly mezi Pythonem a C stírají, takže nyní by měl být rozdíl ještě menší..
Dále jste tvrdil, že C je Váš oblíbený jazyk, takže předpokládám, že moji radu nepotřebujete. Samozřejmě - pokud prohlásíte, že moje ukázka zkompilovat nelze, dokážu Vám opak. Ukázce VB.NET se nevyhýbám, máte ji stejně jako C ukázku dávno k dispozici na ceskaskola.cz, kde jsem uváděl vhodnost VB.NET pro realtime grafiku. Řekl bych, že se jí spíš zatím vyhýbáte vy...
 P.S. Pokud má Vaše ukázka malé okno, zvětšete si ho... 

Např. tahle ukázka 3D skriptu má efektivní datový tok aspoň 10 MB/sec, ale přesto není důkaz mimořádného výkonu JavaScriptu - všechny práci totiž ve MSIE odvede šikovně ukrytá knihovna.
Podobných demonstrací bych Vám mohl připravit celou řadu, aniž by o výkonu té které platformy cokoliv dokazovaly.
 
http://vbnet.aspweb.cz/msie/borgcube.htm

Pro představu, jak by se takový VB.NET program mohl vypadat pro DirectX přikládám rámcovou ukázku. S dobrou grafickou kartou můžete dosáhnout hodně přes 100 FPS (např. dual Xeon 3,6 GHz, QUATRO FX 3400: 420 FPS / 20000 sprites) i na full screen. Pro zkompilování budete potřebovat DirectX 9.0 SDK (viz search Google na soubor directx_9c_Dec04sdk_redist.exe) a nějaký soubor bitmapy pro sprite.

Ve skutečnosti ovšem nejde o benchmark VB.NET, ale vaší grafické karty.
 Imports System, System.Drawing, System.Windows.Forms
Imports Microsoft.DirectX,Microsoft.DirectX.Direct3D
Class SpriteDemo : Inherits Form
Sub Form_Load(ByVal F As Object, ByVal EA As EventArgs) Handles MyBase.Load
Dim PP As New PresentParameters : PP.Windowed = 1 : PP.SwapEffect = 1
Dim D As New Device(0, 1, Me, 32, PP), S As New Sprite(D), R As New Random ' 64 misto 32 vyžaduje TnT HW!
Dim T As Texture = TextureLoader.FromFile(D, "down.bmp") : Show()
While Me.Created
D.Clear(1, Color.Empty, 0, 0)
D.BeginScene()
S.Begin(0)
For i As Integer = 0 To 20000
S.Draw2D(T, Rectangle.Empty, Rectangle.Empty, New Point(R.Next(500), R.Next(500)), Color.FromArgb(R.Next(255), R.Next(255), R.Next(255)))
Next
S.End()
D.EndScene()
D.Present()
Application.DoEvents()
End While
End Sub
End Class

Pekne, jak jsem ti napsal na ceske skole, je to neco jineho, nez co jsem sem dal
ja a nedela to to, co dela moje ukazka. Tudiz si nehon triko rychlosti, dokud
to nebude delat to co ma .

Obě funkčně totožné ukázky C/OpenGL a VB.NET/DirectX máte na ceskaskola.cz, tady si o ně říkáte zbytečně...
To co mají dělat určuje funkční specifikace - a tu jsem zatím nikde neviděl.

Předně, máte tu ode mě tři veřejně publikované benchmarky, podle kterých je Python řádově 30x pomalejší než C/C++ a současně srovnávají několik dalších jazyků a algoritmu takže je nelze podezírat z toho, že byly vytvořeny s cílem uškodit Pythonu (první benchmark byl dokonce vytvořen s cílem právě opačným, byt nepříliš průkazně dosaženým...):
http://www.flat222.org/mac/bench/
http://www.tempest-sw.com/benchmark
http://www.osnews.com/story.php?news_id=5602&page=3
 

Sežeňte nejprve tři jiné, veřejně publikované s přibližně shodným page rank na Google, které to vyvracejí - a pak budu mít (možná...) důvod se zabývat nějakými propritetárními testy. Sám se zabývám fyzikálním modelováním a popravdě řečeno, není  problém často narazit na odkazy, které dokumentují nepoužitelnost Pythonu nejen v benchmarcích, ale i pro reálné použití v tomto směru. Viz např.:
http://peter.mapledesign.co.uk/weblog/archives/python_is_slow.html
 
Due to some problems, the lecturer overseeing this simulation ended up writing the simulation also, in the departmental version of Basic.
At that point I realised how slow the Python code was. I didn't expect it to be as fast as C, but was surprised by how much faster the Basic version was. It wasn't impossibly slow, but running a million random walks of up to 300 steps was taking nearly 2 hours to complete. I tried plugging in Psyco to speed up the Python code, without much luck.
 
Podle mých zkušeností Psyco nažene stěží tak 50% výkonu, ale Python stále nechávají daleko vzadu i takové jazyky, jako QBasic. Nemá cenu to řešit, ale klidně v tom pokračujte, bránit Vám určitě nebudu. BTW Pokud budete studovat poslední odkaz, povšimněte si prosím, oč je Basic verze zdrojáku (objektivně) úspornější, čitelnější a (subjektivně, alespoň pro mne) přehlednější, než kód v Pythonu...
http://peter.mapledesign.co.uk/physics/simulations/rand_walks_qm/1D_0.py
http://peter.mapledesign.co.uk/physics/simulations/rand_walks_qm/1D_0.nfb

U dvou z tech tri jsem ti jasne ukazal ze jsou spatne a
a u toho tretiho vysvetlil, ze u problemove casti se srovnava
nesrovnatelne. Kazdy kdo ma zajem si to muze overit, vcetne
tebe, je to prukazna zalezitost . Ze se ohanis staryma
neaktualnima vecma (navic vedome) co jsi vystrachal nekde
na google a kterym nerozumis, nechapes ze jsou spatne a hlasas
tady bludy je tvuj problem .

Ja zde uvadim lehce overitelna fakta, a tyto fakta nijak
nejsou zavisla na tom, zda je doklada nejaky link na google
s tim nebo onim page rankem . Porad jsou to fakta a porad
jsou platna s linkem i bez nej . Mel bys zkusit dat na
vlastni rozum (no je to tezky, kdyz ho nemas, chapu), nez
na tom, co se nekde doctes. Internet je plny blabolu a
neverohodnych informaci, divim se, ze se najde nekdo, kdo
mu bezvyhradne veri vic, nez vlastnim zkusenostem a poznatkum.
A to co zde pisu si muzes lehce, velmi lehce, overit .

Ze se ti libi vic zdrojak v basicu chapu, me se ten Pythoni
taky nelibi, treba tohle:


def _newlist(self, length, defaultvalue=None):
""" Create a list with length elements and an optional default value. """
list = []
for x in range(length): list.append(defaultvalue)
return list[:]


Se da napsat jako:

newlist = [value] * lenght

No, ale pripomina mi to me tezkopadne zacatky v Pythonu, kdy jsem
ho obvinoval z neprehlednosti a tezkopadnosti, protoze jsem ho
neumel sprvne pouzivat. Ten clovek co to psal si s Pythonem vyslovene
nerozumel . Treba to return list[:] znamena vytvorit novou
kopii listu, to je uplne zbytecne, klidne mohl vratit samotny list,
no proste, je to prisernost. Kdyz me hezky poprosis, prepisu ti
to do normalniho kodu. Mimochodem, neni divu, ze pri takovych
zbytecnostech je to pomale . Python je dnes na svou kategorii
rychly jazyk, s tim se smir, zvanil jsi tu nesmysly.

Psyco nazene tolik vykonu kolik z kodu je Pythoni zdrojak. Jestlize
vetsinu casu bude aplikace travit v C knihovnach, tak Psyco nenazene
prakticky zadny vykon, protoze nebude mit co optimalizovat, ale ono
to samo diky tomu Cecku pobezi hodne rychle. Tyto ciste Pythoni
benchmarky naopak urychluje nekolikanasobne. Viz ma ukazka optimalizace
vypoctu PI. Zkus si to a uvidis.

Ostatne, v te diskuzi pod tim blogem co jsi sem dal
se to vsechno pise . Ten kod ma radu slabin .

U dvou z tech tri jsem ti jasne ukazal ze jsou spatne...
Budiž, já se s Vámi přece nepřu...  Prostě sem nalinkujte lepší, když je to tak průkazné - stači odkazy aspoň na tři benchmarky, které vyvracejí ty moje a byly podrobeny veřejné diskusi ze strany uživatelů jiných jazyků.
Tomu říkám lehce a intersubjektivně oveřitelná fakta. Už jste je mohl dávno mít a ušetřit si čas psaním.
 
Kdyz me hezky poprosis...  Prosím?

Overena fakta jsou, co si nekde neco od nekoho prectes, nebo
co si vyzkousis na vlastni kuzi a uvidis na vlastni oci?
Neverit sam sobe a svemu usudku, to je zajimavy postoj .

Misto linku jsem sem dal tve vlastni benchmerky, ale zbavene
chyb. Chyby v nich obsazene jsem jasne identifikoval a poskytl
navod jak se jich zbavit. Provedl jsem vlastni testy, ktere
plne potvrzuji ma slova. Mas-li strach ze jsou me vysledky
zfalsovane, absolutne nic ti nebrani si to overit sam u sebe
na vlastnim pocitaci. Nic prukaznejsiho nenajdes a jestli
nenajdes relevantni protiargument, jako upozorneni na nejakou
chybu, ktere bych se dopusti, ci zjistil, ze treba i kod
v jazyce C je spatne napsany a podobne, tak to povazuji za
potvrzene. Zbytecne se tu zhazujes fnukanim, ze chces videt
nejaky link s takovym nebo onakym google page ratingem, ktery
potvrzuje to co ti rikam a presvedcive dokazuji.

Ja zadny link nepotrebuji, mam vlastni rozum. Jestli ty vlastni
rozum nemas, musis se schovavat za cizi rozumy, kterym nerozumis
a nejsi schopen obstat v prime diskuzi se mnou, jo, to je holt
smula . Ale jednu radu ti dam, never bezhlave vecem, ktere
naleznes na internetu, kvalitnich verohodnych informaci v tom
balastu je jako jehel v kupce sena. Kdyz das na mou radu, nebudes
se ztrapnovat, jako se ti to odarilo s temito "benchmarky" .

Slusnej clovek by priznal omyl a porazku, jsem zvedav, jak se
zachovas ty.

Pane Mach, dal jsem vám čtyři odkazy, které dokazují, že rychlost Pythonu je 30x nižší, než C a jediné, co jste za dva dny postavil jako protiargument je program, který testuje rychlost wrapperu SDL a dalších knihoven, který ani nejsou součástí distribuce Pythonu a který na svém stroji ani nezkompiluji, ani nespustím.
Takto by to asi nešlo...
 
Na výzvy, aby jste upravil a předložil relevantní zdroják, který testuje skutečnou rychlost interpreteru Pythonu a kompilát, který si budu moci na svém počítači vyzkoušet nereagujete.
 
Nebo to Python nedovede?

Dal jsi odkazy na ctyri benchmarky a ja jsem ctyrikrat identifikoval zavazne nedostaktky,
ktere tyto benchmarky zneverohodnuji. U dvou z techto benchmarku jsem nedostatky odstranil
a provedl znova, kdy se ukazlo, ze je python mnohem rychlejsi, nez uvadeji ony bechmarky.

Na to jsi nedokazal jiz nijak zareagovat, mic je na tve strane hriste, takze se snaz.

Co se tyce benchmarku sprite, ten s tim nijak nesouvisi, to je reakce na tve tvrzeni, ze
Python se nehodi na realtime grafiku. Protoze sam nevim, jestli se hodi nebo ne, udelal
jsem tento benchmark, abychom mohli porovnat graficky vykon a tedy vhodnost/nevhodnost
Pythonu pro realtime grafiku vuci VB.NET. Jedine na co jsi se zmohl bylo knourani, ze muj
benchmark pouziva SDL knihovnu. No a co? Branim ti ji snad pouzit? Nebo nejakou jinou?
Snad nejsi tak neschopny, abys nedokazal rozhybat 20 000 sprajtu 10x10 v okne 768x768.
Vzdyt jsi tu delal ramena, jak tu na VB.NET chces lidi ucit delat realtime grafiku .
Takze mam za to, ze sis to vyzkousel a VB.NET z toho vychazi hodne neslavne, co?

Relevantni zdrojak jsi dostal. Chtit po me kompilat u interpretovaneho jazyka, u ktereho
se zdrojaky nekompiluji, to beru jen jako spatny vtip . Neni pravda ze nereaguji, stezoval
sis ze to nejde spustit, aniz bys uvedl chybovou hlasku, upozornil jsem te na nutnost stazeni
potrebnych (mimochodem malinkych) knihoven, vcetne url, odkud si je mas stahnout. Kdo chce,
ten muze, problem je, ze ty nechces a hledas si duvody, abys nemusel .

Pane Mach, sám jste přece řekl, že tvrdit mohu co chci, takže snažit se musíte vy. Totéž mohu říct o Vás a na mě Vaše přesvědčování o tom, jak jsou ty benchmarky špatné moc nezabírají. Prostě mi nalinkujte lepší, je to takový problém? Nebo je snad výkon Pythonu nedostatečně zdokumentován?
VB.NET z toho vychazi hodne neslavne, co?  To tedy ano, dosáhnu s ním 20x rychlejší, než vy v Pythonu... Myslel jsem, že to bude méně.
 
Chtit po me kompilat u interpretovaneho jazyka, u ktereho se zdrojaky nekompiluji, to beru jen jako spatny vtip 
Já po Vás chci EXE - tvrdil jste přece, že to Python umí. Nebo neumí? Nebo to neumí s Psyco, takže s ním ani slušně běžící aplikaci vlastně nenapíšete? Jak je to tedy?

Tenhle graf vykonu je od tebe pekny podvod na ctenare, urcite te za to budou mit radi:



Ze jde o vedomy podvod je jasne z toho, ze jsi neuvedl zdroj a i ten obrazek jsi
zkopiroval na vlastni web, aby to nebylo dohledatelne. Jenze ja jsem si to stejne
dohledal. http://www.flat222.org/mac/bench/

Nepochybne sis precetl, ze autor byl zadan o jejich aktualizaci, ale ze odpovedel:
This page will not be updated again. Tudíž se tu vědomě oháníš starými
neaktuálními věcmi. Vzhledem k tomu, ze jsem te opakovane upozornoval na to, ze
Python prosel v poslednich letech vyraznymi optimalizacemi na vykon, každá nová
verze je rychlejší než předchozí, je to graf, ktery nema žádnou vypovídací hodnotu,
protože testy byly provedeny na Pythonu 2.1.3, což je několik generací starý interpret.

Krom toho pro Python existuje optimizer vykonu Psyco, ktery se pouziva tak, ze na
zacatek zdrojaku napises import psyco; psyco.full(), coz pouzije kazdy, pro koho je
vykon kriticky.

Na stránce jsou kódy jednotlivych benchmarku, takze jsem je vzal, ty pythoni upravil
pro pouziti s psyco a provedl testy znova:



Python: 2.3.4 + Psyco 1.4
Perl: 5.8.3
Java: 1.4.2
C++: gcc 3.3.2, překlad s optimalizací -O3

Jake prekvapeni, Python je ve trech testech nejrychlejsi (pravdepodobne jen proto, ze
dva zdrojaky C++ se mi nepovedlo prelozit) a ani v jednom neni nejpomalejsi. Takze
asi tolik k tvemu podvodnemu obrazku. Python je naopak az prekvapive rychly. Docela
by me zajimalo i srovnani s VB.NET. Dokazes ty jednoduche testiky prevest do VB.NET
a nebo je to mimo tve schopnosti?

Zdravím, pane Mach...
Myslím, že výsledky z toho grafu poměrně konzistentně korespondují např. s výsledky srovnávacích benchmarků devíti jazyků
zde http://www.osnews.com/story.php?news_id=5602&page=3
 
Jak vidíte, Python má celkové skóre 20x nižší, než VB.NET a více než 30x nižší, než C++.
 
 
 
Bohužel, ani další benchmarky nejsou pro Python příliš povzbuzující, viz např. zde Python spolehlivě prohrává v sousedství šesti jazyků
 
 
 

 
Můžete to samozřejmě namítat, ale by vhodné to dokladovat publikovanými výsledky, ne těmi, které jste si vyrobil sám.

apropos, link na ty poslední benchmarky je zde http://www.tempest-sw.com/benchmark/. 
Jak vidíte, je docela těžké sehnat na webu výsledky, kde je Python rychlejší než C/C++, můžete si je ovšem vyrobit sám.

Ano, vyborne, priklad s vypoctem PI je dalsi perfektni ukazkou
spatneho benchmarku, snad si kazdy uvedomi, ze benchmarkum nelze
verit, pokud clovek dane veci nerozumi a nedovede si overit jejich
spravnost.

1. chyba

Uz jsem ti ji vytykal minule, testy jsou provadene na starem
interpretu a posledni dobou je optimalizaci na rychlost venovana
velka pozornost. Ja doma tak starou verzi Pythonu nemam, ale na
me nejstarsi verzi co mam k dispozici, vypocet 5000 ciferneho
PI probehne takto:

# Python 2.2.3 s puvodnim spatnym kodem
[wraith@frodo test]$ python2.2 pi_orig.py
183.873641014
190.399065018
185.361978054

Kdyz pouziji nevejsi interpret, vysledky se zlepsi:
# Python 2.3.4 s puvodnim spatnym kodem
[wraith@frodo test]$ python2.3 pi_orig.py
127.131766796
131.887209177
124.205429077

To vsak neni vsechno. Nahledneme na kod a zjistime na prvni
pohled, ze ten Pythoni psalo nejake prase. Nejvnitrnejsi
(tedy vykonove nejvice exponovana) smyzka v Pythonu vypada
takto:

for i in xrange(len(a)-1, -1, -1):
x = 10*a[i] + q*(i+1)
q, a[i] = divmod(x, p)
p -= 2


Kdezto u C takto:

for (i = alength; --i >= 0; )
{
int x = 10*a[i] + q*(i+1);
a[i] = x % p;
q = x / p;
p -= 2;
}


A u Javy takto:

for (int i = a.length; --i >= 0; )
{
int x = 10*a[i] + q*(i+1);
a[i] = x % p;
q = x / p;
p -= 2;
}


U Pythonu se v ni vola funkce! Opravme tedy Pythoni kod:

for i in xrange(len(a)-1, -1, -1):
x = 10*a[i] + q*(i+1)
a[i] = x % p
q = x / p
p -= 2


(Provedl jsem jeste dalsi, uz ne tak vyznamne upravy, jako nahrazeni
pomale techniky scitani retezcu za jejich ukladani do pole a jejich
hromadne slouceni az na konci, stejne jako to dela Java.)

A vysledky jsou zase mnohem lepsi:

# Python 2.3.4 s opravenym kodem
[wraith@frodo test]$ python2.3 pi.py
89.4192471504
85.5365068913
89.5616190434
< br>Oproti tomu puvodnimu uz mame zrychleni pres 50 %. Co je tohle
za benchmark? No a samozrejme, kdyz jde o rychlost, pridame na
zacatek zdrojaku instrukci pro optimalizaci:

import psyco; psyco.full()

A konecne vysledky jsou tyto:

# Python 2.3.4 s opravenym kodem a optimalizovany s psyco
[wraith@frodo test]$ python2.3 pi_psyco.py
7.80631399155
7.80032110214
7.8192470073 7

Pekne si to vsechno secteme a zobrazime:



A muzeme konstatovat, ze dana uloha s danym algoritmem se da provest
s drobnyma upravama 24x rychleji. K cemu je puvodni benchmark? Spravne.

Pro srovnani jeste jine jazyky:

# Java 1.4.2_04
[wraith@frodo test]$ /jbin/java Pi
4.675
4.667
4.676

# C (gcc 3.3.2)
[wraith@frodo test]$ ./pi
4.400000
4.420000
4.490000

# C (gcc 3.3.2) optimalizovane s -O3
[wraith@frodo test]$ ./pio
2.100000
2.100000
2.110000

Takze ac je Python dynamicky a interpretovany, ani zdaleka neni tak
pomaly, jak se snazis naznacovat .

K tomu je poteba pripocist fakt, ze vetsina beznych programu pouziva
nejake knihovny, treba GUI, xml parser, systemova volani a podobne,
ktere jsou implementovany v jazyce C a bezi rychlosti odpovidajici
jazyce C. Takze realne aplikace v Pythonu bezi velmi svizne.

Dale je nutno si uvedomit, ze rada aplikaci, zvlaste tech GUI vetsinu
casu stejnenedela nic a ceka na uzivatele, az neco udela a nebo na
data, ktera, z pohledu procesoru, tezou z disku nebo site velmi
pomalu. Python se urcite nehodi na vsechno, a najdou se veci, kde
zalezi na kazdem taktu procesoru a neni radno s nim mrhat. Takovou
aplikaci je vhodne napsat v C a jeji casti i asm, ale jinak?

Trend je takovy, ze je vhodnejsi koupit vykonnejsi hw, nez vyvijet
aplikaci trikrat dele (a tedy za trojnasobnou cenu). Cas programatora
je v dnesni dobe drazsi, naz cena hardware. To vi kazdy programator,
co programuje na zakazku. Rychlost vyvoje je mnohdy dulezitejsi nez
rychlost programu a zde ma Python co nabidnout, vyvoj v nem je snadny
a rychly. A ten vysledny program neni zas az tak pomaly, jak vidis.

Doufam ze se zde predvedes s tou realtime grafikou a 20 000 sprajty,
jsem na to moc zvedavy .

Jinak co se tyce te horni tabulky, tak tam jsou zase jine problemy.
Python nejvic a vyznamne zpomaluje prace s typem Long. Je nutno si
uvedomit, ze Long v Pythonu znamena nekonecne velke cislo, kdezto
v ostatnich jazycich 32 bit. cislo (i kdyz podle casu odhaduji, ze
se ve skutecnosti testoval long long, tedy 64 bit. cislo).

V pythonu je ale Long neomezene velke cislo. viz treba mocnina
100 a 1000:

>>> 10**100
10000000000000000000000000000000000000000000000000 000000000000
000000000000000000000000000000000000000L
> >> 10**1000
1000000000000000000000000000000000000000000000000 0000000000000
00000000000000000000000000000000000000000000 000000000000000000
000000000000000000000000000000000000000 00000000000000000000000
0000000000000000000000000000000000 0000000000000000000000000000
00000000000000000000000000000 000000000000000000000000000000000
000000000000000000000000 00000000000000000000000000000000000000
0000000000000000000 0000000000000000000000000000000000000000000
00000000000000 000000000000000000000000000000000000000000000000
000000000 00000000000000000000000000000000000000000000000000000
0000 0000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000 00
0000000000000000000000000000000000000000000000000000000 0000000
00000000000000000000000000000000000000000000000000 000000000000
000000000000000000000000000000000000000000000 00000000000000000
0000000000000000000000000000000000000000 0000000000000000000000
00000000000000000000000000000000000 000000000000000000000000000
000000000L

To v jinem jazyce s long nedokazes, takze se zde porovnavaji
hrusky s jabkama. Tento test tedy nelze brat v uvahu, o nicem
nevypovida.

Prace s typem Double je v Pythonu pomalejsi, to je pravda.
Prace s Int je dnes o cca 20 % pomalejsi nez v C, zde se
opet projevuje stari interpretu. Volani trigonometrickych
funkci by melo byt stejne rychle jako prace s Int. IO ma
Python dnes velmi rychle. Takze opet na tom Python nebude
tak spatnem jak se snazis prezentovat. Casem sem dodam take
vlastni benchmark.

tesim se na dalsi pokracovani serialu

Vidis Tluchubo, zvedam ti sledovanost serialu, nebyt me, je to nuda,
protoze koho by bavilo cist pet tydnu o tom, jak se pracuje s poli
a retezci . Zvlast kdyz v Pythonu je to snadne a s retezci lze
pracovat jako s polem znaku, coz je velmi uzitecne.

Lidé kteří se zajímají o VB.NET obvykle poměrně dobře vědí,
proč se neinvestují čas do studia Pythonu. Ten, kdo se rozhodl
učit VB.NET tak učinil proto, že jde o snadný způsob seznámení
s prostředím .NET, s platformou dobře optimalizující výkon a
nároky na osvojení, s výbornou a konzistentní základnou
rozsáhlých knihoven a prostředí pro tvorbu webových aplikací,
širokou vývojářskou a studijní základnou , atd..

Nekteri nepochybne ano, ale rada dalsich nepochybne ne. Cim vetsi zacatecnik
s mene znalostmi a zkusenostmi, tim mene je dotycny schopen si vybrat vhodny
jazyk. Treba VB.NET je pro zacatecniky nevhodny, VB je historicky jazyk plny
spatnosti, VB.NET je roztristeny a nekonzistentni, patri na smetiste dejin.

Jestli se nekdo hce ucit .NET, coz je dobra volba, tak je mnohem vhodnejsi
moderni a aktualni C#. Ale je take potreba uvest, ze existuji jazyky, ktere
jsou jednodussi a da se v nich programovat snadneji. Mezi nimi je nejlepsi
Python a myslim ze vetsine laickych zacatecniku, kteri chodi na zive, nabidne
vic, nez kdy budou potrebovat. A pokud jsi soudny, tak to uznas taky .

Python je určen k něčemu dosti jinému a v tom směru může plnit svou úlohu
velmi dobře, ale je to stále "ten" dosti svérázný pomalý skriptovací jazyk s
nevalnou podporou GUI Windows, což je vůči VB.NET výrazný handicap. Zatím byl
Python implementován v Javě i .NETu (Jython, IronPython) a může na nich být
jako jazyk i seriózně používán - ale na to, aby s těmito platformami mohl
vážně soupeřit bych počkal do doby, až budou tato prostředí pro změnu
implementovány v Pythonu. Domnívám se, že to v dohledné době nehrozí.

To by me zajimalo, k cemu dosti jinemu? Python je urcen k rychlemu a snadnemu
vyvoji aplikaci. Ve srovnani s mainstreamem a VB o nem nemuzes prohlasovat ze
je sverazny ani omylem. Neni to jazyk skriptovaci, ale dynamicky a interpretovany.
Diky snadnosti pouziti se v nem daji psat i skripty, ale diky jeho robustnosti
a silne typove kontrole je vhodny i na psani aplikaci.

Pomalejsi nez staticke jazyky kompilovane do binarniho kodu je, ale mnohem mene,
nez by se ti mohlo zdat. Ostatne, uvidime to na programu Sprites, o kolik je
pomalejsi nez VB.NET.

Nevim co myslis tim, ze byl Python implementovan v Jave a .NETu. Pravdepodobne to,
ze existuji prekladace Pythonich zdrojaku do byte kodu Javy a .NET. To je neco jineho
nez implementace Pythoniho prostredi , ktere je implementovano v jazyce C a Pythonu
samotnem. Nicmene to, ze jde Python pouzivat ve vsech prostredich a na ruznych
platformach je jednou z jeho silnych vyhod, kterou mu lze pripocitat k dobru, a kterou
zrovna VB.NET jaksi poskytnout nemuze.

Zminovane soupereni je pekna demagogie, ktere s timto nijak nesouvisi. Soupereni se
odehrava na jine rovine, a to na nabidce schopnosti a cene za tyto schopnosti. A zde
je Python velmi silny. Ostatne, prostredi .NET je napsano v C++ a nijak to nebrani
jeho soupereni o prizen programatoru v C++ .

Co se týče změny Vašich názorů na Python, tam neřeším, zda jej považujete za jazyk
"ve své kategorii" nejlepší (to jste tvrdil už před rokem, jen jste tu kategorii
nespecifikoval)

To je kategorie interpretovanych dynamickych jazyku.

VB.NET je roztristeny a nekonzistentni, patri na smetiste dejin
Přesně totéž jste před časem  tvrdil o Pythonu také. Nu a vidíte, zatímco své výroky jste sám poslal na smětiště dějin, Python je tu stále...

Jestli se nekdo hce ucit .NET, coz je dobra volba, tak je mnohem vhodnejsi moderni a aktualni C#.
Pokud ale umí Basic, a/nebo v něm má spoustu zdrojového kódu je zbytečné aby se učil nový jazyk. Ze stejných důvodů existuje J#. Nemluvě o tom, že řadě lidí syntaxe C# ani chování jeho vývojového prostředí nevyhovuje. Např. VB.NET zdroják Visual Sudio kompiluje na pozadí, to je velmi silná feature.
 
..Python a myslim ze vetsine laickych zacatecniku, kteri chodi na zive, nabidne vic, nez kdy budou potrebovat...
Většina lidí ale potřebuje současně skriptovat makra MS Officce, ASP a další prostředí s VB syntaxí a má k dispozici na webu spoustu ukázek ve VB. Python je - řekněme si to upřímně - pod Windows vcelku k ničemu, nativní podpora Windows GUI mu stále chybí a má syntaxi, o které jste se sám vyjádřil jako težkopádné a zastaralé.. Dokonce i OpenOffice.org nativně nahrává makra ve VBScriptu, takže úlohu Basicu spíše dále posiluje. Ostatně v době, kdy jste byl laickým začátečníkem vy jste se vyjádřil, následovně:
Nekdo prohlasil ze Python je snadny jazyk pro zacatecniky,jak se v nem lehko a krasne programuje a jak je srozumitelny a vsichni ostatni to po nem papouskuji, ale skutecnost je jina. Osobne bych tuto roli spis priradil PHP, ktere si na nic nehraje a je opravdu snadne a k zacatecnikum privetive Python desne tezkopadnej (treba i tim rozlisovanim slozenych prikazu odsazenim kodu) a zastaralej, je to takova splacanina, jako OOP jazyk byl navrzen desne mizerne a neni vhodny pro zacatecniky v programovani . Nemam problem se vyznat treba v 20 KB zdrojaku PHP, ale v 5 KB zdrojaku Pythonu ano.
To zní docela drsně, že? To všechno dnes paušálně negujete s poukazem na to, že jste byl tehdy začátečník v Pythonu. To pak ale zase těžko můžete tvrdit, že vám Python jako začátečníkovi vyhovoval. Nyní o VB.NET tvrdíte v podstatě to samé - a to jste v něm nenapsal nejspíš ani řádku. Pouhou extrapolací bych si dovolil soudit, že za rok budete zažraný fanda VB.NET a budete útočit zase na nějaký jiný jazyk. A pokud jste soudny, tak to uznáte taky, osobně o tom ale dovolím pochybovat.. 
 
Python je urcen k rychlemu a snadnemu vyvoji aplikaci.  Python se nehodí pro automatizovaný vývoj v IDE - nepoužívá explicitní formátování, oddělovače a nezná typové deklarace, což jsou vlastnosti používané v současných RAD IDE.
 
Ostatne, uvidime to na programu Sprites, o kolik je pomalejsi nez VB.NET.
Nechtěl jste spíše napsat kolikrát?

a to na nabidce schopnosti a cene za tyto schopnosti. A zde je Python velmi silny.
Objektivně je nutné říci, že Python se v nabídce jazyků pod Windows dodnes neprosadil. Pod Linuxem mu chybí jeho hlavní konkurenti, především Visual Basic a VBScript.
Ostatne, prostredi .NET je napsano v C++ 
Jen z malé části, odhadem tak 5% a tento podíl se navíc s novými verzemi .NET Framework nestále zmenšuje. Většina .NETu je napsána v .NETu.

Pane Mach, můžeme se celkem smysluplně bavit o rozdílech a výhodách C#
versus VB.NET - ale stran srovnání VB.NET a Pythonu týče se obávám, že to
velký smysl nemá - zvlášť pod tímto článkem ne - protože Python je prostě
jiná liga a je určen jiné cílové skupině pro řešení jiných problémů. Slovu
JINÉ bych zde preventivně nepříkládal jakékoliv hodnotící stanovisko, ale
určitě se shodneme na tom, že Python třeba není ideální pro realtime
grafiku, grabování videa, vývoj a práci s COM objekty, složité GUI aplikace
s MDI formuláři apod. záležitosti, se kterými se zde budeme postupně
seznamovat.

Kdyz se v diskuzi o Pythonu jako prvnim jazyce pro vyuku muzeme bavit
o VB.NET jako takovem, tak nevidim duvod, proc si zde nepopovidat o Pythonu.
Ale jsem rad, ze si uvedomujes, ze je to jaksi podivne, snad te to pro
priste odradi od podobnych excesu .

Ano, Python je jina liga, ale viz. vyse, je to to same .

Ad realtime grafika. Nevidim duvod, proc by Python nemel byt vhodny.
Jedine snad z duvodu nizsiho vykonu. Neni to muj obor, ale docela
by me zajimalo o kolik (a jestli vubec) je Python pomalejsi nez
VB.NET. Udelal jsem takovou malou ukazku, kterou nepochybne ve
VB.NET zvladnes udelat take, muzeme to porovnat.

Programek Sprites vytvari 20 000 ctverecku o rozmerech 10x10 pixelu
s nahodnou barvou, pozici a smerem. Tyto jsou umisteny na plochu o
velikosti 768x768 pixelu, na ktere se pohybuji nahoru a dolu, kdyz
se dotknou okraje, zmeni smer pohybu. Na mem pocitaci tento programek
dosahuje 16,736 fps.

Jednoduchy vypocet 10*10*20000*16,736 ukazuje, ze dynamicky interpretovany
Python dosahuje grafickeho datoveho toku 33, 742 MPix/s. Jsem zvedavy na
vykon statickeho kompilovaneho VB.NET. Mel by byt vyssi, samotneho me
zajima o kolik.

Zdrojak: http://wraith.iglu.cz/python/ukazky/graph.sprites/sprites.py.html
Ukazka: http://wraith.iglu.cz/python/ukazky/graph.sprites/sprites.png

Grabovani videa. To nevim co tim myslis, jestli napsani graberu se vsim
vsudy, tak ne. Jestli pouziti nejakych komponent, ktere odedrou hlavni
praci, tak proc ne. Na "slepeni" ruznych komponent je Python dobry.

Vyvoj a praci COM objektu zvlada Python s rozsirenim pro Windows bez
probelmu uz hodne dlouho, treba tohle je prezentace z roku 97:

http://www.python.org/windows/win32com/COMTutorial/

Nemene zajimave pro tebe bude toto:
http://www.microsoft.com/technet/scriptcenter/scripts/python/default.mspx
http://www.microsoft.com/technet/scriptcenter/scripts/python/os/com/default.mspx

Nejlepsi dokumentace pro praci s COM je soucasti win32 rozsireni pro Python.
http://starship.python.net/crew/mhammond/win32/

Slozite GUI aplikace s MDI bez problemu. To neni zalezitost jazyka, ale
GUI knihovny a Python podporuje radu standardnich a bezne uzivanych GUI
knihoven. Prikladem takove aplikace je treba:

http://wingware.com/wingide/screenshots

Jejiz GUI je vemi dynamicke, pracovni plochu lze libovolne delit, kazde
sub okno muze mit zalozky, ktere lze libovolne pridavat, odebirat a
pretahovat a tak dale. To vse je pritom multiplatformni a funguje to
jak ve Windows, tak Linuxu tak na Macu. Je to skinovatelne a tak dale
a tak podobne.

To WinGIDE jsem si vyzkoušel pod Windows - a opravdu vřele doporučuji všem pochybovačům nainstalovat třeba spolu s IDE volně dostupného Visual Studio Express
http://lab.msdn.microsoft.com/express/vbasic/default.aspx
 
 Protože není nad reálné srovnání.....

Vaše ukázka mi nejde bohužel zkompilovat a spustit ani ve WinGIDE, ani z příkazové řádky. Mám standardní distribuci Pythonu 2.4 a Wing IDE Lite 1.1.10
Zkuste mi zkompilovat EXE, zkusím si ho pustit aspoň v sandboxu.

V tom pripade ti chybi pygame: http://www.pygame.org/download.shtml
A psyco: http://sourceforge.net/project/showfiles.php?group_id=41036

K tomu ti jeste doporucuji si doinstalovat win32 rozsireni:
http://sourceforge.net/project/showfiles.php?group_id=78018&package_id=79063&release_id=2743 44

Neni to pro ukazku potreba, ale umozni ti to pristup k win32
api a dalsim sluzbam, tedy plnohodnotne vyuziti Pythonu ve
windows.

vyhod tu blit funkciu (to je trocha demagogia ze, co to ma spolocne z interpreterom) a napis cas.

(aj pygame.display.update() pochopitelne)

S interpretem to ma spolecneho tolik, ze interpret tuto
metodu vola. Nevim co je na tom demagogickeho. Nejde o test
rychlosti interpretu, ale o otazku, zda je Python vhodny na
realtime grafiku nebo ne .

Jestli hodlate resit jen samotny interpret/prekladac jazyka
bez knihoven, tak to vas predem lituji, protoze Python ma
radu builtin funkci a umi bez knihoven alespon cist a zapisovat
do souboru, cimz je aspon trochu pouzitelnej. Jsem fakt zvedav,
jak hodlas testovat graficky vykon, kdyz ti zakazu pouzivat
#include cokoli .

Pouzivani knihoven je bezna programatorska praxe, kdyz chci
v Pythonu pracovat s grafikou, pouziju k tomu prislusnou
grafickou knihovnu, kdyz ty chces v C++ pouzivat IO operace,
pouzijes k tomu stdio.h, conio.h a podobne .

Na mem pocitaci tento programek dosahuje 16,736 fps. 
Jestli jde o šestnáct tisíc FPS, pak je to slušný výkon, to stihne můj blitter leda naprázdno. Ukázka ve VB.NET níže na dobrém PC zrenderuje cca 8 milionů sprajtů s 1 FPS, 20.000 sprajtů s cca 420 FPS.