Python vs Ruby
maxp
Попробуем объективно оценить "за" и "против".
На всякий случай замечу, что Питон это не Джанго, а Руби это не Рельсы.
Олег Рощупкин
интерпретируемых языков, хотя сейчас всё уже не так просто - Руби с
новой версией сильно разогналась. Хотя в принципе можно взять тот же
Parrot и достичь на нём примерно одинаковой скорости, что для Руби,
что для Питона.
27.04.2009, в 13:03, maxp написал(а):
jja...@gmail.com
jahson
Maxim Penzin
> Можно начать со скорости. Питон одно время был одним из самых быстрых
> интерпретируемых языков, хотя сейчас всё уже не так просто - Руби с
> новой версией сильно разогналась. Хотя в принципе можно взять тот же
> Parrot и достичь на нём примерно одинаковой скорости, что для Руби,
Одинаково медленной скорости? :)
Предлагаю поглядеть на существующие мэйнстримы,
у меня в дистрибутиве это Python 2.6.2 и Ruby 1.8.7,
(вроде 1.9 тоже достаточно стабилен, но просто у меня он не собран).
Может набросать какой-нибудь тестик
по поводу вызовов методов экземпляра/класса/унаследованных,
туда же работу со списком или с массивом.
Создание новых объектов тоже не плохо было бы попробовать,
но как по скорости, так и по памяти.
Есть желающие попробовать?
--
-- mpe...@gmail.com icq:3861496 www.penzin.ru --
Олег Рощупкин
можно посмотреть в сторону http://shootout.alioth.debian.org/.
Потнятно, что там тоже не всё радужно.
Да и вообще с тестами дело такое - нужно учитывать погрешности, как
минимум, да и до кучи статистическую обработку разуметь.
27.04.2009, в 19:36, Maxim Penzin написал(а):
Evgeniy Potapov
кажется.
Давно когда то я больше ради шутки
мерил двойные против одинарных
кавычек в php.
Ну понятно да, что одинарные быстрее и
гораздо.
Но потом в голову пришло добавить
простейший селект по примари кею без
всяких условий.
и сравнить время выполнения снова.
Если без селектов то соотношения '
против " было предположим как t мс
против t*2 мс (все просто из головы).
То с селектом стало t против t*1.000000001 мс
(я опять же утрирую).
Если возвращатся к тому что эти языки
предназначены прежде всего для
вебразработки, а вебразработка в 99
процентах случаях это не
матвычисления а сортировка,
фильтрация и агрегация данных то и
мерить надо, если подходить к этому
практически - именно на этих задачах.
Ну и плюс еще интересны был бы
бенчмарки по выполнению (я бы сказал
интерпретации, но я путаюсь в этих
словах) сложных ООП структур на случай
если девелоперам очень захочется
наворотить чтото огромное, ну то есть
опять же вполне реальная ситуация -
проект запустили а там хз что. Чтобы
сразу знать что может случиться. Вот,
так что если и замерять то мне кажется
набор должен быть примерно такой:
1. Вычисления. Нагрузка на процессор.
2. Вычисления. Нагрузка на память.
3. №1 и №2 + селект из БД
4. Навороченная ООП структура.
5. №4 + селект из БД.
И я бы добавил php ага :)
Evgeniy Potapov
Maxim Penzin
> В принципе, кроме написания своих тестов, которые будут сравнивать,
> можно посмотреть в сторону http://shootout.alioth.debian.org/.
> Потнятно, что там тоже не всё радужно.
> Да и вообще с тестами дело такое - нужно учитывать погрешности, как
> минимум, да и до кучи статистическую обработку разуметь.
Я честно говоря вообще не понял что показывают те тесты.
Точнее какую практическую ценность они имеют для меня :)
Потому, что если говорить о математике, то для того же Питона
есть большой набор специализированных мат. библиотек.
Но если их использовать в тестах, то при чем здесь Питон не понятно.
Maxim Penzin
> кажется.
> Давно когда то я больше ради шутки
> мерил двойные против одинарных
> кавычек в php.
> Ну понятно да, что одинарные быстрее и
> гораздо.
> Но потом в голову пришло добавить
> простейший селект по примари кею без
> всяких условий.
> и сравнить время выполнения снова.
>
> Если без селектов то соотношения '
> против " было предположим как t мс
> против t*2 мс (все просто из головы).
> То с селектом стало t против t*1.000000001 мс
> (я опять же утрирую).
Это всё к тому, что обращения к диску стоят дорого?
Факт медицинский, ага.
> 1. Вычисления. Нагрузка на процессор.
> 2. Вычисления. Нагрузка на память.
> 3. №1 и №2 + селект из БД
> 4. Навороченная ООП структура.
> 5. №4 + селект из БД.
>
> И я бы добавил php ага :)
Я тут некоторое время назад уже задавал простенькую задачку -
посчитать N самых частых слов в текстовом файле.
У меня тут остались два интересных кусочка:
- - -
c={}
STDIN.each { |line| line.split.each { |w| c[w]||=0;c[w]+=1 } }
c.keys.sort.each { |w| puts "#{w}\t#{c[w]}" }
- - -
import operator, re, time, sys
r=re.compile( r'[\s\.,!?;]+' )
res={}
resget = res.get
for w in r.split( open(sys.argv[1]).read() ):
# try: res[w] += 1;
# except: res[w] = 1
res[w] = resget(w,0)+1
freq=res.items()
freq.sort( key=operator.itemgetter(1) )
for w,f in freq: print w,f
- - -
Evgeniy Potapov
On 28.04.2009, at 0:19, Maxim Penzin wrote:
>> Вообще конечно все это синтетика мне
>> кажется.
>> Давно когда то я больше ради шутки
>> мерил двойные против одинарных
>> кавычек в php.
>> Ну понятно да, что одинарные быстрее и
>> гораздо.
>> Но потом в голову пришло добавить
>> простейший селект по примари кею без
>> всяких условий.
>> и сравнить время выполнения снова.
>>
>> Если без селектов то соотношения '
>> против " было предположим как t мс
>> против t*2 мс (все просто из головы).
>> То с селектом стало t против t*1.000000001 мс
>> (я опять же утрирую).
>
> Это всё к тому, что обращения к диску
> стоят дорого?
> Факт медицинский, ага.
большинстве крупного вебдева
произвоительность вычислений
практически не играет никакой роли (ну
если среда совсем не скатывается в
тормоза конечно), просто из-за
специфики этого самого вебдева.
Соответственно и бенчи очень такая
сомительная вещь ;)
Evgeniy Potapov
Олег Рощупкин
протестировать. Естественно они достаточно синтетические - ребята там
прямо говорят, что они тестируют реализации языков. А тестировать
реализации вряд ли можно, плотно шурша по диску и спрашивая бд.
28.04.2009, в 0:07, Maxim Penzin написал(а):
> Я честно говоря вообще не понял что показывают те тесты.
> Точнее какую практическую ценность они имеют для меня :)
>
> Потому, что если говорить о математике, то для того же Питона
> есть большой набор специализированных мат. библиотек.
> Но если их использовать в тестах, то при чем здесь Питон не понятно.
>
>
> --
> -- mpe...@gmail.com icq:3861496 www.penzin.ru --
>
> >
Олег Рощупкин
Особенно как вон кидали ссылку в скайп, про преимущество руби 1.9,
которое рассматривать нужно было только с позиции "по сравнению с руби
1.8".
Если же мы будем подходить с позиций хайлоад вебдева, то нам скорость
исполнения пофигу до той поры, пока всё остальное работает медленно.
Но тогда почти нет смысла тестировать хэш лукапы и прочее.
Вообще, конечно, интересно выходит - пхписты повылезали, остальные
отмалчиваются.
28.04.2009, в 0:38, Evgeniy Potapov написал(а):
> Ну вот да, то есть суть в том что в
> большинстве крупного вебдева
> произвоительность вычислений
> практически не играет никакой роли (ну
> если среда совсем не скатывается в
> тормоза конечно), просто из-за
> специфики этого самого вебдева.
> Соответственно и бенчи очень такая
> сомительная вещь ;)
>
Maxim Penzin
> исполнения пофигу до той поры, пока всё остальное работает медленно.
> Но тогда почти нет смысла тестировать хэш лукапы и прочее.
Вот это интересный вопрос - что остальное и почему оно работает медленно?
Несколько отвлеченный, но иллюстративный пример:
При помощи обычного java'вского HashMap'а и List'а можно сделать самостоятельно
(1 страница кода) вполне себе управляемый, in process (нет лишних
переключений контекста)
и быстрый многопоточный кэш без сериализации/десериализации и т.п.
Можно прикинуть, сколько юзерских сессий (кил по 10) можно положить в 1Г РАМа,
т.е. во многих случаях это снизит дисковую нагрузку на порядок.
Evgeniy Potapov
работа с данными на стороне хранилища
данных (ну можно было бы сказать
реляционной БД но это, все же, не
единственное что может хранить).
Кэш оно конечно хорошо, но большую
часть User Generated Content в него все же не
положишь.
Как мне кажется (ну я прошу списать все
на то что я скорее быдлокодер и
менеджер чем классный девелопер) -
здесь все уже сделано, реляционной
модели много лет и ничего
принципиально нового именно в этой
сфере сделать нельзя. А соответственно
пока порядки времени выполнения БД-
операций (я имею ввиду не только IO
нагрузку но и RAM и CPU) кардинально
превосходят операции по обработке и
выдаче этих данных в веб-части (назовем
ее так) смысла в выборе языка из-за
производительности мало IMHO. Ну до тех
пор пока у нас специфика проекта не
уходит в какие-нибудь Natural Language Processing,
Data Mining, Collaborative Filtering и прочее.
Evgeniy Potapov
Maxim Penzin
> Ну все остальное - это, прежде всего, -
> работа с данными на стороне хранилища
> данных (ну можно было бы сказать
> реляционной БД но это, все же, не
> единственное что может хранить).
> Кэш оно конечно хорошо, но большую
> часть User Generated Content в него все же не
> положишь.
Вот тут тоже вопросы возникают. А чего же у нас хранилище-то такое медленное?
Сейчас самый затрапезный диск показывает трансфер от 50 МБ/с и выше.
т.е. если даже эту цифру уменьшить в несколько раз, то всё-равно,
например, 100 мбитный эзер один диск наполняет без проблем.
Следовательно вопрос в организации оптимального доступа к данным на диске.
Олег Рощупкин
индексам в лучшем случае, в худшем начинается случайный (как правило)
доступ к диску. И это лишь поверхностная картина происходящего - на
самом деле всё ещё забавней. При всём при этом большинство хранилищ
ужасно закостенели в своём стремлении к обратной совместимости, а
новых почти и нет.
Та же mysql может съесть мозг своими особенностями. "Не более A баз на
сервере, не более B таблиц в базе, не более C записей на таблицу".
Есть у нас, конечно, key=>value, давно поднимавшиеся, и сейчас активно
выползающие из тени в связи с временным (вечным?) наступлением
параллелизма (да и то, что они масштабируются, как правило, проще -
тоже играет роль). Есть CouchDB, подходящая по-своему, забавно.
А вот оптимального доступа к данным на диске - как-то не видно.
Кстати, Женя может рассказать, как весело бывает жить с большим
количеством файлов в одной директории. Уж не знаю, относится это к
доступу к данным - лень лезть и разбираться в реализации.
28.04.2009, в 14:07, Maxim Penzin написал(а):
> Вот тут тоже вопросы возникают. А чего же у нас хранилище-то такое
> медленное?
> Сейчас самый затрапезный диск показывает трансфер от 50 МБ/с и выше.
>
> т.е. если даже эту цифру уменьшить в несколько раз, то всё-равно,
> например, 100 мбитный эзер один диск наполняет без проблем.
>
> Следовательно вопрос в организации оптимального доступа к данным на
> диске.
Maxim Penzin
> Медленное-то оно известно чего - подготавливает запрос, ищет по
> индексам в лучшем случае, в худшем начинается случайный (как правило)
> доступ к диску. И это лишь поверхностная картина происходящего - на
> самом деле всё ещё забавней. При всём при этом большинство хранилищ
> ужасно закостенели в своём стремлении к обратной совместимости, а
> новых почти и нет.
Понятие "закостенели" мне не очень понятно :)
> Та же mysql может съесть мозг своими особенностями. "Не более A баз на
> сервере, не более B таблиц в базе, не более C записей на таблицу".
Как я понимаю, сами по себе "N баз и M таблиц" уже достаточно велики,
на мой взгляд, если речь идёт о производительности, то N == 1, а M в
пределах сотни-двух,
что само по себе уже очень дофига.
> Есть у нас, конечно, key=>value, давно поднимавшиеся, и сейчас активно
> выползающие из тени в связи с временным (вечным?) наступлением
> параллелизма (да и то, что они масштабируются, как правило, проще -
> тоже играет роль). Есть CouchDB, подходящая по-своему, забавно.
> А вот оптимального доступа к данным на диске - как-то не видно.
Что есть оптимальный доступ?
> Кстати, Женя может рассказать, как весело бывает жить с большим
> количеством файлов в одной директории. Уж не знаю, относится это к
> доступу к данным - лень лезть и разбираться в реализации.
Тут не надо никуда лезть - это можно сказать азбука.
Директорий это тоже файл, у него тоже есть размер и время на его чтение.
Ко всему прочему во многих файловых системах файл в директории ищется
тривиальным последовательным поиском (на это есть немало причин), то
веселье тут очевидно.
Так вот, насчет доступа к дисковым данным.
Теория на самом деле очень давняя и давно проработанная.
Обычные индексы строятся на сильноветвящихся деревьях, с не полностью
заполненными
страницами индекса.
Если положить размер элемента индекса 10 байт, среднее кол-во
элементов в узле дерева
1000, то до миллиарда элементов можно доступаться за 3 чтения без всяких кэшей.
Или за 2 чтения при условии кэширования первого уровня индекса (10Мб),
т.е. порядка 20-ти мс
или 50 чтений в секунду.
К тому же, если учесть, что с диска имеет смысл читать сразу пол цилиндра
или размер его встроенного кэша, то на самом деле программеру предоставляются
очень немаленькие возможности по оптимизации всего этого хозяйства.
Pavel Pacific
Если положить размер элемента индекса 10 байт, среднее кол-во
элементов в узле дерева
1000, то до миллиарда элементов можно доступаться за 3 чтения без всяких кэшей.
Или за 2 чтения при условии кэширования первого уровня индекса (10Мб),
т.е. порядка 20-ти мс
или 50 чтений в секунду.
К тому же, если учесть, что с диска имеет смысл читать сразу пол цилиндра
или размер его встроенного кэша, то на самом деле программеру предоставляются
очень немаленькие возможности по оптимизации всего этого хозяйства.
Рыл различную информацию на тему оптимизации работы, хорошая статья на тему, может кому-нибудь пригодится.
Почему нельзя использовать RAID 5 для сервера базы данных
http://gsbelarus.com/gs/wiki/index.php/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83_%D0%BD%D0%B5%D0%BB%D1%8C%D0%B7%D1%8F_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D1%8C_RAID_5_%D0%B4%D0%BB%D1%8F_%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0_%D0%B1%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
Maxim Penzin
> Рыл различную информацию на тему оптимизации работы, хорошая статья на тему,
> может кому-нибудь пригодится.
>
> Почему нельзя использовать RAID 5 для сервера базы данных
>
> http://gsbelarus.com/gs/wiki/index.php/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83_%D0%BD%D0%B5%D0%BB%D1%8C%D0%B7%D1%8F_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D1%8C_RAID_5_%D0%B4%D0%BB%D1%8F_%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0_%D0%B1%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
Странно, что товарищ, говоря о RAID5, приводит картинку от RAID4.
Pavel Pacific
Странно, что товарищ, говоря о RAID5, приводит картинку от RAID4.
Alexander
---------------
Hello Pavel!
PP> Почему нельзя использовать RAID 5 для сервера базы данных
PP> http://gsbelarus.com/gs/wiki/index.php/%D0%9F%D0%BE%D1%87%D0%B5%D0%BC%D1%83_%D0%BD%D0%B5%D0%BB%D1%8C%D0%B7%D1%8F_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D1%8C_RAID_5_%D0%B4%D0%BB%D1%8F_%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0_%D0%B1%D0%B0%D0%B7%D1%8B_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
что-то сколько мы райд не пытались использовать (в разных вариантах) - получалось как в анекдоте "один потерял, а один - сломал"... то оба зеркала навернутся, то один из зеркала навернется, а после вставки отрепайрит чистый винт на винт с данными, то из райда-5 что-то так навернется, что проще убиться, а не искать такие старые винты...
в общем,самое надежное - умный бэкап. Завязал я с райдами, спокойнее теперь живется. Видимо, с ними надо очень тесно жить, их любить и только ими заниматься, чтобы помнить, что надо делать в определенном случае и вообще их лелеять. :)
Счастливо!
Take Care!
--
Александр Чижов (Alexander Chizhov)
mailto:ch...@irk.ru
http://cooler-online.com
БАБР.RU-Сибирь
> Кстати, Женя может рассказать, как весело бывает жить с большим
> количеством файлов в одной директории.
А большое - это сколько?
(в загашнике вопрос про тип файловой системы).
--
ДТ
(395-2) 51-22-08
Evgeniy Potapov
фотографий в одну и ту же папку, в которой и кропилось при этом.
На ext3 (ну собственно клиенты заказывали дефольтную конфигурацию
когда им индусы делали) апогей был достигнут где-то на 2-3 миллионах
файлов.
Вообще по сути там надо раскидывать по папкам все, лучше всего через
webdav вообще чтобы учесть то что серверов может быть много.
Проще и удобнее чем распредленная фс.
В итоге имеем урлы типа site.com/cdn/1/images/100/dfs13123sdfsdf.jpg
где 1 - айди сервера на котором лежит файл (запрос отдается через
proxy_pass)
и файл берется с cdn1.site.com/images/100/dfs13123sdfsdf.jpg
cdn1.site.com это как раз то что принимает webdav запросы
Evgeniy Potapov
БАБР.RU-Сибирь
> Вообще по сути там надо раскидывать по папкам все, лучше всего через
> webdav вообще чтобы учесть то что серверов может быть много.
> Проще и удобнее чем распредленная фс.
> В итоге имеем урлы типа site.com/cdn/1/images/100/dfs13123sdfsdf.jpg
> где 1 - айди сервера на котором лежит файл (запрос отдается через
> proxy_pass)
И что?
Кстати, какая разница, как выглядит url?
--
ДТ
(395-2) 51-22-08
Evgeniy Potapov
Никитина Юлия
русских:)) каким должен быть лучший сайт
http://www.bowencraggs.com:80/ftindex/indices
у японцев, вообще, своя картина мира http://www.toyota.co.jp/
http://www.mufg.jp/
С уважением,
Никитина Юлия
Pavel Pacific
Мега-супер проверил его с отключенными J-скриптами, а он как был
сайтом - так и остался.
Вывод - фармацевты не жалеют денег для людей (испытуемых) ;)
Глубже не копал. Просто хотел сказать - thx, за ссылку.
Pavel Pacific
<script type="text/javascript" src="jquery-1.2.3.pack.js"></script>
<script type="text/javascript" src="jquery.dimensions.js"></script>
<script type="text/javascript" src="jquery.tooltip.js"></script>
<script type="text/javascript" src="jquery.mousewheel.js"></script>
<script type="text/javascript" src="ui.mouse.js"></script>
<script type="text/javascript" src="ui.slider.js"></script>
<script type="text/javascript" src="ui.accordion.js"></script>
<script type="text/javascript" src="jquery.tablesorter.js"></script>
<script type="text/javascript" src="core.js"></script>
<script type="text/javascript" src="en.js"></script>
<script type="text/javascript" src="script.js"></script>
<script type="text/javascript" src="custom.js"></script>
<script type="text/javascript" src="default.js"></script>
<script type="text/javascript" src="thickbox.js"></script>
<script type="text/javascript" src="swfaddress_2_2_ext.js"></script>
<script type="text/javascript" src="productfinder.js"></script>
Pavel Pacific
Есть одна фишка которую roche.com не решили и ее без скриптов или
предварительных запросов ее не решить - Выпадающий список с
последующим переходом по ссылке. Тут без JS и кнопки не нарисовать и
плюс многие разработчики брезгуют почему кнопочку по дефолту воткнуть,
к списку, типа [>]. И вроде места не занимает. Буквально сегодня на
http://www.d-link.ru/ наткнулся из-за глiюка оперы, которая почему-то
JS отключила. Но на COM источнике кнопулька есть.
О чем это говорит - о деньгах или о качестве. Лада КолЪинна или БУ
Японка ????....
Pavel Pacific
С масквой сегодня ругались.
Отправили ссылку на почту, они скачали - файл оказался левым.
А ларчик просто открывался, чуть не "обслогал" оппонентов.
Делая пересылку письма, в веб-интерфейск гугламыла переправил ссылку,
тип письма HTML, но эта падла видимую часть заменила а внутри оставила
старую (<а href="бла-бла1">бла-бла2</a>). Люди тыкаю и грузят файл
совершенно другой. Отправлял через Firexox, не знаю глюк браузера или
системы.
БАБР.RU-Сибирь
15.05.09, 13:24, "Evgeniy Potapov" <eapo...@gmail.com>:
--
ДТ
(395-2) 51-22-08