Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 67
Каа — он удавом был, а не питоном ;-)
хорошая статья, спасибо пригодится.
Спасибо! Не знал, что есть биндинги для питона :-)
PyCUDA — забавно, может есть еще и phpCUDA? :)
*сарказм*
*сарказм*
и что же забавного?
Реализация параллельных вычислений с помощью GPU на скриптовом, интерпретируемом языке, использующемся преимущественно в совершенно иных целях и не обладающим высокой производительностью мне показалась забавной. Сарказм в том, что если идти в том же направлении — можно реализовать и CUDA на php.
(Не хотел сказать ничего плохого ни в сторону Python ни в сторону php, сам пишу на php)
(Не хотел сказать ничего плохого ни в сторону Python ни в сторону php, сам пишу на php)
Ага. Это как купить Феррари и прицепить к ней сзади якорь =)
Вы когда-нибудь работали с библиотеками для численных методов?
Нет. И?
Зачем тогда приводить такие сравнения? Просто для красного словца?
С реалиями они никак не соотносятся.
С реалиями они никак не соотносятся.
Я уверен что Феррари якорь стянет. Но на пользу он ей не пойдет.
Вот и библиотеки эти написали почему то на Сях, а GUI к ним зачем то на python+gtk.
Да — работает. Как и Феррари с якорем едет помаленьку. А ведь может быстрее.
Вот и библиотеки эти написали почему то на Сях, а GUI к ним зачем то на python+gtk.
Да — работает. Как и Феррари с якорем едет помаленьку. А ведь может быстрее.
Какая-то сквозит безграничная уверенность в просто заоблачных скоростях магического Си :)
Может погоняемся?
У меня вот есть задачка простенькая, минут на 10-20 делов — посчитать частоты слов в текстовом файле (утф-8) и вывести 100 самых частых слов.
Я пишу на Питоне и Java, а вы на Си. Погладим на сколько ваша феррари будет быстрее, если поедет конечно :)
Может погоняемся?
У меня вот есть задачка простенькая, минут на 10-20 делов — посчитать частоты слов в текстовом файле (утф-8) и вывести 100 самых частых слов.
Я пишу на Питоне и Java, а вы на Си. Погладим на сколько ваша феррари будет быстрее, если поедет конечно :)
Вы будете считать слова в файле с помощью CUDA? :)
А как Вы будете учитывать время, необходимое Питону и Java для компиляции?
это время загрузки кода, не более ) а если эта программа запущена всегда, то это вообще можно не учитывать.
не говоря уже о том, что ведь можно делать прекомпиляцию байт-кода, и в таком случае разницы ноль.
и между прочим, скорость работы виртуальной машины явы сейчас во многих случаях догнала си, на эту тему есть материал в инете, можете поискать
не говоря уже о том, что ведь можно делать прекомпиляцию байт-кода, и в таком случае разницы ноль.
и между прочим, скорость работы виртуальной машины явы сейчас во многих случаях догнала си, на эту тему есть материал в инете, можете поискать
Ну не скажите — скорость загрузки, это очень важно. Хотя, конечно, все зависит от ситуации — если Вы при старте системы грузите фотошоп и потом день в нем работаете, можно и потерпеть. Но наверняка для просмотра картинок у Вас стоит что-то легкое и шустрое. И была бы альтернатива фотошопу, такая же мощная, но легкая и шустрая — фотошоп бы забросили.
Да, конечно, я соглашусь, что после компиляции байт-кода разницы может быть ноль. Какая разница, если в итоге тот же машинный код.
Просто пока оно запустится и скомпилируется, в изначально скомпиленном приложении уже работают.
Что до явы. Я тут как-то пробовал Zend Studio. Ужас. Офигенно мощный тормоз.
Да, конечно, я соглашусь, что после компиляции байт-кода разницы может быть ноль. Какая разница, если в итоге тот же машинный код.
Просто пока оно запустится и скомпилируется, в изначально скомпиленном приложении уже работают.
Что до явы. Я тут как-то пробовал Zend Studio. Ужас. Офигенно мощный тормоз.
просмотр картинок — ну да, но это уже не на тему «почему хорошо делать обертку над CUDA-подобными вещами». во-вторых, уж если на то пошло, у ява-машины есть утилита (не помню как называется, но ставится вроде по умолчанию при установке jre), которая после первого запуска программы ускоряет последующие запуски, и старт практически мгновенный. такая техника еще используется, насколько я помню, для ms/open office
>Zend Studio
не пробовал, но, если он тормозит также как эклипс, значит он аналогично дерьмово сделан. попробуйте netbeans, он весьма шустрый.
>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.
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-файл (я где-то уж писал об этом), после этого я благополучно сбежал на нетбинс.
ну не знаю, насчет «вникать», по-моему вообще одинаково, модульно, те же плагины, одинаковый функционал. только у нетбинса как-то все приятнее и прямее.
сижу пока на винде.
эклипс глючил иногда конкретно, переодически выскакивали какие-то ошибки, один раз вообще запилил мне js-файл (я где-то уж писал об этом), после этого я благополучно сбежал на нетбинс.
ну не знаю, насчет «вникать», по-моему вообще одинаково, модульно, те же плагины, одинаковый функционал. только у нетбинса как-то все приятнее и прямее.
В винде такое ускорение встроено в систему. Тот же фотошоп первый раз после перезагрузки грузится секунд 10. Если его закрыть и открыть снова — секунд 5. В Ms Office была похожая штука — тока она грузилась не первый раз при старте офиса, а при старте винды. В последних версиях этого уже нет. Есть в Adobe Acrobat Reader. В любом случае это костыль, который частично решает проблему, но создает другую.
>netbeans
спасибо за совет. я нашел уже nusphere phpEd. он вроде нативный
>netbeans
спасибо за совет. я нашел уже nusphere phpEd. он вроде нативный
При чём здесь время компиляции?
Ну я вроде объяснял уже f33l выше, что пока запустится интерпретатор, пока он скомпилит ваш скрипт, нативное приложение уже работает.
То есть, если мы разогнались оба до 100 км/ч, то приедем в одно время. Но неплохо бы еще учитывать за сколько каждый набрал эту сотню.
То есть, если мы разогнались оба до 100 км/ч, то приедем в одно время. Но неплохо бы еще учитывать за сколько каждый набрал эту сотню.
Нативное приложение тоже, кстати, надо загружать.
И это время тоже бывает заметно, если загружаем не hello world, конечно.
Сейчас запустил Eclipse, стартовало вместе с полным фаршем (Java/Sql/Python/SVN/Tasks/...) 22 секунды. Если пересчитать на рабочее время (3-4 часа), то это будет менее 0.2%. На чём здесь собираетесь сэкономить?
Кстати, а сколько запускается VisualStudio с тремя-четырьмя проектами (по 5-10 тыс строк) в аналогичной конфигурации?
И это время тоже бывает заметно, если загружаем не 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
он больше экспериментальный, там выключен юникод и чтение файла сделано не итератором, а одним куском, что не есть гуд.
Еще использование в 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 не покажутся такими забавными.
numpy.scipy.org/
numpy.scipy.org/numpydoc/numdoc.htm
www.scipy.org/
возможно тогда байндинги на NVIDIA не покажутся такими забавными.
Это прекрасно что для Python'а есть такие библиотеки. Я просто считаю что подобные библиотеки на С++ быстрее.
Сами библиотеки и есть на Си, в том-то и прикол.
Очень удобно бывает использовать гибкость Питона совместно с числодробилками.
Очень удобно бывает использовать гибкость Питона совместно с числодробилками.
Гибкость Питона наверняка это здорово. Просто для меня лично, например, чуждо разрабатывать десктопное приложение на некомпилируемом в машинный код языке.
Ну это уже чисто личные пристрастия.
Вот мне чуждо разрабатывать что-либо на PHP, однако я стараюсь не делать из своих предпочтений далеко идущих глобальных выводов :)
Вот мне чуждо разрабатывать что-либо на PHP, однако я стараюсь не делать из своих предпочтений далеко идущих глобальных выводов :)
Так я и не говорю за всю Одессу. Только за себя. (Хотя хабра-народ ко мне сегодня какой-то лояльный, судя по плюсам).
В Вашем случае вы не любите язык. Я вот тот же Си тоже не люблю. Но я и не говорю, что он плох.
Я же говорю про подход вообще. Мне не понятно какие причины толкают людей на написание десктопных приложений на интерпретируемом языке.
В Вашем случае вы не любите язык. Я вот тот же Си тоже не люблю. Но я и не говорю, что он плох.
Я же говорю про подход вообще. Мне не понятно какие причины толкают людей на написание десктопных приложений на интерпретируемом языке.
>Мне не понятно какие причины толкают людей на написание десктопных приложений на интерпретируемом языке
я ниже вам написал, причем к десктопным приложениям это больше всего относится.
причины очень простые — желание с удовольствием создавать продукт и не писать при этом намного больше сложного хрупкого кода при практически незаметной разнице.
я разницу в скорости между нормально написанными десктопными приложениями на си и яве например замечаю только при их старте или подгрузке компонентов, а вы?
думаю, у вас и у плюсующих/минусующих просто еще недостаточно опыта, потому что кроме скорости работы кода есть еще масса факторов, особенно в сложных проектах.
я ниже вам написал, причем к десктопным приложениям это больше всего относится.
причины очень простые — желание с удовольствием создавать продукт и не писать при этом намного больше сложного хрупкого кода при практически незаметной разнице.
я разницу в скорости между нормально написанными десктопными приложениями на си и яве например замечаю только при их старте или подгрузке компонентов, а вы?
думаю, у вас и у плюсующих/минусующих просто еще недостаточно опыта, потому что кроме скорости работы кода есть еще масса факторов, особенно в сложных проектах.
А Вы какие приложения разрабатывали?
Дело в том, что большинство программистов решают конкретные программистские задачи, а не идеологические.
Практические задачи пишутся под конкретные условия за определенное время.
Приложение на Питоне, работающее на 10% медленнее, чем аналогичное на Си, но укладывающееся в заданные временные рамки значительно лучше приложения на Си, которое работает на 10% быстрее, но по непонятным причинам падает в кору в самых неподходящих местах.
Еще мне кажется, что у Вас есть какое-то недопонимание связанное с машинным кодом, некая его идеализация. Даже если не говорить о таких экстремальных случаях, когда байткод может выполняться быстрее аналогичного сишного только лишь потому, что влазит в процессорный кэш.
Есть такое наглядное правило 10/90 — «десять процентов кода потребляют девяносто процентов машинного времени».
И очень часто эти самые дорогие 10% это как раз уже донельзя соптимизированные библиотечные функции работы с массивами, строками, списками.
Можно убиться оптимизировать остальные 90% кода и не выиграть по сути ничего.
Дело в том, что большинство программистов решают конкретные программистские задачи, а не идеологические.
Практические задачи пишутся под конкретные условия за определенное время.
Приложение на Питоне, работающее на 10% медленнее, чем аналогичное на Си, но укладывающееся в заданные временные рамки значительно лучше приложения на Си, которое работает на 10% быстрее, но по непонятным причинам падает в кору в самых неподходящих местах.
Еще мне кажется, что у Вас есть какое-то недопонимание связанное с машинным кодом, некая его идеализация. Даже если не говорить о таких экстремальных случаях, когда байткод может выполняться быстрее аналогичного сишного только лишь потому, что влазит в процессорный кэш.
Есть такое наглядное правило 10/90 — «десять процентов кода потребляют девяносто процентов машинного времени».
И очень часто эти самые дорогие 10% это как раз уже донельзя соптимизированные библиотечные функции работы с массивами, строками, списками.
Можно убиться оптимизировать остальные 90% кода и не выиграть по сути ничего.
У меня нет идеализации. Есть простая логика.
1. Запустить виртуальную машину
2. С помощью JIT-компиляции получить машинный код
3. Выполнить машинный код
3 шага.
1. Выполнить машинный код.
1 шаг, раный 3му из предыдущего варианта.
В итоге по-моему очевидно, что сделать 1 шаг быстрее чем три.
Со всем остальным я соглашусь, только соотношение обычно 20/80.
1. Запустить виртуальную машину
2. С помощью JIT-компиляции получить машинный код
3. Выполнить машинный код
3 шага.
1. Выполнить машинный код.
1 шаг, раный 3му из предыдущего варианта.
В итоге по-моему очевидно, что сделать 1 шаг быстрее чем три.
Со всем остальным я соглашусь, только соотношение обычно 20/80.
Соотношение именно 10/90 (см. google: 90/10 rule), а если оно вдруг 80/20, то скорее всего просто кода мало написано или в нем есть просто лишняя часть :)
Шаг номер один на самом деле вовсе не такой тривиальный, как кажется.
Понятие динамическая линковка знакомо?
И я не очень понял почему мы вдруг сравниваем время загрузки какой-то маленькой программки и время загрузки jvm? Почему мы вообще перешли на обсуждение времени запуска? На мой взгляд оно находится далеко не на первом месте по важности.
Шаг номер один на самом деле вовсе не такой тривиальный, как кажется.
Понятие динамическая линковка знакомо?
И я не очень понял почему мы вдруг сравниваем время загрузки какой-то маленькой программки и время загрузки jvm? Почему мы вообще перешли на обсуждение времени запуска? На мой взгляд оно находится далеко не на первом месте по важности.
Про соотношение. Я исходил из этого ru.wikipedia.org/wiki/Закон_Парето
Про динамическую линковку лучше поподробнее.
Если брать ваш пример когда с утра загрузили, вечером закрыли — возможно и не важно.
Если программа постоянно в памяти не висит, а отрабатывает свое и выходит — время загрузки уже существеннно.
Про динамическую линковку лучше поподробнее.
Если брать ваш пример когда с утра загрузили, вечером закрыли — возможно и не важно.
Если программа постоянно в памяти не висит, а отрабатывает свое и выходит — время загрузки уже существеннно.
возможно что на языке более низкого уровня, к примеру C или ассемблере, еще быстрее. впрочем, даже не возможно, а так и есть. но порой скорость разработки важнее скорости выполнения ;)
Главное, чтобы после быстрой разработки и получения результатов у написавшего хватало ума/освободившегося времени/терпения их проверить и проанализировать, а не публиковать результаты :) Это я про науку.
Плюсы здесь как пример — можно поставить любой компилируемый язык. Что до скорости — то как программер я Вас, конечно, прекрасно понимаю. Но как юзверю, скорость выполнения мне важнее.
а я не вижу никакого противоречия, напротив. вы видимо не понимаете, что на питоне в данном случае реализоввываются не сами вычисления, а высокоуровневый интерфейс к устройству. смысл как раз в том, чтобы контролировать объекты, параллельно производящие интенсивные вычисления, и для контроля важна гибкость и удобство, а не производительность.
тот же erlang для чего сделан, не задумывались?
по вашему, графические движки, например, надо на ассемблере писать, работая напрямую с видеокартой?
а вот php тут не к месту по многим причинам.
тот же erlang для чего сделан, не задумывались?
по вашему, графические движки, например, надо на ассемблере писать, работая напрямую с видеокартой?
а вот php тут не к месту по многим причинам.
Объясните пожалуйста, по каким причинам php здесь более не к месту, чем python?
(не считая прямого назначения php, а то тут еще начнут говорить, что php это просто «инструменты для создания персональных веб-страниц» или препроцессор гипертекста. Давайте говорить об архитектурных особенностях языков, делающих уместными те или иные вещи)
p.s.: я не пытаюсь спорить, ибо тонкости питона мне неведомы :) Я просто интересуюсь.
(не считая прямого назначения php, а то тут еще начнут говорить, что php это просто «инструменты для создания персональных веб-страниц» или препроцессор гипертекста. Давайте говорить об архитектурных особенностях языков, делающих уместными те или иные вещи)
p.s.: я не пытаюсь спорить, ибо тонкости питона мне неведомы :) Я просто интересуюсь.
как раз назначение тут играет большую роль. пхп для веб-разработки, так исторически сложилось, и продолжает развивается он только в эту сторону. питон же универсален, и как ни пародоксально, на нем эффективно решается широкий круг задач, от игровых серверов до маленьких утилит. так он устроен, гибко, красиво и лаконично.
не буду сравнивать сам язык с пхп, потому что это ведет прямо к холивару — надеюсь, вы не с этой целью задали вопрос, хоть он уже и не по теме ветки. но язык характеризует не только его архитектура, но и набор библиотек, расширений, фреймворков и т.д.
и если посмотреть с этой точки зрения на пхп и питон, то становится хорошо видно, что более уместно.
я тоже пишу пока еще на пхп, кстати, если что.
не буду сравнивать сам язык с пхп, потому что это ведет прямо к холивару — надеюсь, вы не с этой целью задали вопрос, хоть он уже и не по теме ветки. но язык характеризует не только его архитектура, но и набор библиотек, расширений, фреймворков и т.д.
и если посмотреть с этой точки зрения на пхп и питон, то становится хорошо видно, что более уместно.
я тоже пишу пока еще на пхп, кстати, если что.
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().
такого рода вещи позволяют записывать алгоритмы очень компактно и эффективно.
И в нём постарались избежать явно выраженных проблем с производительностью.
К примеру в Питоне различаются по внутреннему устройству, например,
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, еще выше ваш фреймворк, а над ним логика. на каждом уровне неизбежная потеря производительности. и движком называется все это вцелом, а не только то, что внизу.
забавно, да?
и я говорил не про вставки. движок это многоуровневая штука, внизу работа с железом, над ней directx/opengl, еще выше ваш фреймворк, а над ним логика. на каждом уровне неизбежная потеря производительности. и движком называется все это вцелом, а не только то, что внизу.
забавно, да?
eve мне всегда приводят в пример в этом случае =)
Про движок — забавно да, но это не отменят моего мнения, что все это надо писать на компилируемом языке. Да — бывает лень и хочется чего то типа
i = ( (a,a*a) for a in (1,2,3,4) if a != 2 )
а приходится вручную выделять память под массивы и гонять обычные циклы с индексом.
Про движок — забавно да, но это не отменят моего мнения, что все это надо писать на компилируемом языке. Да — бывает лень и хочется чего то типа
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 )».
Зачем Питон на десктопе? ;-)
Зачем Питон на десктопе? ;-)
дельфи, омг…
ох ну кроссплатформенность, хотя бы, про язык промолчу…
а на питоне вас никто не заставляет писать несколько строчек в одну, кашу легко в нагородить на любом языке.
ох ну кроссплатформенность, хотя бы, про язык промолчу…
а на питоне вас никто не заставляет писать несколько строчек в одну, кашу легко в нагородить на любом языке.
Кстати, а интересный вопрос — что такое десктоп?
У меня из приложений сейчас самое популярное — Firefox,
Среда разработчика — Eclipse,
Еще бывает — Gimp и Picasa,
Кроме этого примочки от Gnome — терминал, часы, иконки.
Если брать это, как готовую платформу, то что сюда дописывать на Си?
У меня из приложений сейчас самое популярное — Firefox,
Среда разработчика — Eclipse,
Еще бывает — Gimp и Picasa,
Кроме этого примочки от Gnome — терминал, часы, иконки.
Если брать это, как готовую платформу, то что сюда дописывать на Си?
Десктоп — то что выполняется у вас локально. Все что Вы перечислили -десктоп. Не десктоп — это то, что выполняется на Web-сервере.
Что дописывать? Вас все устраивает? Ну и прекрасно — ничего не надо дописывать.
Меня не устраивает тормознутость фокса и эклайпса — я нашел им замену, и меня тоже все устраивает.
Спасибо за диалог. Всего доброго.
Что дописывать? Вас все устраивает? Ну и прекрасно — ничего не надо дописывать.
Меня не устраивает тормознутость фокса и эклайпса — я нашел им замену, и меня тоже все устраивает.
Спасибо за диалог. Всего доброго.
Релейтед пик вин :)
Какие возможности у этой библиотеки? Какие грабли? Можно ли использовать в реальных проектах?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
NVIDIA CUDA(сиквел) — Настройка PyCUDA