Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Já vidím v původním příspěvku, že je řeč o Spring (na Javě) vs Flash (na Pythonu). Ty tam vidíš něco jiného?Kromě toho tam vidím neplatné zobecnění "co platí pro Spring, platí pro Javu". Proto jsem ho korigoval.
Jen aby se vám z toho ale nezamotala hlava.Já tam teda vidím Javu na druhém a 5.-8. místě, přičemž se jí tam vetřel jenom Ur (asi málo kdo používá) a C++. První výskyt Pythonu vidím až někde na místě, do kterého se mi nechce počítat. Cca čtyřicátém?Ten tolikrát vychvalovaný Spring v o několik řádů rychlejší Javě je v něm totiž například pomalejší než flask s Pythonem. A to se bavíme o reálných problémech webového backendu
Ty tam vidíš něco jinýho?
Hele ty nerudný človíčku, buď té lásky a běž si vkládat slova do úst někomu jinému. Tenhle způsob diskuze mě nebere. Díky.Jen se snažím dobrat smyslu toho tvého "benchmarku", ale asi se mi to nepodaří...
Tak tyhle závěry jste si vyvodil sám. Já vůbec ne. Já upozorňoval na to, jak je to s benchmarky. Nedělal jsem z toho závěry. Můj příspěvek je o tom, jak se dají věci ohýbat v benchmarcích. Nehodnotil jsem ani jednotlivé jazyky ani ohledně nich nedělal závěr. Jen jsem je použil na demonstraci toho, jak je to se syntetickými benchmarky tak, aby to bylo zřetelně vidět. Pokud to stále nechápete, tak už nevím jak vám to mám vysvětlit...Takže tvrdíš, že benchmarky na benchmarksgame jsou podobně vadné, jako ten tvůj benchmark? Po pravdě nevím, co se snažíš říct. Že se dá bechmark udělat úplně blbě a je naprosto nevypovídající? To všichni víme. Jsou takové i benchmarky na benchmarksgame? Nemyslím si.
Neříkejte, že vám přece jen uchází pointa, že to není o language war, ale upozornění na to, jak je to s benchmarky.Bohužel pointa uchází tobě, tvrdíš, že jsou benchmarky k ničemu a sám vyrobíš benchmark, který je naprosto úplně mimo a vyvozuješ z něho závěry o kosmické rychlosti C oproti jiným jazykům.
Ta benchmarks game se snazi implementovat realne algoritmy a kod, ktery tam je, je od profiku v danych jazycich.
Moje pointa je, ze pokud neco naimplementujete naivne v Jave a pustite to na defaultnim JVM, tak to pojede mnohem rychleji (klidne o rady), nez kdyz udelate to stejne naivne v Pythonu a pustite defaultnim interpreterem.
A to si myslim i odrazi dost tech "zpackanych" benchmarku valejicich se na blozich, proste pokud chcete vykon v Pythonu stejny, jako dostanete bez prace v Jave, musite vynalozit specialni usili - napr. prepsat cast aplikace aby pouzivala externi knihovnu, prekladat to necim specialnim atp.
Co jsem cetl, tak pomalost Javy oproti C++ je pouze v pripade malych projektu - kdyz JIT jede dlouho nad velkymi enterprise vecmi, tak pry bezne dosahuje lepsiho vykonu, nez C++, protoze dynamicky provadi mnohem vice pokrocilych optimalizaci podle hotspotu v dobe behu, ne jen pri kompilaci nebo provadeni jedne ulohy (na to je C++ rozhodne lepsi). To je duvod, proc se to pouziva na ty obrovske veci - (relativne) jednoduchy velmi rozsireny jazyk + solidni vykon.
Pokud vim, tak postovane benchmarky nepodvadi outsourcovanim provadeni opraci do asm/c/c++ knihoven, jako tvuj kod.
PS: Java snad nema specializovane matematicke knihovny?
1. Téma této diskuse se týká Pythonu, ne Javy
2. Pointa příspěvku nebyla ohledně toho co má který jazyk, ale ohledně toho, jak to je s benchmarky
Nasel jsi snad nejaky podobne zavadny kod, jako jsi napsal, v te benchmarksgame? V opacnem pripade tvuj prispevek nema zadnou pointu, protoze asi vsichni vi, ze podvadet se da
Njn, když ono je to s těmi testy takové ošidné. Když bych měl parafrázovat: Nevěřím žádnému benchmarku, který jsem si sám nezfalšoval...
Kupříkladu:
CKód: [Vybrat]#include <stdio.h>
int main ()
{
long a;
long sum = 0;
for( a = 0; a < 200000000; a++ )
{
sum += a;
}
printf("sum: %ld\n", sum);
return 0;
}
Tak tenhle benchmark sis zfalšoval opravdu hezky. Viděl jsi assembler, který gcc vygeneruje?Kód: [Vybrat]Ten cyklus se vyhodnotí během kompilace a nic se nepočítá. Takový syntetický příklad je ale úplně k ničemu. Zkus si místo konstanty načíst horní mez cyklu ze vstupu a bude to vypadat úplně jinak..cfi_startproc
subq $8, %rsp
.cfi_def_cfa_offset 16
movabsq $19999999900000000, %rsi
movl $.LC0, %edi
xorl %eax, %eax
call printf
Pokud vim, tak postovane benchmarky nepodvadi outsourcovanim provadeni opraci do asm/c/c++ knihoven, jako tvuj kod
PS: Java snad nema specializovane matematicke knihovny?
Jako ja nevim, ale normalni Python je malokdy rychlejsi, nez Java, vetsinou i o rady pomalejsi - https://benchmarksgame.alioth.debian.org/u64q/python.html.
Tohle bych nečekal http://benchmarksgame.alioth.debian.org/u64q/php.html
#include <stdio.h>
int main ()
{
long a;
long sum = 0;
for( a = 0; a < 200000000; a++ )
{
sum += a;
}
printf("sum: %ld\n", sum);
return 0;
}
$ gcc -o bench0 bench.c && time ./bench0
sum: 19999999900000000
real 0m0.529s
user 0m0.524s
sys 0m0.000s
class Bench {
public static void main (String [] args)
{
long i, sum = 0;
for(i=0; i<200000000; i++) {
sum+=i;
}
System.out.println(sum);
}
}
$ javac bench.java && time java Bench
19999999900000000
real 0m0.188s
user 0m0.184s
sys 0m0.016s
<?php
$sum = 0;
for($i=0; $i<200000000; $i++) {
$sum += $i;
}
echo($sum."\n");
?>
$ time php -f bench.php
19999999900000000
real 0m8.860s
user 0m8.836s
sys 0m0.012s
sum = 0
for i in range(200000000):
sum+=i
print(sum)
$ time python bench3.py
19999999900000000
real 0m25.327s
user 0m21.612s
sys 0m3.616s
$ time python3 bench3.py
19999999900000000
real 0m21.746s
user 0m21.676s
sys 0m0.012s
sum = 0
for i in xrange(200000000):
sum+=i
print(sum)
$ time python bench.py
19999999900000000
real 0m15.998s
user 0m15.972s
sys 0m0.000s
$ time pypy bench3.py
19999999900000000
real 0m1.175s
user 0m1.152s
sys 0m0.016s
$ time pypy bench.py
19999999900000000
real 0m1.165s
user 0m1.156s
sys 0m0.004s
print(sum(range(200000000)))
$ time python3 bench-sum-range.py
19999999900000000
real 0m3.209s
user 0m3.200s
sys 0m0.000s
$ cat bench-sum-xrange.py
print sum(xrange(200000000))
$ time python bench-sum-xrange.py
19999999900000000
real 0m1.335s
user 0m1.324s
sys 0m0.000s
import numpy
print numpy.sum(numpy.arange(200000000))
$ time python3 bench-numpy.py
19999999900000000
real 0m1.745s
user 0m0.792s
sys 0m0.876s
$ time python bench-numpy.py
19999999900000000
real 0m1.599s
user 0m0.684s
sys 0m0.900s
$ gcc -O1 -o bench1 bench.c && time ./bench1
sum: 19999999900000000
real 0m0.085s
user 0m0.080s
sys 0m0.000s
$ gcc -O2 -o bench2 bench.c && time ./bench2
sum: 19999999900000000
real 0m0.003s
user 0m0.000s
sys 0m0.000s
Nevím jestli chápu zadání správně, ale podle podmínek je řešení vzít nejmenší kousek a ostatní v libovolném pořadí odečíst, tím vyjde záporná délka :-D.
2-3-5-6 = -12
a vlastně proč neodečíst už i první číslo?
-2-3-5-6 = -14
Problem solved :-D
Nechápeš to správně, tohle znamená, že jsi našel řešení s délkou 14.
Představte si následující problém:
mám kousky dřeva různých délek (např. 3, 5, 2 a 6 cm) spojených na svých koncích (podobně jako skládací metr). Úkolem je najít rovnici, která povede k nejmenší délce složených kousků.
Jedno z možných řešení je sestavit všechny možné rovnice a spočítat složenou délku:
3 + 5 + 2 + 6 -> délka 16
3 + 5 + 2 - 6 -> délka 10
3 + 5 - 2 + 6 -> délka 8
3 + 5 - 2 - 6 -> délka 8
3 - 5 + 2 + 6 -> délka 8
3 - 5 + 2 - 6 -> délka 9
3 - 5 - 2 + 6 -> délka 7
3 - 5 - 2 - 6 -> délka 13
Hledaná rovnice (která nemusí být jen jedna) je tedy 3 - 5 - 2 + 6.
Generování všech rovnic zabere poměrně dost času (například při padesáti kouscích to vyjde na nějakých 2 500 let). Existuje algoritmus (případně s kódem), jak najít požadovanou rovnici ještě během mého života :-)
Díky!
Ale no tak. Nejenomže prodejci o tomhle chování neinformujíMně tedy název disku „Archive“ připadá jako klíčová informace. Pokud bych ten disk chtěl použít jinak, než k archivaci, budu si pečlivě zjišťovat, čím je ta řada specifická. Že to používá SMR prodejci informují, že SMR zpomaluje zápis se dočtu i na Wikipedii.
Jakoze windows neumi virualni plochy? No to chce zkusit win10
K libreoffice nepouzitelnej nastroj. Oproti officu. Tedka jsem kamosce delal cislovani na diplomce. Mela to v libreoffice a ani za boha jsem nevedel jak to udelat a to jsem zkousel ruzne moznosti. Chytnul jsem ms word a za minuty jsem to mel. Jako pouzitelnost nekterych programu 0b.
Nebo je to všechno stejný, pomalý šmejd, a napsat se to v tom zkrátka nedá?
Eclipse - padá, seká se. Simulink - padá, seká se, odezva gui v sekundách. Xilix PlanAhead - naprosto to samé. Jdownloader - pomalost, zasekávání. Jediným pojítkem je GUI psané v Javě....
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.