Как стать автором
Обновить

Комментарии 67

Каа — он удавом был, а не питоном ;-)
Знаю, но картинка понравилась :)
Каа был питоном. Ибо азиат. В Азии, Африке и Австралии обитают именно питоны. А в Южной америке и на Мадагаскаре — удавы.
хорошая статья, спасибо пригодится.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо! Не знал, что есть биндинги для питона :-)
PyCUDA — забавно, может есть еще и phpCUDA? :)
*сарказм*
и что же забавного?
Реализация параллельных вычислений с помощью GPU на скриптовом, интерпретируемом языке, использующемся преимущественно в совершенно иных целях и не обладающим высокой производительностью мне показалась забавной. Сарказм в том, что если идти в том же направлении — можно реализовать и CUDA на php.

(Не хотел сказать ничего плохого ни в сторону Python ни в сторону php, сам пишу на php)
Ага. Это как купить Феррари и прицепить к ней сзади якорь =)
Вы когда-нибудь работали с библиотеками для численных методов?
Нет. И?
Зачем тогда приводить такие сравнения? Просто для красного словца?

С реалиями они никак не соотносятся.
Я уверен что Феррари якорь стянет. Но на пользу он ей не пойдет.
Вот и библиотеки эти написали почему то на Сях, а GUI к ним зачем то на python+gtk.
Да — работает. Как и Феррари с якорем едет помаленьку. А ведь может быстрее.
Какая-то сквозит безграничная уверенность в просто заоблачных скоростях магического Си :)

Может погоняемся?
У меня вот есть задачка простенькая, минут на 10-20 делов — посчитать частоты слов в текстовом файле (утф-8) и вывести 100 самых частых слов.

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

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

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

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

Что до явы. Я тут как-то пробовал Zend Studio. Ужас. Офигенно мощный тормоз.
просмотр картинок — ну да, но это уже не на тему «почему хорошо делать обертку над CUDA-подобными вещами». во-вторых, уж если на то пошло, у ява-машины есть утилита (не помню как называется, но ставится вроде по умолчанию при установке jre), которая после первого запуска программы ускоряет последующие запуски, и старт практически мгновенный. такая техника еще используется, насколько я помню, для ms/open office

>Zend Studio
не пробовал, но, если он тормозит также как эклипс, значит он аналогично дерьмово сделан. попробуйте netbeans, он весьма шустрый.
А с чего вдруг Нетбинс сильно шустрее Эклипса?

Стартует Эклипс медленее, это обусловлено его архитекрурой, но в остальном большой разницы не заметно.
не знаю, с чего… видимо лучше написан. у меня он работает ощутимо шустрее (и не глючит, в отличии от эклипса). может быть, у вас посто достаточно быстрый комп, поэтому разницы не заметно? )
а стартует вроде не особо быстрее, но это и не важно
Видимо просто Эклипс какой-то не такой или не так поставился. У меня

uname -a
Linux black 2.6.28-gentoo #4 SMP PREEMPT Mon Jan 5 19:22:24 IRKT 2009 i686 Intel® Pentium® D CPU 3.00GHz GenuineIntel GNU/Linux

2G RAM

не глючит ни Клипса, ни Бинс.
На Целероне 2.4 под ВинХП тоже всё нормально работало.

Надо сказать Бинс проще в установке и освоении, там больший упор сделан на «поставил и заработало», а в Клипсу надо вникать, так как это в первую очередь платформа, а потом уже IDE.
а, ну вот, а у меня ~1.7 проц, 512 рам, видать старичек не тянет ) но бинсы вот тянет.
сижу пока на винде.
эклипс глючил иногда конкретно, переодически выскакивали какие-то ошибки, один раз вообще запилил мне js-файл (я где-то уж писал об этом), после этого я благополучно сбежал на нетбинс.

ну не знаю, насчет «вникать», по-моему вообще одинаково, модульно, те же плагины, одинаковый функционал. только у нетбинса как-то все приятнее и прямее.
В винде такое ускорение встроено в систему. Тот же фотошоп первый раз после перезагрузки грузится секунд 10. Если его закрыть и открыть снова — секунд 5. В Ms Office была похожая штука — тока она грузилась не первый раз при старте офиса, а при старте винды. В последних версиях этого уже нет. Есть в Adobe Acrobat Reader. В любом случае это костыль, который частично решает проблему, но создает другую.

>netbeans
спасибо за совет. я нашел уже nusphere phpEd. он вроде нативный
При чём здесь время компиляции?
Ну я вроде объяснял уже f33l выше, что пока запустится интерпретатор, пока он скомпилит ваш скрипт, нативное приложение уже работает.
То есть, если мы разогнались оба до 100 км/ч, то приедем в одно время. Но неплохо бы еще учитывать за сколько каждый набрал эту сотню.
Нативное приложение тоже, кстати, надо загружать.
И это время тоже бывает заметно, если загружаем не hello world, конечно.

Сейчас запустил Eclipse, стартовало вместе с полным фаршем (Java/Sql/Python/SVN/Tasks/...) 22 секунды. Если пересчитать на рабочее время (3-4 часа), то это будет менее 0.2%. На чём здесь собираетесь сэкономить?

Кстати, а сколько запускается VisualStudio с тремя-четырьмя проектами (по 5-10 тыс строк) в аналогичной конфигурации?
Студия на .net написана — так что это тоже не натив. Впрочем на глаз грузится она и работает шустрее Eclipse. Не в разы, конечно.

Возвращаясь к Вашему предложению погонятся. Не могли бы Вы все-таки набросать на питоне указанную задачу? Гонятся я не буду, просто хочу посмотреть как это правильно написать на питоне.
Вот здесь код — pastebin.com/m2552fe27
он больше экспериментальный, там выключен юникод и чтение файла сделано не итератором, а одним куском, что не есть гуд.

Еще использование в sort() параметра key=operator.itemgetter(1) вместо lambda x,y: дает порядка 10-ти процентов выигрыша.

Рекомендую написать то же самое на «компилируемом языке» и удивиться насколько мала разница. Запросто может получиться, что с первого раза обогнать Питон не получится :)

Да, вот еще похожий вариант на Руби:

c={}
t=Time.now
STDIN.each { |line| line.split.each { |w| c[w]||=0;c[w]+=1 } }
c.keys.sort.each { |w| puts "#{w}\t#{c[w]}" }
puts Time.now-t

но Руби по своей сути работает медленнее, тут ничего не поделаешь.

И вообще, я думаю, продолжение дискуссии давно стоит перенести куда-нибудь. Тут про NVIDIA все-таки :)

icq:3861496
xmpp:maxp@jabber.ru
ок. спасибо.
Рекомендую ознакомиться с насколько серьезно и эффективно подходят люди к решению численных задач с помощью Python'а

numpy.scipy.org/
numpy.scipy.org/numpydoc/numdoc.htm
www.scipy.org/

возможно тогда байндинги на NVIDIA не покажутся такими забавными.
Это прекрасно что для Python'а есть такие библиотеки. Я просто считаю что подобные библиотеки на С++ быстрее.
Сами библиотеки и есть на Си, в том-то и прикол.
Очень удобно бывает использовать гибкость Питона совместно с числодробилками.
Гибкость Питона наверняка это здорово. Просто для меня лично, например, чуждо разрабатывать десктопное приложение на некомпилируемом в машинный код языке.
Ну это уже чисто личные пристрастия.

Вот мне чуждо разрабатывать что-либо на PHP, однако я стараюсь не делать из своих предпочтений далеко идущих глобальных выводов :)
Так я и не говорю за всю Одессу. Только за себя. (Хотя хабра-народ ко мне сегодня какой-то лояльный, судя по плюсам).

В Вашем случае вы не любите язык. Я вот тот же Си тоже не люблю. Но я и не говорю, что он плох.
Я же говорю про подход вообще. Мне не понятно какие причины толкают людей на написание десктопных приложений на интерпретируемом языке.
>Мне не понятно какие причины толкают людей на написание десктопных приложений на интерпретируемом языке
я ниже вам написал, причем к десктопным приложениям это больше всего относится.

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

думаю, у вас и у плюсующих/минусующих просто еще недостаточно опыта, потому что кроме скорости работы кода есть еще масса факторов, особенно в сложных проектах.
>я разницу в скорости между нормально написанными десктопными приложениями на си и яве например замечаю только при их старте или подгрузке компонентов, а вы?

Я вообще не замечаю. У меня нет ничего на яве. На .Net и то только VisualStudio =)
и все лицензионное, да? :]
Лицензия как-то влияет на скорость? =)

PS. О минусовать пошли. Людям стало скучно
А Вы какие приложения разрабатывали?

Дело в том, что большинство программистов решают конкретные программистские задачи, а не идеологические.

Практические задачи пишутся под конкретные условия за определенное время.

Приложение на Питоне, работающее на 10% медленнее, чем аналогичное на Си, но укладывающееся в заданные временные рамки значительно лучше приложения на Си, которое работает на 10% быстрее, но по непонятным причинам падает в кору в самых неподходящих местах.

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

Есть такое наглядное правило 10/90 — «десять процентов кода потребляют девяносто процентов машинного времени».
И очень часто эти самые дорогие 10% это как раз уже донельзя соптимизированные библиотечные функции работы с массивами, строками, списками.
Можно убиться оптимизировать остальные 90% кода и не выиграть по сути ничего.
У меня нет идеализации. Есть простая логика.
1. Запустить виртуальную машину
2. С помощью JIT-компиляции получить машинный код
3. Выполнить машинный код

3 шага.

1. Выполнить машинный код.

1 шаг, раный 3му из предыдущего варианта.

В итоге по-моему очевидно, что сделать 1 шаг быстрее чем три.

Со всем остальным я соглашусь, только соотношение обычно 20/80.
Соотношение именно 10/90 (см. google: 90/10 rule), а если оно вдруг 80/20, то скорее всего просто кода мало написано или в нем есть просто лишняя часть :)

Шаг номер один на самом деле вовсе не такой тривиальный, как кажется.
Понятие динамическая линковка знакомо?

И я не очень понял почему мы вдруг сравниваем время загрузки какой-то маленькой программки и время загрузки jvm? Почему мы вообще перешли на обсуждение времени запуска? На мой взгляд оно находится далеко не на первом месте по важности.

Про соотношение. Я исходил из этого ru.wikipedia.org/wiki/Закон_Парето

Про динамическую линковку лучше поподробнее.

Если брать ваш пример когда с утра загрузили, вечером закрыли — возможно и не важно.
Если программа постоянно в памяти не висит, а отрабатывает свое и выходит — время загрузки уже существеннно.
возможно что на языке более низкого уровня, к примеру C или ассемблере, еще быстрее. впрочем, даже не возможно, а так и есть. но порой скорость разработки важнее скорости выполнения ;)
Главное, чтобы после быстрой разработки и получения результатов у написавшего хватало ума/освободившегося времени/терпения их проверить и проанализировать, а не публиковать результаты :) Это я про науку.
Плюсы здесь как пример — можно поставить любой компилируемый язык. Что до скорости — то как программер я Вас, конечно, прекрасно понимаю. Но как юзверю, скорость выполнения мне важнее.
а я не вижу никакого противоречия, напротив. вы видимо не понимаете, что на питоне в данном случае реализоввываются не сами вычисления, а высокоуровневый интерфейс к устройству. смысл как раз в том, чтобы контролировать объекты, параллельно производящие интенсивные вычисления, и для контроля важна гибкость и удобство, а не производительность.
тот же erlang для чего сделан, не задумывались?
по вашему, графические движки, например, надо на ассемблере писать, работая напрямую с видеокартой?
а вот php тут не к месту по многим причинам.
Объясните пожалуйста, по каким причинам php здесь более не к месту, чем python?
(не считая прямого назначения php, а то тут еще начнут говорить, что php это просто «инструменты для создания персональных веб-страниц» или препроцессор гипертекста. Давайте говорить об архитектурных особенностях языков, делающих уместными те или иные вещи)

p.s.: я не пытаюсь спорить, ибо тонкости питона мне неведомы :) Я просто интересуюсь.
как раз назначение тут играет большую роль. пхп для веб-разработки, так исторически сложилось, и продолжает развивается он только в эту сторону. питон же универсален, и как ни пародоксально, на нем эффективно решается широкий круг задач, от игровых серверов до маленьких утилит. так он устроен, гибко, красиво и лаконично.
не буду сравнивать сам язык с пхп, потому что это ведет прямо к холивару — надеюсь, вы не с этой целью задали вопрос, хоть он уже и не по теме ветки. но язык характеризует не только его архитектура, но и набор библиотек, расширений, фреймворков и т.д.
и если посмотреть с этой точки зрения на пхп и питон, то становится хорошо видно, что более уместно.

я тоже пишу пока еще на пхп, кстати, если что.
да видел я это все )
Ню-ню. Если закрыть глаза на стандартный пролог <?php, то РНР вполне себе годный general-purpose язык. Тут вам выше привели phpшные биндинги к GTK, QT и WinAPI. Рисовать гуй можно. Java-like ООП присутствует. А игрища с блудницами реализуются посредством расширений на C/C++. И вообще, UNIX-way ещё никто не отменял.
Я это всё к тому, что на РНР можно делать практически всё то же, что и на питоне. Да, более многословно, с бóльшим геморроем — но можно. Поправьте меня, если я не прав (особенно буду признателен за примеры «неуместности» РНР в эээ… коде).
>Да, более многословно, с бóльшим геморроем — но можно.
ключевая фраза. спрашивается, а зачем?
пикрелэйтед, ага lurkmore.ru/images/2/21/Linux_doma.jpg
Python значительно более выразительный и логически выдержанный язык нежели PHP.
И в нём постарались избежать явно выраженных проблем с производительностью.
К примеру в Питоне различаются по внутреннему устройству, например,
tuple: (1,2,3,4,) и list: [1,2,3,4,] — первый immutable и поэтому иногда более эффективен.

В Питоне более эффективней, чем в ПХП реализован hash. Так как в ПХП хочешь не хочешь поддерживается последовательность ключей, а в Питоне есть варианты.

Еще одна интересная особенность — это генераторы, советую почитать про них, если действительно интересно могу найти ссылку на pdf. Только читать надо не поверхностно, а разбирать примеры. Иначе не понятно в чём прикол.

Простые примерчики:

[ (a,a*a) for a in (1,2,3,4) if a != 2 ]
результат [(1, 1), (3, 9), (4, 16)]
смысл в том, что конструктор списка выполняется в Си коде, в отличие от
общепринятого интерпретируемого for a in (1,2,3,4) {… }

а вот еще интересный момент (генератор)

i = ( (a,a*a) for a in (1,2,3,4) if a != 2 )

>>> i.next()
(1, 1)
>>> i.next()
(3, 9)
>>> i.next()
(4, 16)
>>>

Это тоже, что выше. НО! Генератор i хранит в себе стейт и начинает выполняться _только_ при первом next().
такого рода вещи позволяют записывать алгоритмы очень компактно и эффективно.
Да — движки надо писать на языке компилируемом в машинный код. В том числе с ассемблерными вставками
скажите это разработчикам eve-online

и я говорил не про вставки. движок это многоуровневая штука, внизу работа с железом, над ней directx/opengl, еще выше ваш фреймворк, а над ним логика. на каждом уровне неизбежная потеря производительности. и движком называется все это вцелом, а не только то, что внизу.
забавно, да?
eve мне всегда приводят в пример в этом случае =)
Про движок — забавно да, но это не отменят моего мнения, что все это надо писать на компилируемом языке. Да — бывает лень и хочется чего то типа
i = ( (a,a*a) for a in (1,2,3,4) if a != 2 )

а приходится вручную выделять память под массивы и гонять обычные циклы с индексом.
в том-то и дело )
функционал, у которого критична производительность, естественно надо решать на си и т.д… но на определенном уровне становится критичной не скорость работы кода, а скорость разработки, отсутствие длительных компиляций, легкость изменения, отладки, поддержки кода и прочее. я бы с радостью писал все на си, но если одна вещь пишется на си за полгода с огромными усилиями, а другая за месяц-другой с удовольствием, и при этом потеря в скорости несколько процентов, — выбор очевиден.
Согласен. Сравнение «полгода» и «месяц-другой» не в пользу первого. Но мне кажется это крайности. Тем более Вы предлагаете писать так не критичные к скорости части. Как правило все подразумевают под этим GUI. Давайте возьмем Delphi и Python. Я даже не буду утверждать, что на Delphi все сделать быстрее. Но я буду утверждать, что на Delphi это сделать не медленнее. При том что Delphi — компилируемый язык. Там нет длительных компиляций, там замечательный отладчик. Поддержка кода? Что по мне так разбираться в обычных array, for и if проще, чем в этом «i = ( (a,a*a) for a in (1,2,3,4) if a != 2 )».
Зачем Питон на десктопе? ;-)
дельфи, омг…
ох ну кроссплатформенность, хотя бы, про язык промолчу…
а на питоне вас никто не заставляет писать несколько строчек в одну, кашу легко в нагородить на любом языке.
О, для Вас писать на Delphi — это «ОМГ». Прекрасно. Тогда Вы можете понять мои чувства, когда мне предлагают писать на питоне под десктоп. =)

Кроссплатформенность. Если это действительно кому-то надо, то можно найти средства компилить паскаль и под линукс.

Ладно — давайте заканчивать это оффтопик.
Кстати, а интересный вопрос — что такое десктоп?

У меня из приложений сейчас самое популярное — Firefox,
Среда разработчика — Eclipse,
Еще бывает — Gimp и Picasa,
Кроме этого примочки от Gnome — терминал, часы, иконки.

Если брать это, как готовую платформу, то что сюда дописывать на Си?
Десктоп — то что выполняется у вас локально. Все что Вы перечислили -десктоп. Не десктоп — это то, что выполняется на Web-сервере.

Что дописывать? Вас все устраивает? Ну и прекрасно — ничего не надо дописывать.
Меня не устраивает тормознутость фокса и эклайпса — я нашел им замену, и меня тоже все устраивает.

Спасибо за диалог. Всего доброго.
Какие возможности у этой библиотеки? Какие грабли? Можно ли использовать в реальных проектах?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.