44 ответов в теме

[P.J.Fry]

Забавная старая картинка, но в тему

[doommer]

Бред.

Пока ты будешь писать программу на С, которая будет считать 2^1000, я на Python это посчитаю на раз-два, просто написав 2**1000. Логика вроде if/while работает с одинаковой скоростью тоже.

Бред то чем вы занимаетесь. Сравнивать производительность у языков у совершенно разного уровня. Но я всё же продолжу заниматься тем же бредом

Есть два кода:

Python:

i = 0while (i < 1000000):   print i  i = i + 1

С:

#include <stdio.h>int main (){int i;for(i = 0; i < 1000000; i++)    printf ("%d\n", i);return 0;}

Итак кто же быстрей сделает эту однотипную операцию, я специально вывожу вывод в /dev/null что бы тест не зависел от фазы луны. Принтскрин с результатами в аттаче. Так что С считает на начале слово раз, а питон, на раз-два-три

Еще можно ради интереса сделать программку которая считывает данные из файла(скажем так метров 50-100 было), что-то с ними делает и записывает в другой файл. Но это всё ровно бред, я еще раз повторюсь, сравнивать эти языки дурное занятие )

Прикрепленные изображения

• 

Сообщение отредактировал doommer: 05 September 2010 - 13:20

[ононимъ]

Бред то чем вы занимаетесь. Сравнивать производительность у языков у совершенно разного уровня. Но я всё же продолжу заниматься тем же бредом

Есть два кода:

Ну если уж ты занялся этим бредом, то теперь будь добр, сделай второй шаг, добавь в оба теста по паре нулей к циклам, а затем из полученных результатов вычти их первые результаты.

[DarkPhoenix]

...

Лог

dfx@Kreo:~/Desktop$ cat iter.py 
i = 0
while (i < 1000000): 
  print(i)
  i = i + 1
dfx@Kreo:~/Desktop$ time python3 iter.py > /dev/null

real	0m1.902s
user	0m1.896s
sys	0m0.004s
dfx@Kreo:~/Desktop$ cat iter.c 
#include <stdio.h>

int main ()
{
int i;
for(i = 0; i < 1000000; i++)  
  printf ("%d\n", i);
return 0;
}
dfx@Kreo:~/Desktop$ gcc -O3 iter.c 
dfx@Kreo:~/Desktop$ time ./a.out > /dev/null 

real	0m0.165s
user	0m0.164s
sys	0m0.004s

То самое дополнительное время в риал и юзер - это время, затрачиваемое на запуск интерпретатора и прочей инфраструктуры. После того, как оно запущено - данный код исполняется также (ну, или почти также) быстро.

Кстати, боян - на оффе уже было:
http://www.eveonline...a...2&page=1#27

edit: хотя нет, если по паре ноликов добавлять результат все равно сильно различается:

Исчо лог

dfx@Kreo:~/Desktop$ cat iter.py 
for x in range(100000000):
   print(x)
dfx@Kreo:~/Desktop$ time python3 iter.py > /dev/null

real	2m47.573s
user	2m47.470s
sys	0m0.064s
dfx@Kreo:~/Desktop$ cat iter.c
int main ()
{
int i;
for(i = 0; i < 100000000; i++)  
  printf ("%d\n", i);
return 0;
}
dfx@Kreo:~/Desktop$ gcc -O3 iter.c
dfx@Kreo:~/Desktop$ time ./a.out > /dev/null 

real	0m17.596s
user	0m17.517s
sys	0m0.076s

Сообщение отредактировал DarkPhoenix: 05 September 2010 - 14:11

[doommer]

Я на простеньком примере попытаюсь объяснить. Систему с кластерингом можно представить как большой автобан, но утыканный светофорами в местах, где контроль должен передаваться от одной машины к другой. В такой ситуации в-общем-то неважно, будешь ли ты жечь движок на форсаже или ехать свои пенсионерские 120 - на каждом светофоре все равно будешь стоять и ждать как все. Поэтому зачем выпендриваться?

Вот как, мне просто ухо режет слово "кластерингом" ) Имел "счастье" собирать не один кластер, как http\ftp\smtp-pop3 так и для других специфичных вычислительных целей, основываюсь на своем опыте могу сказать что в любой большой распределенной вычислительной системе есть слабые места(как я понял это и есть те самые светофоры ), светофоры могут быть двух типов программные или аппаратные (могут быть одновременно и те и те )) проблему с которыми можно решить, программно(ресталинг кода или а на *** все заново о0) и аппаратно(например если проблема с пропускной способностью сети, поставить еще в стек портов, на серверах добавить сетевух(или изменить их режим работы), протянуть дополнительный проводчик к провайдеру и т.д, вертикально\горизонтальное масштабирование ). Зачастую программные светофоры самые проблемные и решения проблем с ними, может убить много времени и чел. ресурсов, да и не всегда как показывает практика, их под силу решить той или иной команде. И кстати язык программирования тут вовсе не причем.

Что касается преимуществ С - в местах со сложной логикой работы с машинными ресурсами он может дать прирост производительности, если программист точно знает особенности работы системы и способы на них повлиять.
Но если где-то ошибется, или еще интереснее - захочется поменять систему, то все это упадет с большим треском и придется затратить дополнительные месяцы чтоб все снова заработало.
А для пайтона вроде бы есть JIT-компилятор

Еще раз повторюсь, каждому языку, своё время и место, например на каком-нибудь свичике под управлением *inx подобной ОС, интерпретатор Phyton нафиг не нужен, а вот исполняемый код С вполне там уживается.... )

[Kanthu]

/me чувствует себя тупым

[doommer]

Ну если уж ты занялся этим бредом, то теперь будь добр, сделай второй шаг, добавь в оба теста по паре нулей к циклам, а затем из полученных результатов вычти их первые результаты.

Добавил по пру нулей в каждый из исходников:

Результат

[admin@pc-server01 /root/temp]$ time python test01.py > /dev/null					(100000000)real    5m10.887suser    4m34.972ssys     0m0.240s-					(1000000)real    0m2.967suser    0m2.770ssys     0m0.009s=real 	5m7,92suser	4m32,202ssys		0m0,231s[admin@pc-server01 /root/temp]$ time ./a.out > /dev/null					(100000000)real    0m57.895suser    0m52.517ssys     0m0.161s-					(1000000)real    0m0.519suser    0m0.515ssys     0m0.000s=real 	0m57,376suser	0m52,002ssys     0m0.161s

И что дальше?

Сообщение отредактировал doommer: 05 September 2010 - 14:24

[DarkPhoenix]

И что дальше?

Ну на самом деле у тебя далеко не оптимальный синтаксис в питоне. Выше я привел пример с нормальным, там срубается 1.5-2 минуты

Да, си получается намного быстрее на итерациях. Даже с++ значительно медленнее.

[doommer]

Ну на самом деле у тебя далеко не оптимальный синтаксис в питоне.

Честно признаюсь сегодня я написал свою первую программу на Питоне

Выше я привел пример с нормальным, там срубается 1.5-2 минуты

Всё ровно есть дельта во времени, хотя делается по сути одно и тоже, причем эта дельта довольно большая.

Да, си получается намного быстрее на итерациях. Даже с++ значительно медленнее.

Можно попробовать чтения и запись в файл, вызов\завершения объектов(ну это тогда уж С++), уверен что С\С++ будут быстрей, хотя и не так на много.

адд. Да и у тебя машинка на много шустрей чем испытуемый мною )

Сообщение отредактировал doommer: 05 September 2010 - 14:30

[DarkPhoenix]

Можно попробовать чтения и запись в файл, вызов\завершения объектов(ну это тогда уж С++), уверен что С\С++ будут быстрей, хотя и не так на много.

Если выводить в /dev/null из самой программы, С делает за 18 сек, С++ за 36, питон за 2:15. Но, к счастью, приложения - это не только итерации, которые так легко щелкает си

А еще есть штучки типа http://psyco.sourceforge.net/

[doommer]

Если выводить в /dev/null из самой программы, С делает за 18 сек, С++ за 36, питон за 2:15. Но, к счастью, приложения - это не только итерации, которые так легко щелкает си

А еще есть штучки типа http://psyco.sourceforge.net/

ыыы, специально для убнутовцов
http://shootout.alio...p;lang2=python3

чего там на серверах EVE за ОС ? )

Сообщение отредактировал doommer: 05 September 2010 - 14:45

[CHoh]

Я всё жду, когда кто-нить ВНЕЗАПНО зафигачит пару страниц на Erlang с комментами про асинхронные/параллельные процессы, масштабируемость и распределённые вычисления.

Но из года в год апологетов этого ЯП на форуме не находится..

[ононимъ]

Скорее всего разница в реализации принтов.
Или в том, что питон счетчик цикла держит в памяти, а си в регистре.
А может и то и другое.
Но вообще, это все ерунда, на самом деле. В лучшем случае все это приведет к тому, что придут гуру питона и покажут код, который будет выполняться быстрее, чем его реализация в лоб на си, просто потому-что будут знать, где ошибается оптимизатор gcc. А потому придут гуру си назовут предыдущих гуру ламерами и покажут, как надо эту хрень делать на си правильно. А потом придет еще кто-нибудь и начнет вытаскивать какие-нибудь заброшенные и никому не нужные куски кода из glibc и ржать над ними, крича, что то, что написано с такими библиотеками не может работать быстро в принципе. А потом придет еще кто-нибудь...
В любом случае, ни к тему подобные споры не приведут, каждый останется при своем мнении.

[myst]

В этой теме доказано, что C очень быстро делает ничего.

[Eklykti]

Да, си получается намного быстрее на итерациях. Даже с++ значительно медленнее.

Я, конечно, ассемблера не знаю, но при кратком взгляде на сгенерированный гцц код у меня возникло впечатление, что оно этот цикл разворачивает в одну длиииинную простыню без всяких итераций.

[Trimutius III]

Я, конечно, ассемблера не знаю, но при кратком взгляде на сгенерированный гцц код у меня возникло впечатление, что оно этот цикл разворачивает в одну длиииинную простыню без всяких итераций.

Ну понимаешь важно то как это откомпилиться а не как код выглядит, и важна производительность, иногда длинная простыня даёт большую производительность чем короткий и понятный код с кучей циклов...

[myst]

Может просто сюда посмотрите?

[doommer]

Я, конечно, ассемблера не знаю, но при кратком взгляде на сгенерированный гцц код у меня возникло впечатление, что оно этот цикл разворачивает в одну длиииинную простыню без всяких итераций.

вовсе нет. Но соглашусь что gcc еще тот компилятор.

Может просто сюда посмотрите?

А может быть сюда ?

В этой теме доказано, что C очень быстро делает ничего.

если бы так думали бы все программисты, то никакой там Unix и тем боле Питона\ПХП и так далее, не было бы на свете

[myst]

если бы так думали бы все программисты, то никакой там Unix и тем боле Питона\ПХП и так далее, не было бы на свете

Сказал, как в лужу пёрднул. Ты совершенно не понял, что я имел ввиду. Ну и хрен с тобой.

[Trojan4ick]

Бред то чем вы занимаетесь. Сравнивать производительность у языков у совершенно разного уровня. Но я всё же продолжу заниматься тем же бредом

Есть два кода:

Python:

i = 0while (i < 1000000):   print i  i = i + 1

С:

#include <stdio.h>int main (){int i;for(i = 0; i < 1000000; i++)    printf ("%d\n", i);return 0;}

Итак кто же быстрей сделает эту однотипную операцию, я специально вывожу вывод в /dev/null что бы тест не зависел от фазы луны. Принтскрин с результатами в аттаче. Так что С считает на начале слово раз, а питон, на раз-два-три

Еще можно ради интереса сделать программку которая считывает данные из файла(скажем так метров 50-100 было), что-то с ними делает и записывает в другой файл. Но это всё ровно бред, я еще раз повторюсь, сравнивать эти языки дурное занятие )

Обратите внимание, что здесь не учитывается время затраченное на загрузку python интерпретатора. Теоретически при запущенном приложении данный код отработает гораздо быстрее чем при полном запуске. И пример кода слишком прост чтобы протестировать скорость работы реального приложения. Так что однозначные выводы из этого теста всё равно не сделать.