Для начала, спасибо всем, кто отвечал на мои вопросы по данной теме. Без вас этот язык... был бы написан, но его писать было бы намного более уныло.
Для тех кто не в курсе, кратко напомню: Beep (Бип, звук, которым забивают непечатные ругательства в эфире, так как именно их я произнес, когда понял, что мне придется написать этот язык) — это питоно-луа образный язык со статической типизацией и выводом типов, компилируемый в байткод и предназначенный, по замыслу, для скриптования на микроконтроллерах (таких, куда не впихнешь Java и Lua). Является заменой форту. Сейчас он работает на MSP TI430, размер памяти именно на язык определяется размером выделенного хипа и стеков. Сейчас это контроллер с 5K RAM на борту, но будет работать и на 2K — младшие процессоры в линейке.
Сейчас, после переписывания компилятора в человеческий вид и добавления ряда полезных фич, решил, для смеха, сравнить производительность на похожем скрипте с питоном (скрипты в конце поста). Запускалось на PC, естественно, результаты оказались слегка удивительными:
Beep с компиляцией
dmz@x200:~/prj/raccoon/beepvm$ time (./beepc nmea.beep >/dev/null 2>1 && ./beepvm ./nmea.bin >/dev/null)
real 0m1.500s
user 0m1.480s
sys 0m0.004s
Beep, заранее скомпилировано
dmz@x200:~/prj/raccoon/beepvm$ time (./beepvm ./nmea.bin >/dev/null)
real 0m1.386s
user 0m1.352s
sys 0m0.000s
Python
dmz@x200:~/prj/raccoon/beepvm$ time python ./nmea.py >/dev/null
real 0m3.251s
user 0m3.228s
sys 0m0.004s
Начальные условия: питону доступна вся память, сколько раз запускался сборщик мусора (какой бы он у него ни был) — неизвестно.
Бипу доступно 1024 байта хипа и 256 байт (128 16-битных слов) стека. Сборщик мусора запускался 10924 раза.
Если из скрипта на Бипе убрать strdup(...) — которая каждый раз копирует строку в динамическую память, то количество сборок мусора уменьшается до 5568, результат по времени практически такой-же, и я кажется, знаю почему: сборщих халтурит, освобождая за O(текущая глубина стека), а вот что бы его заставить работать по-честному, надо адресами загадить весь стек, пока не знаю как.
Структуры и строки пока иммутабельны, то есть каждое операция со строкой или создание структуры — приводят к честному копированию.
Никаких оптимизаций чего-либо, кроме скорости компиляции, не проводилось; это практически первые реальные запуски (Да, на микроконтроллере оно тоже работает). Конечно не с такими результатами, чуть позже запущу тот же скрипт.
Кому интересно, исходные коды скриптов (да, я знаю что на питоне так не пишут)
Бип:
type nmea_gga { time_utc: string,
lat: string,
lat_semi: string,
lon: string,
lon_semi: string,
fix: string,
sat: string
}
def nmea_parse_gga(s)
{
local c, i = 0, j = 0, comma = 0;
local len = strlen(s);
local utc, lat, lat_s, lon, lon_s, fix, sat;
while i < len {
c = strnth(s, i);
if c == ',' || c == '*' then
{
comma = comma + 1;
if comma == 2 then utc = strsub(s, j, 6);
elif comma == 3 then lat = strsub(s, j, i-j);
elif comma == 4 then lat_s = strsub(s, j, i-j);
elif comma == 5 then lon = strsub(s, j, i-j);
elif comma == 6 then lon_s = strsub(s, j, i-j);
elif comma == 7 then fix = strsub(s, j, i-j);
elif comma == 8 then sat = strsub(s, j, i-j);
j = i+1;
}
i = i + 1;
if i == len || c == '*' then break;
}
ret { time_utc=utc, lat=lat, lat_semi=lat_s,
lon=lon, lon_semi=lon_s,
fix=fix, sat=sat
of nmea_gga
};
}
def main()
{
local s = "$GPGGA,121505,4807.038,N,01131.324,E,1,08,0,9133.4,M,46.9,M,,*42";
local i = 0;
while i < 0xFFFF {
local gga = nmea_parse_gga(s);
putsn(gga.time_utc);
putsn(gga.sat);
putsn(gga.fix);
putsn(gga.lat);
putsn(gga.lat_semi);
putsn(gga.lon);
putsn(gga.lon_semi);
i = i + 1;
}
}
Питон:
class nmea_gga:
def __init__(self, time_utc, lat, lat_semi, lon, lon_semi, fix, sat):
self.time_utc = time_utc
self.lat = lat
self.lat_semi = lat_semi
self.lon = lon
self.lon_semi = lon_semi
self.fix = fix
self.sat = sat
def nmea_parse_gga(s):
(c, i, j, comma) = ('',0,0,0)
ln = len(s)
(utc, lat, lat_s, lon, lon_s, fix, sat) = ('','','','','','','')
while i < ln:
c = s[i]
if c == ','or c == '*':
comma = comma + 1
if comma == 2: utc = s[j:j+6]
elif comma == 3: lat = s[j:i]
elif comma == 4: lat_s = s[j:i]
elif comma == 5: lon = s[j:i]
elif comma == 6: lon_s = s[j:i]
elif comma == 7: fix = s[j:i]
elif comma == 8: sat = s[j:i]
j = i + 1
i = i + 1
if i == ln or c == '*':
break
return nmea_gga(time_utc=utc, lat=lat, lat_semi=lat_s, lon=lon, lon_semi=lon_s, fix=fix, sat=sat)
if __name__ == "__main__":
s = "$GPGGA,121505,4807.038,N,01131.324,E,1,08,0,9133.4,M,46.9,M,,*42";
i = 0
while i < 0xFFFF:
gga = nmea_parse_gga(s)
print gga.time_utc
print gga.sat
print gga.fix
print gga.lat
print gga.lat_semi
print gga.lon
print gga.lon_semi
i = i + 1
dmz>Для начала, спасибо всем, кто отвечал на мои вопросы по данной теме. Без вас этот язык... был бы написан, но его писать было бы намного более уныло. dmz>Для тех кто не в курсе, кратко напомню: Beep (Бип, звук, которым забивают непечатные ругательства в эфире, так как именно их я произнес, когда понял, что мне придется написать этот язык) — это питоно-луа образный язык со статической типизацией и выводом типов, компилируемый в байткод и предназначенный, по замыслу, для скриптования на микроконтроллерах (таких, куда не впихнешь Java и Lua). Является заменой форту. Сейчас он работает на MSP TI430, размер памяти именно на язык определяется размером выделенного хипа и стеков. Сейчас это контроллер с 5K RAM на борту, но будет работать и на 2K — младшие процессоры в линейке.
Достаточно интересные результаты, однако.
Справедливости ради надо добавить, что сходство с Питоном по всей видимости
ограничивается одним лишь слово 'def'
dmz>Сейчас, после переписывания компилятора в человеческий вид и добавления ряда полезных фич, решил, для смеха, сравнить производительность на похожем скрипте с питоном (скрипты в конце поста). Запускалось на PC, естественно, результаты оказались слегка удивительными:
Результаты не столь удивительны, сколько не понятно, что же, собственно измерялось?
dmz>Сейчас, после переписывания компилятора в человеческий вид и добавления ряда полезных фич, решил, для смеха, сравнить производительность на похожем скрипте с питоном (скрипты в конце поста). Запускалось на PC, естественно, результаты оказались слегка удивительными:
dmz>Beep с компиляцией
Сильно.
beepc на чём?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, dmz, Вы писали:
dmz>Сейчас, после переписывания компилятора в человеческий вид и добавления ряда полезных фич, решил, для смеха, сравнить производительность на похожем скрипте с питоном (скрипты в конце поста). Запускалось на PC, естественно, результаты оказались слегка удивительными:
А что именно вызвало удивление?
Статически типизированный язык против насквозь динамического, должно было исполняться раз в надцать быстрее.
С учётом интерпретации байткода и неоптимизированности интерпретатора — разница в 2-3 раза по скорости смотрится вполне естественно.
M>Справедливости ради надо добавить, что сходство с Питоном по всей видимости M>ограничивается одним лишь слово 'def'
Не, ну еще не надо указывать типы переменных (хотя можно). Еще у меня есть кортежи и списки, if/elif/else и while — точно как в питонове.
dmz>>Сейчас, после переписывания компилятора в человеческий вид и добавления ряда полезных фич, решил, для смеха, сравнить производительность на похожем скрипте с питоном (скрипты в конце поста). Запускалось на PC, естественно, результаты оказались слегка удивительными:
M>Результаты не столь удивительны, сколько не понятно, что же, собственно измерялось?
Ну говорю же, ради смеха. Ну или сравнение производительности на определенного вида задачах, типа Language shoutout.
Честно говоря я затрудняюсь интрепретировать эти цифры.
Дело в том что код который ты тестировал уж сильно разный.
В Python нет структур в твоем понимании.
Есть объекты, да. Но это что-то типа hash-map.
Т.е. в Python доступ по ключу, а у тебя (я надеюсь) доступ по индексу/смещению от
начала структуры.
Кстати что-то мне говорит что если переписать тест с Python на Lua то цифры там
будут сопоставимы с твоими т.е. очень близкими. У Lua цена вызова процедуры
меньше в разы.
dmz>>>Beep с компиляцией T>>Сильно. T>>beepc на чём? dmz>На ocaml. Хаскелл когда начинал не осилил (точнее, не понял как на нем надо писать), но зато в процессе dmz>написания понял, что хаскелл крутой.
Интересно.
Расскажешь?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, dmz, Вы писали:
dmz>Сейчас, после переписывания компилятора в человеческий вид и добавления ряда полезных фич, решил, для смеха, сравнить производительность на похожем скрипте с питоном (скрипты в конце поста). Запускалось на PC, естественно, результаты оказались слегка удивительными:
Мне кажется эти тесты меряют в основном скорость вывода в консоль — по крайней мере для луа 'print' занимает 3/4 времени. С закомментированной печатью работает примерно в 2 раза быстрее питона (питон тоже без печати.)
--// Lua 5.1.x
local COMMA, STAR = (","):byte(), ("*"):byte()
local function nmea_parse_gga(s)
local result, j, comma = {}, 1, 0
for i=1,#s do
local c = s:byte(i)
if c == COMMA then
comma = comma + 1
if comma == 2 then result.time_utc = s:sub(j,i-1)
elseif comma == 3 then result.lat = s:sub(j,i-1)
elseif comma == 4 then result.lat_semi = s:sub(j,i-1)
elseif comma == 5 then result.lon = s:sub(j,i-1)
elseif comma == 6 then result.lon_semi = s:sub(j,i-1)
elseif comma == 7 then result.fix = s:sub(j,i-1)
elseif comma == 8 then result.sat = s:sub(j,i-1)
end
j = i+1
elseif c == STAR then
break
end
end
return result
end
--// TEST:
local s = "$GPGGA,121505,4807.038,N,01131.324,E,1,08,0,9133.4,M,46.9,M,,*42"for i=1,0xFFFF do
local gga = nmea_parse_gga(s)
assert( gga.time_utc == "121505"
and gga.sat == "08"
and gga.fix == "1"
and gga.lat == "4807.038"
and gga.lat_semi == "N"
and gga.lon == "01131.324"
and gga.lon_semi == "E")
--// print(gga.time_utc)
--// print(gga.sat)
--// print(gga.fix)
--// print(gga.lat)
--// print(gga.lat_semi)
--// print(gga.lon)
--// print(gga.lon_semi)
end
CS>Честно говоря я затрудняюсь интрепретировать эти цифры.
Да не надо к этим цифрам относиться слишком серьезно. Просто написав некий язык/vm, трудно
удержаться от того, что бы с чем-то его сравнить. Это именно время, которое занимает выполнение
определеной задачи, реализованной похожим образом, на языке A и на языке B. Как на Language Shoutout.
Более ничего.
CS>Дело в том что код который ты тестировал уж сильно разный. CS>В Python нет структур в твоем понимании.
CS>Есть объекты, да. Но это что-то типа hash-map. CS>Т.е. в Python доступ по ключу, а у тебя (я надеюсь) доступ по индексу/смещению от CS>начала структуры.
По уму, доступ по ключу к хэшу занимает O(1), и для константных строк хэш должен быть вычислен заранее,
или кешироваться — т.е. в отсутствии коллизий
CS>Кстати что-то мне говорит что если переписать тест с Python на Lua то цифры там CS>будут сопоставимы с твоими т.е. очень близкими. У Lua цена вызова процедуры CS>меньше в разы.
Ну, думаю, что Lua достаточно быстрый, что бы накладные расходы динамического языка компенсировать скоростью исполнения.
Мерять не буду, все равно на целевой платформе нет ни питона, не Lua, да и Lua я толком не знаю и его у меня нет.
К тому-же, у Бипа впереди еще оптимизация байткода и оптимизация VM. Еще, в глубине души я уверен, что VM для статического
языка обязана работать быстрее, чем для динамического в любом случае.
Z>Мне кажется эти тесты меряют в основном скорость вывода в консоль — по крайней мере для луа 'print' занимает 3/4 времени. С закомментированной
печатью работает примерно в 2 раза быстрее питона (питон тоже без печати.)
В PC-шной сборке бипа, функция putsn реализована достаточно неэффективно:
Замена в питоне функции print на sys.out.write — только увеличивает время выполнения. Если у питона и луа эти функции еще менее эффективные, то я не виноват. Ладно, убедили — более близкая версия на питон — убираем ввод-вывод и вместо объекта возвращаем кортеж:
def nmea_parse_gga(s):
(c, i, j, comma) = ('',0,0,0)
ln = len(s)
(utc, lat, lat_s, lon, lon_s, fix, sat) = ('','','','','','','')
while i < ln:
c = s[i]
if c == ','or c == '*':
comma = comma + 1
if comma == 2: utc = s[j:j+6]
elif comma == 3: lat = s[j:i]
elif comma == 4: lat_s = s[j:i]
elif comma == 5: lon = s[j:i]
elif comma == 6: lon_s = s[j:i]
elif comma == 7: fix = s[j:i]
elif comma == 8: sat = s[j:i]
j = i + 1
i = i + 1
if i == ln or c == '*':
break
return (utc, lat, lat_s, lon, lon_s, fix, sat)
if __name__ == "__main__":
s = "$GPGGA,121505,4807.038,N,01131.324,E,1,08,0,9133.4,M,46.9,M,,*42";
i = 0
while i < 0xFFFF:
gga = nmea_parse_gga(s)
i = i + 1
результаты:
dmz@x200:~/prj/raccoon/beepvm$ time python ./nmea.py
real 0m2.574s
user 0m2.568s
sys 0m0.000s
CS>Честно говоря я затрудняюсь интрепретировать эти цифры.
Интерпретировать их надо так: если бы получилось так, что скорость бипа, была бы, скажем, в три раза медленнее питона, это бы значило,
что я где-то просчитался, например, каждый вызов GC стоит недопустимо дорого. Напомню — что у бипа он вызывался более 10000 раз на 0xFFFF
итераций. Причем, GC консервативный и очень дорогой, так как он обходит дерево объектов за константную (и очень маленькую) память. Даже без реверсирования указателей, так как реверсированные указатели тоже негде хранить.
А у питона его вообще толком нет, да и запускаться, я думаю, он бы не стал.
Основной мой пойнт, все-же, в том, что 1) статические языки работают быстрее 2) по удобству использования они могут не уступать динамическим.
CS>Дело в том что код который ты тестировал уж сильно разный. CS>В Python нет структур в твоем понимании.
Ну вон, привел в треде пример с кортежами и без консольного ввода-вывода, питон стал на 0.5 секунды быстрее.
Z>Мне кажется эти тесты меряют в основном скорость вывода в консоль — по крайней мере для луа 'print' занимает 3/4 времени. С закомментированной печатью работает примерно в 2 раза быстрее питона (питон тоже без печати.)
А можно тест для Lua 5.0 ? 5.1 в репозитории нет, а этот скрипт под 5.0 не работает. С питоном сравнивать неспортивно, надо попробовать сравнить с грамотно реализованным языком, к которым я Lua отношу (пока не доказано обратное).
Исходников они не дают. Кажется, он интерпретируемый. В примерах, собраных для Intel лежат какие-то бинарники с именем
Hume и весом 3 мегабайта, что наводит на мысли.
VM Бипа, собранная для Intel — 23 килобайта, если собрать без отладочной информации.
Если бы я мог взять что-то готовое, я бы взял Lua. Но оно не влезет.
А еще, у меня есть специфическое требование к стабильности байткодов, так как после устаканивания, байткоды меняться вообще не будут. А так же явное специфицирование этих байткодов. Все это наводит на мысли, что даже если бы я что-то взял, то это что-то пришлось бы форкать и поддерживать самостоятельно.
PS. А если собрать BeepVM с оптимизацией -O2, то скрипт nmea.beep волшебным образом начинает работать 0.7 секунд
вместо 1.3
Ну а что тут рассказывать? Более приятный и современный синтаксис. Более обширная и продуманная стандартная
библиотека, которая не менее важна, чем язык. Даже несмотря на то, что для OCaml есть ExtLib, без которой
вообще невозможно работать, все равно приходится все дописывать. Хаскелл — более консистентный.
Когда бы мне понадобилось взять от строки подстроку длиной N, или все что есть, если строка короче N — то я не
задумываясь написал бы (не заглядывая в документацию) take 5 s — и в хаскелле это отлично работает.
А в окамле 1) вообще нет take 2) когда он найдется в ExtLib, он не будет работать со строками 3) Всякие функции String.sub
работают не так (надо вычислять смещение) 4) Еще они падают с исключением, которое нафиг тут не нужно.
И так везде. В итоге, что бы сделать такую простую вещь, в окамле надо 1) перерыть доки 2)убедиться, что все равно как надо
не работает 3) написать свою обертку
Библиотека окамла неинтуитивна, потери на чтение документации велики. Но хуже то, что когда мне в следующий раз через полгода понадобиться
потранкейтить строку, я опять напишу take 5 s, обломаюсь, пойду искать свою реализацию, не найду, пойду читать документацию и писать свою обертку.
Язык все же неплохой, обертка пишется быстро — но если мощи встроенной, поставляемой с языком библиотеки не хватает, это автоматически
означает, что язык не подходит на роль Swiss Army Knife, то есть для автоматизации повседневных задач. А для меня это важно, так как есть
привычка скриптовать все на том языке, который я пытаюсь изучить, что бы научиться и не забывать.
Особенно я обламываюсь сейчас из-за того, что забыл перл, а питон и окамл категорически не годятся для написания однострочников, которыми я регулярно пользуюсь. Надо бы хаскелл покурить на этот предмет, что то мне подсказывает, что он подойдет для однострочников.
Но с другой стороны — я уже напоролся на проблемы производительности и пришлось существенно напрячься, что бы ускорить компиляцию, и не допускать что бы она была не более одной секунды на скрипт, который в состоянии написать человек. И вот как бы тут повел себя хаскелл — я не знаю.
Здравствуйте, dmz, Вы писали:
dmz>Особенно я обламываюсь сейчас из-за того, что забыл перл
Расскажи как тебе это удалось!!
dmz>а питон и окамл категорически не годятся для написания однострочников
Хмм... Я как раз Питоном для однострочников пользуюсь...
dmz>>Особенно я обламываюсь сейчас из-за того, что забыл перл C>Расскажи как тебе это удалось!!
Это элементарно. Даже когда я на нем активно программил (включая perlguts-xs, ЕВПОЧЯ), году так в 2002ом,
то и то не мог в каждый момент уверенно сказать какую кракозябру когда применить, а так же, когда имею дело со ссылкой,
а когда со значением. Все вот эти $@# и скалярно-векторные контексты крайне задалбывали. Особенно запомнился момент, когда я после нескольких часов бодания просто тупо один в один переписал работу с какой-то сложной вложенной структурой данных на питоне, и оно сразу заработало правильно, просто в силу того, что там негде было накосячить с пресловутыми контекстами.
dmz>>а питон и окамл категорически не годятся для написания однострочников C>Хмм... Я как раз Питоном для однострочников пользуюсь...
Ну вот у меня есть много-много-экранный вывод лога компилятора с таймстемпами вида
СТРОКА ВСЯКИЙ БРЕД 0.XXXXX
....
Мне надо написать фильтр для шелла, который отфильтрует по строке, отцепит крайние значение (таймстемп), и
результаты просуммирует. Можно это сделать коротким однострочником на питоне? Который набрать быстрее, чем
запустить электронную таблицу (как это сделал бы обычный пользователь). Питон многословен, и потребует импорты.
А так-же, если что-то не влезет в лямбду, то потребуются отступы — и все, однострочник не получился.
На перле это сделать точно можно, только я забыл какой кракозяброй получить последний элемент массива, который выдает
split. Читать документацию принципиально не буду, так как это будет инвестиция в мертвый (для меня) язык.
CS>>Честно говоря я затрудняюсь интрепретировать эти цифры.
dmz>Да не надо к этим цифрам относиться слишком серьезно. Просто написав некий язык/vm, трудно dmz>удержаться от того, что бы с чем-то его сравнить. Это именно время, которое занимает выполнение dmz>определеной задачи, реализованной похожим образом, на языке A и на языке B. Как на Language Shoutout.
Собственно цифры важны за для понять стоит ли овчина выделки.
Я имею ввиду компиляцию с оптимизацией по типам.
CS>>Дело в том что код который ты тестировал уж сильно разный. CS>>В Python нет структур в твоем понимании.
CS>>Есть объекты, да. Но это что-то типа hash-map. CS>>Т.е. в Python доступ по ключу, а у тебя (я надеюсь) доступ по индексу/смещению от CS>>начала структуры.
dmz>По уму, доступ по ключу к хэшу занимает O(1), и для константных строк хэш должен быть вычислен заранее, dmz>или кешироваться — т.е. в отсутствии коллизий
O(1) она тем не менее разная бывает.
У Python есть вычисляемые properties. В случае
obj.foo = bar;
runtime обязан сначала просканировать класс, а потом сам объект.
Т.е. имеем как минимум 2*O(1).
CS>>Кстати что-то мне говорит что если переписать тест с Python на Lua то цифры там CS>>будут сопоставимы с твоими т.е. очень близкими. У Lua цена вызова процедуры CS>>меньше в разы.
dmz>Ну, думаю, что Lua достаточно быстрый, что бы накладные расходы динамического языка компенсировать скоростью исполнения. dmz>Мерять не буду, все равно на целевой платформе нет ни питона, не Lua, да и Lua я толком не знаю и его у меня нет.
Вот статья с DDJ Embedded про язык BOB http://www.ddj.com/184409401 (старая статья, была еще одна позже)
Я знаю что Давид его делал для какого-то встравиваемого процессора.
Там есть есть режим сборки голой VM — без компайлера и всего остального.
Исходники у него на сайте http://www.mv.com/ipusers/xlisper/
dmz>К тому-же, у Бипа впереди еще оптимизация байткода и оптимизация VM. Еще, в глубине души я уверен, что VM для статического dmz>языка обязана работать быстрее, чем для динамического в любом случае.
А чего бы не взять скажем TinyVM (писана для Lego Mindstorms) http://tinyvm.sourceforge.net/
Это JavaVM т.е. можно использовать Java compilers прооптимизированные по самое нихочу.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, dmz, Вы писали:
dmz>>Особенно я обламываюсь сейчас из-за того, что забыл перл C>Расскажи как тебе это удалось!!
