Beep: первые результаты
От: dmz Россия  
Дата: 28.02.09 06:51
Оценка: 195 (10) :)
Для начала, спасибо всем, кто отвечал на мои вопросы по данной теме. Без вас этот язык... был бы написан, но его писать было бы намного более уныло.
Для тех кто не в курсе, кратко напомню: 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
beep
Re: Beep: первые результаты
От: maxp Россия http://penzin.ru/
Дата: 28.02.09 11:05
Оценка:
dmz>Для начала, спасибо всем, кто отвечал на мои вопросы по данной теме. Без вас этот язык... был бы написан, но его писать было бы намного более уныло.
dmz>Для тех кто не в курсе, кратко напомню: Beep (Бип, звук, которым забивают непечатные ругательства в эфире, так как именно их я произнес, когда понял, что мне придется написать этот язык) — это питоно-луа образный язык со статической типизацией и выводом типов, компилируемый в байткод и предназначенный, по замыслу, для скриптования на микроконтроллерах (таких, куда не впихнешь Java и Lua). Является заменой форту. Сейчас он работает на MSP TI430, размер памяти именно на язык определяется размером выделенного хипа и стеков. Сейчас это контроллер с 5K RAM на борту, но будет работать и на 2K — младшие процессоры в линейке.

Достаточно интересные результаты, однако.
Справедливости ради надо добавить, что сходство с Питоном по всей видимости
ограничивается одним лишь слово 'def'

dmz>Сейчас, после переписывания компилятора в человеческий вид и добавления ряда полезных фич, решил, для смеха, сравнить производительность на похожем скрипте с питоном (скрипты в конце поста). Запускалось на PC, естественно, результаты оказались слегка удивительными:


Результаты не столь удивительны, сколько не понятно, что же, собственно измерялось?
Re: Beep: первые результаты
От: thesz Россия http://thesz.livejournal.com
Дата: 28.02.09 11:06
Оценка:
dmz>Сейчас, после переписывания компилятора в человеческий вид и добавления ряда полезных фич, решил, для смеха, сравнить производительность на похожем скрипте с питоном (скрипты в конце поста). Запускалось на PC, естественно, результаты оказались слегка удивительными:

dmz>Beep с компиляцией


Сильно.

beepc на чём?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: Beep: первые результаты
От: mkizub Литва http://symade.tigris.org
Дата: 28.02.09 11:50
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>Сейчас, после переписывания компилятора в человеческий вид и добавления ряда полезных фич, решил, для смеха, сравнить производительность на похожем скрипте с питоном (скрипты в конце поста). Запускалось на PC, естественно, результаты оказались слегка удивительными:


А что именно вызвало удивление?
Статически типизированный язык против насквозь динамического, должно было исполняться раз в надцать быстрее.
С учётом интерпретации байткода и неоптимизированности интерпретатора — разница в 2-3 раза по скорости смотрится вполне естественно.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[2]: Beep: первые результаты
От: dmz Россия  
Дата: 28.02.09 12:13
Оценка:
dmz>>Beep с компиляцией

T>Сильно.


T>beepc на чём?


На ocaml. Хаскелл когда начинал не осилил (точнее, не понял как на нем надо писать), но зато в процессе
написания понял, что хаскелл крутой.
Re[2]: Beep: первые результаты
От: dmz Россия  
Дата: 28.02.09 12:17
Оценка:
M>Справедливости ради надо добавить, что сходство с Питоном по всей видимости
M>ограничивается одним лишь слово 'def'

Не, ну еще не надо указывать типы переменных (хотя можно). Еще у меня есть кортежи и списки, if/elif/else и while — точно как в питонове.

dmz>>Сейчас, после переписывания компилятора в человеческий вид и добавления ряда полезных фич, решил, для смеха, сравнить производительность на похожем скрипте с питоном (скрипты в конце поста). Запускалось на PC, естественно, результаты оказались слегка удивительными:


M>Результаты не столь удивительны, сколько не понятно, что же, собственно измерялось?


Ну говорю же, ради смеха. Ну или сравнение производительности на определенного вида задачах, типа Language shoutout.
Re: Beep: первые результаты
От: c-smile Канада http://terrainformatica.com
Дата: 28.02.09 19:05
Оценка: +1
Здравствуйте, dmz, Вы писали:

dmz>Beep с компиляцией


dmz>
dmz>dmz@x200:~/prj/raccoon/beepvm$ time (./beepc nmea.beep >/dev/null 2>1 && ./beepvm ./nmea.bin >/dev/null)

dmz>real    0m1.500s
dmz>user    0m1.480s
dmz>sys    0m0.004s
dmz>


dmz>Python


dmz>
dmz>dmz@x200:~/prj/raccoon/beepvm$ time python ./nmea.py >/dev/null

dmz>real    0m3.251s
dmz>user    0m3.228s
dmz>sys    0m0.004s
dmz>


Честно говоря я затрудняюсь интрепретировать эти цифры.

Дело в том что код который ты тестировал уж сильно разный.
В Python нет структур в твоем понимании.
Есть объекты, да. Но это что-то типа hash-map.
Т.е. в Python доступ по ключу, а у тебя (я надеюсь) доступ по индексу/смещению от
начала структуры.

Кстати что-то мне говорит что если переписать тест с Python на Lua то цифры там
будут сопоставимы с твоими т.е. очень близкими. У Lua цена вызова процедуры
меньше в разы.
Re[3]: Beep: первые результаты
От: thesz Россия http://thesz.livejournal.com
Дата: 28.02.09 19:23
Оценка: +1
dmz>>>Beep с компиляцией
T>>Сильно.
T>>beepc на чём?
dmz>На ocaml. Хаскелл когда начинал не осилил (точнее, не понял как на нем надо писать), но зато в процессе
dmz>написания понял, что хаскелл крутой.

Интересно.

Расскажешь?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: Beep: первые результаты
От: z00n  
Дата: 28.02.09 21:08
Оценка:
Здравствуйте, 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
Re: Beep: первые результаты
От: z00n  
Дата: 28.02.09 21:11
Оценка: 4 (1)
Здравствуйте, dmz, Вы писали:

dmz>Для начала, спасибо всем, кто отвечал на мои вопросы по данной теме.

А про Hume рассказали?
Re[2]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 04:13
Оценка:
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 для статического
языка обязана работать быстрее, чем для динамического в любом случае.
Re[2]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 04:40
Оценка:
Z>Мне кажется эти тесты меряют в основном скорость вывода в консоль — по крайней мере для луа 'print' занимает 3/4 времени. С закомментированной
печатью работает примерно в 2 раза быстрее питона (питон тоже без печати.)

В PC-шной сборке бипа, функция putsn реализована достаточно неэффективно:

VM_WORD beepvm__put_str(void *data)
{
    VM *vm = (VM*)data;
    VM_WORD addr = 0;
    VM_WORD *p;
    uint16_t len = 0;
    char *ps = 0;
    addr = beepvm__api_pop_arg(data);
    p  = ADDR2PTR(vm, addr);
    len = beepvm__api_strlen(data, p);
    ps = (char*)(p+1); 
    while( len-- ) printf("%c",*ps++);
    return 0;
}

VM_WORD beepvm__put_strn(void *data)
{
    beepvm__put_str(data);
    printf("\n");
    return 0;
}


так что, где-то как-то должны быть эквивалентны.

Замена в питоне функции 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
Re[2]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 04:53
Оценка:
CS>Честно говоря я затрудняюсь интрепретировать эти цифры.

Интерпретировать их надо так: если бы получилось так, что скорость бипа, была бы, скажем, в три раза медленнее питона, это бы значило,
что я где-то просчитался, например, каждый вызов GC стоит недопустимо дорого. Напомню — что у бипа он вызывался более 10000 раз на 0xFFFF
итераций. Причем, GC консервативный и очень дорогой, так как он обходит дерево объектов за константную (и очень маленькую) память. Даже без реверсирования указателей, так как реверсированные указатели тоже негде хранить.

А у питона его вообще толком нет, да и запускаться, я думаю, он бы не стал.

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

CS>Дело в том что код который ты тестировал уж сильно разный.

CS>В Python нет структур в твоем понимании.

Ну вон, привел в треде пример с кортежами и без консольного ввода-вывода, питон стал на 0.5 секунды быстрее.
Re[2]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 04:56
Оценка:
Z>Мне кажется эти тесты меряют в основном скорость вывода в консоль — по крайней мере для луа 'print' занимает 3/4 времени. С закомментированной печатью работает примерно в 2 раза быстрее питона (питон тоже без печати.)

А можно тест для Lua 5.0 ? 5.1 в репозитории нет, а этот скрипт под 5.0 не работает. С питоном сравнивать неспортивно, надо попробовать сравнить с грамотно реализованным языком, к которым я Lua отношу (пока не доказано обратное).
Re[2]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 05:09
Оценка:
Z>А про Hume рассказали?

Исходников они не дают. Кажется, он интерпретируемый. В примерах, собраных для Intel лежат какие-то бинарники с именем
Hume и весом 3 мегабайта, что наводит на мысли.

VM Бипа, собранная для Intel — 23 килобайта, если собрать без отладочной информации.

Если бы я мог взять что-то готовое, я бы взял Lua. Но оно не влезет.

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

PS. А если собрать BeepVM с оптимизацией -O2, то скрипт nmea.beep волшебным образом начинает работать 0.7 секунд
вместо 1.3
Re[4]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 05:40
Оценка:
T>Интересно.

T>Расскажешь?


Ну а что тут рассказывать? Более приятный и современный синтаксис. Более обширная и продуманная стандартная
библиотека, которая не менее важна, чем язык. Даже несмотря на то, что для OCaml есть ExtLib, без которой
вообще невозможно работать, все равно приходится все дописывать. Хаскелл — более консистентный.

Когда бы мне понадобилось взять от строки подстроку длиной N, или все что есть, если строка короче N — то я не
задумываясь написал бы (не заглядывая в документацию) take 5 s — и в хаскелле это отлично работает.

А в окамле 1) вообще нет take 2) когда он найдется в ExtLib, он не будет работать со строками 3) Всякие функции String.sub
работают не так (надо вычислять смещение) 4) Еще они падают с исключением, которое нафиг тут не нужно.

И так везде. В итоге, что бы сделать такую простую вещь, в окамле надо 1) перерыть доки 2)убедиться, что все равно как надо
не работает 3) написать свою обертку

Библиотека окамла неинтуитивна, потери на чтение документации велики. Но хуже то, что когда мне в следующий раз через полгода понадобиться
потранкейтить строку, я опять напишу take 5 s, обломаюсь, пойду искать свою реализацию, не найду, пойду читать документацию и писать свою обертку.

Язык все же неплохой, обертка пишется быстро — но если мощи встроенной, поставляемой с языком библиотеки не хватает, это автоматически
означает, что язык не подходит на роль Swiss Army Knife, то есть для автоматизации повседневных задач. А для меня это важно, так как есть
привычка скриптовать все на том языке, который я пытаюсь изучить, что бы научиться и не забывать.

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

Но с другой стороны — я уже напоролся на проблемы производительности и пришлось существенно напрячься, что бы ускорить компиляцию, и не допускать что бы она была не более одной секунды на скрипт, который в состоянии написать человек. И вот как бы тут повел себя хаскелл — я не знаю.
Re[5]: Beep: первые результаты
От: Cyberax Марс  
Дата: 01.03.09 05:53
Оценка: +1
Здравствуйте, dmz, Вы писали:

dmz>Особенно я обламываюсь сейчас из-за того, что забыл перл

Расскажи как тебе это удалось!!

dmz>а питон и окамл категорически не годятся для написания однострочников

Хмм... Я как раз Питоном для однострочников пользуюсь...
Sapienti sat!
Re[6]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 06:18
Оценка:
dmz>>Особенно я обламываюсь сейчас из-за того, что забыл перл
C>Расскажи как тебе это удалось!!

Это элементарно. Даже когда я на нем активно программил (включая perlguts-xs, ЕВПОЧЯ), году так в 2002ом,
то и то не мог в каждый момент уверенно сказать какую кракозябру когда применить, а так же, когда имею дело со ссылкой,
а когда со значением. Все вот эти $@# и скалярно-векторные контексты крайне задалбывали. Особенно запомнился момент, когда я после нескольких часов бодания просто тупо один в один переписал работу с какой-то сложной вложенной структурой данных на питоне, и оно сразу заработало правильно, просто в силу того, что там негде было накосячить с пресловутыми контекстами.


dmz>>а питон и окамл категорически не годятся для написания однострочников

C>Хмм... Я как раз Питоном для однострочников пользуюсь...

Ну вот у меня есть много-много-экранный вывод лога компилятора с таймстемпами вида

СТРОКА ВСЯКИЙ БРЕД 0.XXXXX
....


Мне надо написать фильтр для шелла, который отфильтрует по строке, отцепит крайние значение (таймстемп), и
результаты просуммирует. Можно это сделать коротким однострочником на питоне? Который набрать быстрее, чем
запустить электронную таблицу (как это сделал бы обычный пользователь). Питон многословен, и потребует импорты.
А так-же, если что-то не влезет в лямбду, то потребуются отступы — и все, однострочник не получился.

На перле это сделать точно можно, только я забыл какой кракозяброй получить последний элемент массива, который выдает
split. Читать документацию принципиально не буду, так как это будет инвестиция в мертвый (для меня) язык.
Re[3]: Beep: первые результаты
От: c-smile Канада http://terrainformatica.com
Дата: 01.03.09 06:32
Оценка:
Здравствуйте, dmz, Вы писали:


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 прооптимизированные по самое нихочу.
Re[6]: Beep: первые результаты
От: FR  
Дата: 01.03.09 06:33
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, dmz, Вы писали:


dmz>>Особенно я обламываюсь сейчас из-за того, что забыл перл

C>Расскажи как тебе это удалось!!

Да это легко, у меня тоже самое с фортом
Re[5]: Beep: первые результаты
От: FR  
Дата: 01.03.09 06:37
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>Ну а что тут рассказывать? Более приятный и современный синтаксис. Более обширная и продуманная стандартная

dmz>библиотека, которая не менее важна, чем язык. Даже несмотря на то, что для OCaml есть ExtLib, без которой
dmz>вообще невозможно работать, все равно приходится все дописывать. Хаскелл — более консистентный.

OCaml вообще коряв и безобразен, но он очень прост и на нем легко писать в очень разных стилях, поэтому наверно и живет и поэтому наверно при меньшей популярности на нем пишут (и главное дописывают) намного больше чем на хаскеле.
Re[7]: Beep: первые результаты
От: frogkiller Россия  
Дата: 01.03.09 06:39
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>На перле это сделать точно можно, только я забыл какой кракозяброй получить последний элемент массива, который выдает split.


Всё проще, и без кракозябл. $arr[-1] даст последний элемент @arr.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[3]: Beep: первые результаты
От: z00n  
Дата: 01.03.09 06:48
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>Исходников они не дают.

Шотландцы!

dmp> Кажется, он интерпретируемый.

Там есть несколько вариантов, например:

The Hume to C compiler (humec) translates HAM instructions
produced by the phamc compiler into portable C code using a template-instantiation approach.
This provides a higher-performance route for deploying Hume code, that has been tested on a
number of platforms, including Linux, MacOSX, the a Renesas M32C development board and the
Tmote Sky. The Renesas board uses a 32-bit embedded microcontroller with 16KB DRAM, the
Tmote Sky is a 16-bit standalone computing device with 8KB of DRAM


dmz>В примерах, собраных для Intel лежат какие-то бинарники с именем

dmz>Hume и весом 3 мегабайта, что наводит на мысли.
Это, наверное, компилятор, написанный на Haskell.

dmz>VM Бипа, собранная для Intel — 23 килобайта, если собрать без отладочной информации.

У них есть маленький интерпретатор: hami
Re: Beep: первые результаты
От: D. Mon Великобритания http://thedeemon.livejournal.com
Дата: 01.03.09 06:49
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>Для тех кто не в курсе, кратко напомню: Beep (Бип, звук, которым забивают непечатные ругательства в эфире, так как именно их я произнес, когда понял, что мне придется написать этот язык) — это питоно-луа образный язык со статической типизацией и выводом типов, компилируемый в байткод и предназначенный, по замыслу, для скриптования на микроконтроллерах (таких, куда не впихнешь Java и Lua). Является заменой форту. Сейчас он работает на MSP TI430, размер памяти именно на язык определяется размером выделенного хипа и стеков. Сейчас это контроллер с 5K RAM на борту, но будет работать и на 2K — младшие процессоры в линейке.


А можешь про свою VM рассказать?
Re[3]: Beep: первые результаты
От: z00n  
Дата: 01.03.09 07:10
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>А можно тест для Lua 5.0 ? 5.1 в репозитории нет, а этот скрипт под 5.0 не работает. С питоном сравнивать неспортивно, надо попробовать сравнить с грамотно реализованным языком, к которым я Lua отношу (пока не доказано обратное).

Луа медленнее, чем мог бы быть — потому что принципиально написан на ANSI C.
Если интересно — есть такой ресурс по написанию быстрых VM: http://www.complang.tuwien.ac.at/projects/interpreters.html

Код для луа 5.0.x:
--// lua 5.0.x

local byte, sub = string.byte,string.sub

local COMMA, STAR = byte(","), byte("*")

local function nmea_parse_gga(s)
  local result, j, comma = {}, 1, 0
  local len = string.len(s)
  for i=1,len do
    local c = byte(s,i)
    if c == COMMA then
      comma = comma + 1
      if     comma == 2 then result.time_utc = sub(s,j,i-1)
      elseif comma == 3 then result.lat      = sub(s,j,i-1)
      elseif comma == 4 then result.lat_semi = sub(s,j,i-1)
      elseif comma == 5 then result.lon      = sub(s,j,i-1)
      elseif comma == 6 then result.lon_semi = sub(s,j,i-1)
      elseif comma == 7 then result.fix      = sub(s,j,i-1)
      elseif comma == 8 then result.sat      = sub(s,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"

local N = 65535

for i=1,N 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
Re[7]: Beep: первые результаты
От: Cyberax Марс  
Дата: 01.03.09 07:22
Оценка: +1
Здравствуйте, dmz, Вы писали:

C>>Расскажи как тебе это удалось!!

dmz>Это элементарно. Даже когда я на нем активно программил (включая perlguts-xs, ЕВПОЧЯ), году так в 2002ом,
dmz>то и то не мог в каждый момент уверенно сказать какую кракозябру когда применить, а так же, когда имею дело со ссылкой,
dmz>а когда со значением. Все вот эти $@# и скалярно-векторные контексты крайне задалбывали. Особенно запомнился момент, когда я после нескольких часов бодания просто тупо один в один переписал работу с какой-то сложной вложенной структурой данных на питоне, и оно сразу заработало правильно, просто в силу того, что там негде было накосячить с пресловутыми контекстами.
Вот-вот. Мне программы на нём до сих пор снятся

dmz>Мне надо написать фильтр для шелла, который отфильтрует по строке, отцепит крайние значение (таймстемп), и

dmz>результаты просуммирует. Можно это сделать коротким однострочником на питоне?
На шэле точно можно: "cat yourfile | sed s/^.*\.//g | sum"
Sapienti sat!
Re[4]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 07:34
Оценка: 70 (7)
CS>Собственно цифры важны за для понять стоит ли овчина выделки.
CS>Я имею ввиду компиляцию с оптимизацией по типам.

Собственно, никакой язык кроме статического в целевую платформу просто не влезет.
Так как если мы вынуждены хранить информацию о типе объекта для каждого объекта,
это автоматически означает, что каждый объект сразу занимает 32 бита вместо 16.

И еще вот что — я готов писать сколь угодно сложный компилятор на нормальном языке типа окамла или
хаскелла, но я категорически не готов писать сколько-нибудь сложную VM на языке С. Вообще не готов писать что-то сложное
на языках уровнем ниже определенного. Я год назад вообще думал, что я не готов что-то писать что-либо на чем-либо вообще.

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

CS>Вот статья с DDJ Embedded про язык BOB

CS>А чего бы не взять скажем TinyVM (писана для Lego Mindstorms) http://tinyvm.sourceforge.net/
CS>Это JavaVM т.е. можно использовать Java compilers прооптимизированные по самое нихочу.

А есть еще NanoVM, PicoVM, NekoVM. Еще есть PIC16FORTH, PIC18FORTH, пачка схем ,и много другого. Их я
изучал тоже. Еще я усиленно ковырял Lua на предмет встраивания.

1) Я рассмотрел все языки, которые нашел на момент до начала компилятора
2) TinyVM не влезало в минимальную целевую платформу (PIC18) на момент начала разработки
3) JavaCard и тот, по моему, не влезал
4) Есть еще цель — получить максимально компактный байткод, так как он будет грузиться по каналам.

Так вот конкретно про Java, не надо думать, что там нормальная джава. Там НЕ нормальная джава, и какими-то
конструкциями пользоваться нельзя. Во что это "нельзя" выливается я не знаю — либо они в байткоде анализируют
невалидные инструкции, либо просто их не реализуют в VM — с непредсказуемым результатом. Более того, если
потребуется вносить какие-то изменения в компилятор или VM — а потребуется почти наверняка — то любая возня
на низкоуровневых языках сразу приведет к тому, что дешевле написать свое с нуля.

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

Для примера — у меня тут лежат исходники двух языков с выводом типов — Boo на C# и Haxe на NekoML и окамле.
Так, система типов Boo — это 107 файлов и 15759 строк / 479001 символов и я даже пытаться не стал ее понять.

Система типов Haxe —

dmz@x200:~/prj/haxe/haxe-1.19/haxe$ cat ./type.ml ./typer.ml  | wc -lc
   4096  125288


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

Так что я думаю, что решение написать свое — оказалось вполне адекватно. Типы + компиляция + кодогенерация — 1022 строки на окамле. Это немного.
Думаю адаптация любого друго решения, и особенно, уплотнение байткода (а в планах — вплоть до хаффмановских кодов) — заняла бы просто тупо больше времени. И окончилась бы форком и поддержкой большого чужого проекта на каком-нибудь неподходящем языке.

Вообще, все как сговорились компиляторы (Компиляторы!!! — не тайм-критикал системы!) писать на си. Когда с девяностых годов существует хотя бы Окамл.

И вообще мне получившийся в результате язык нравится больше джавы, уж для целей мелкого скриптинга уровня "если по машине долбанули кувалдой — то послать смс с ахтунгом" — то точно. Так что я выкидывать его не буду, а наоборот, сделаю оптимизацию хвостовой рекурсии и может, генерацию нативного кода — получится вообще приличный язык.
Re[4]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 07:53
Оценка:
Z>Там есть несколько вариантов, например:

Tmote Sky is a 16-bit standalone computing device with 8KB of DRAM


У MSP430F1611 2K килобайта RAM... И я думаю, что все это поделие туда влезет.
А если выкинуть операционную систему FreeRTOS, которая занимается тредами — которых два —
в одном работает скрипт, во втором мигает диод, что бы мне было не скучно — и вообще
памяти нужно будет только на буфера ввода-вывода, стеки и хип.

dmz>>В примерах, собраных для Intel лежат какие-то бинарники с именем

dmz>>Hume и весом 3 мегабайта, что наводит на мысли.
Z>Это, наверное, компилятор, написанный на Haskell.

Z>У них есть маленький интерпретатор: hami


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

Да и ну их вообще. Я и не думал вовсе, что я единственный человек в мире, который написал vm для всяких мелких девайсов.
И вообще, в силу того, что похоже на питон и луа, то есть внешне простое — я думаю, ко мне быстрее народ потянется.

Если я пойму, что это хоть кому-то нужно, я это выложу в опенсорц. В принципе получилось нечто такое, что уже жалко будет
выбросить или забыть.
Re[4]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 08:39
Оценка:
Z>Код для луа 5.0.x:

1.5s. Луа крут. На ANSI C они его, написали, наверное, зря. Точнее так — надо было сделать версию для GCC и версию ANSI,
дефайнами перекрыть или еще как. GCC поддерживает label as values, что дает возможность наиболее быстрой интерпретации
Token-threaded code, каковой и используется в Beep, и, кажется, в Lua.

У меня есть исследование одних товарищей, они там анализируют различные способы интерпретации и приходят к выводу,
что способ интерпретации такого вида:

    goto *instruction[code[++ip]];


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

Итого: lua 1.5s, python 2.5s, beep (-O2), 0.7s.
Re[5]: Beep: первые результаты
От: Cyberax Марс  
Дата: 01.03.09 08:42
Оценка: +1
Здравствуйте, dmz, Вы писали:

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

dmz>выбросить или забыть.
Выкладывай. По крайней мере, просто даже почитать код будет интересно.
Sapienti sat!
Re[5]: Beep: первые результаты
От: z00n  
Дата: 01.03.09 09:34
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>1.5s. Луа крут. На ANSI C они его, написали, наверное, зря. Точнее так — надо было сделать версию для GCC и версию ANSI,

dmz>дефайнами перекрыть или еще как. GCC поддерживает label as values, что дает возможность наиболее быстрой интерпретации
Это так, но авторы точно не будут этого делать
Автор luajit грозится переписать VM на ассемблере (и изменить байткод) — обещает без jit 200-400% ускорения на типичных операциях.

Ну и если переписать тест в луа-стиле c паттернами будет еще в 2-2.5 раза быстрее.
--// Lua 5.0.x
local gfind = string.gfind

local fields = {
  "header","time_utc","lat","lat_semi","lon","lon_semi","fix","sat"
}

local function nmea_parse_gga(s)
  local obj, comma = {}, 0
  for data, sep in gfind(s,"([^,*]*)([,*])") do
    comma = comma + 1
    if sep == "*" or comma > 8 then break end
    obj[fields[comma]] = data
  end
  return obj
end

--// TEST:

local s = "$GPGGA,121505,4807.038,N,01131.324,E,1,08,0,9133.4,M,46.9,M,,*42"

local N = 65535

for i=1,N 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
Re[5]: Beep: первые результаты
От: thesz Россия http://thesz.livejournal.com
Дата: 01.03.09 09:38
Оценка:
T>>Интересно.
T>>Расскажешь?
dmz>Ну а что тут рассказывать? Более приятный и современный синтаксис. Более обширная и продуманная стандартная
dmz>библиотека, которая не менее важна, чем язык. Даже несмотря на то, что для OCaml есть ExtLib, без которой
dmz>вообще невозможно работать, все равно приходится все дописывать. Хаскелл — более консистентный.

Соглашусь.

Последовательность соблюдения решений очень важна.

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

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


Уверяю тебя, ты был бы достаточно приятно удивлён.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[6]: Beep: первые результаты
От: thesz Россия http://thesz.livejournal.com
Дата: 01.03.09 09:39
Оценка:
FR>OCaml вообще коряв и безобразен, но он очень прост и на нем легко писать в очень разных стилях, поэтому наверно и живет и поэтому наверно при меньшей популярности на нем пишут (и главное дописывают) намного больше чем на хаскеле.

А вот новое пишут...
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: Beep: первые результаты
От: mkizub Литва http://symade.tigris.org
Дата: 01.03.09 10:21
Оценка:
Здравствуйте, dmz, Вы писали:


dmz>У меня есть исследование одних товарищей, они там анализируют различные способы интерпретации и приходят к выводу,

dmz>что способ интерпретации такого вида:

dmz>
dmz>    goto *instruction[code[++ip]];
dmz>


dmz>быстрейший из возможных для такого рода байткода (что довольно предсказуемо).

dmz>Цикл выборки отсутствует, в конце каждой команды — находится выборка следующей.

Ассемблер круче. А реализация на нём main loop интерпретатора байткода — неделя работы.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[2]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 11:09
Оценка: 20 (3)
DM>А можешь про свою VM рассказать?

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

На стек возвратов кладется адрес возврата функции и смещение текущего фрейма стека данных. Свободного доступа к регистру возвратов
R нет, его могут писать/читать только инструкции вызова и сохранения/восстановления фрейма. Текущий фрейм стека данных сохраняется,
что бы 1) были простые прологи/эпилоги функций 2) что бы переживать ситуацию, когда какие-то вычисления его загадили. В принципе
сейчас третья версия компилятора не дает возможности гадить в стек (те производить вычисления, которые имеют тип отличный от void и
которые ничему не присваиваются или не участвуют в выражении — но нативные функции могут гадить как им вздумается).

Стек данных разбит на фреймы, фрейм создается при вызове функции. Есть операции доступа к ячейкам стека относительно указателя фрейма —
т.е возможность изменить данные вне своего фрейма — отсутствует. Восемь ячеек выделены, и для доступа к ним используются однобайтные
операции — LOAD0 ... LOAD8, STORE0 .. STORE8. Для остальных есть литеральные команды LOADF, STOREF (передается смещение ячейки от начала фрейма).
Выделенные ячейки можно (и нужно) кэшировать в регистрах, и это легко сделать. Кроме того их можно сделать больше, так как пока
задействована 71 команда из 256 возможных.

Глобальных мутабельных данных нет. Константы времени компиляции хранятся в байткоде (program flash), в хип не грузятся. Program flash у нас
много, 30 — 80 килобайт, а вот хипа мало.

Хип. Хип организован как последовательность блоков, 16 бит на заголовок, размер блока, признак занятости и отметки GC. Таким образом, выделение нового блока — O(количество блоков). Алгоритм поиска — ищем подходящий свободный блок наименьшего размера, т.е. наверное типа O(2N). Это не очень хорошо, но так как хипа мало, то нестрашно. Я знаю как сделать за O(1), но нужна будет доп. таблица и вообще это потом, и так нормально.

Память адресуется строго словами. Никакой байтовой адресации. Это ускоряет сборщик минимум в два раза, и все остальное тоже сильно ускоряет.

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

Сборщик мусора — консервативный, трехцветный. Поскольку памяти для него нет, то дерево объектов обходится где-то квадратично. Это плохо, но
поскольку хипа мало, то не очень. Техника реверсирования указателей потребует место для хранения указателя в заголовке каждого блока, в общем, я не стал.

Но. Поскольку нет глобальных мутабельных данных, то периметр сборщика мусора ограничивается текущей глубиной стека данных. Соответственно, в некоторые моменты мы память можем освободить за O(1). В общем, тесты показывают, что большую часть времени оно так и работает;
серьезно нагнуть его можно, только если забить стек данными похожими на адреса — но это надо как-то специально постараться.

Типы данных — инт (он же используется для символов), так что если зачем нибудь понадобится поддержка юникода — то она будет бесплатной.
Все, что не помещается в инт — это ссылка на объект в хипе.

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

Туплы, списки — классические. Пробовал сделать VList, но накладные расходы для обоих подходов таковы, что проще оказалось пока на это забить.

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

Как-то так. Машина частично инспирирована джавовской, но попроще. Кстати, JVM сделана по-уму, и сравнительные отзывы о ней хорошие.

Как-то так. Вкратце получилось подробнее, чем у меня на вики
Re[6]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 11:19
Оценка:
M>Ассемблер круче. А реализация на нём main loop интерпретатора байткода — неделя работы.

Так нету, main loop-а то.

И в топку ассемблер. Есть у меня ассемблерная реализация для старой версии для PIC18 — еще для форта — и что с ней делать?
Платформа сменилась, несколько месяцев работы разработчика и деньги, ему заплаченные — выкинуты.

Трекеров в мире куча, все на чем попало, но си есть под каждый.

Да и не думаю я, что результаты будут сильно отличаться от си. Можно подумать, что goto *instruction[code[++p]] может скомпилироваться во что-то другое, чем то, чем оно является. Данные по регистрам gcc и так успешно распихивает. Да и производительность скрипта вообще почти неважна, если
честно. По первоначальной задумке. Правда теперь возникают мысли, что надо допилить VM до доступа к портам ввода-вывода, сделать сборку мусора рилтаймовой, сделать пре-компиляцию в нативный код (преобразованием token threading в code threading), рилтаймовый сборщик мусора и зеленые треды.
И забить даже на си.
Re[3]: Beep: первые результаты
От: maxp Россия http://penzin.ru/
Дата: 01.03.09 11:25
Оценка:
dmz>Основной мой пойнт, все-же, в том, что 1) статические языки работают быстрее

На простых задачах просто обязаны.

dmz> 2) по удобству использования они могут не уступать динамическим.


А вот это верно, видимо, толко для микроконтроллеров

Как, кстати, в Beep виртуальные методы реализуются?
Re[4]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 11:40
Оценка:
dmz>> 2) по удобству использования они могут не уступать динамическим.

M>А вот это верно, видимо, толко для микроконтроллеров


Ой ли? У меня есть пример разработки почти одного и того же проекта на питоне и на ocaml.
На питоне — транслятор форта. На окамле — компилятор бипа. На питоне кода получилось в разы
больше, а функцинальности — в разы меньше. Более того, компилятор бипа на питоне я бы (не говоря о том, что не написал бы никогда) —
писал бы год, большую часть времени отлаживаясь и гоняя юнит тесты (которые бы тоже надо было написать и поддерживать в актуальном состоянии).

Динамическая типизация, я уверен, появилась не то того, что она очень нужна — а от того, что именно такую
типизацию проще всего сделать. Местами она может и нужна, но таких мест меньшинство.

M>Как, кстати, в Beep виртуальные методы реализуются?


Так же как и везде — vtbl. Только я думаю, что ОО не стоит того, что бы ради него как-то напрягаться. Мелкая, частная,
ограниченно-полезная концепция (c) Луговский.

Т.е. если когда нибудь в бипе будут макросы — то объектная ориентированность будет реализована именно ими, именно
теми, кому она зачем-то понадобилась.
Re[4]: Beep: первые результаты
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.03.09 12:06
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>runtime обязан сначала просканировать класс, а потом сам объект.

CS>Т.е. имеем как минимум 2*O(1).

2*O(1) == O(1)

Точнее "2*O(1)" — это какое-то недоразумение. O(1) — означает константное время доступа, т.е. не изменяемое при увеличении количества элементов в коллекции и т.п. О том же сколько времени займет доступ O-нотация информации не дает. Ее задача описать масштабируемость алгоритма, а не его скорость.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Beep: первые результаты
От: maxp Россия http://penzin.ru/
Дата: 01.03.09 12:23
Оценка:
dmz>>> 2) по удобству использования они могут не уступать динамическим.

M>>А вот это верно, видимо, толко для микроконтроллеров


dmz>Ой ли? У меня есть пример разработки почти одного и того же проекта на питоне и на ocaml.

dmz>На питоне — транслятор форта. На окамле — компилятор бипа. На питоне кода получилось в разы
dmz>больше, а функцинальности — в разы меньше.

Очень может быть, что это просто личные предпочтения, как с Перлом, например

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

А вот в Питоне реально нравится возможность делать так

def factory( **kwa ):
        def g():
                for i in kwa['a']:
                        if i % 2:
                                yield i*i
        return g    

b = factory( a=[1,2,3,4,5] )


или практически тоже самое

a = [1,2,3,4,5]
b = (i*i for i in a if i % 2)



Надеюсь когда-нибудь увидеть Биип на каком-нибудь сорфорже или гуглекоде.
Если практически и не требуется, то по крайней мере познавательно.
Re[6]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 12:36
Оценка:
M>Очень может быть, что это просто личные предпочтения, как с Перлом, например

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

a = [1,2,3,4,5]
b = (i*i for i in a if i % 2)


Лист компрехеншены есть и в статических языках.

M>Надеюсь когда-нибудь увидеть Биип на каком-нибудь сорфорже или гуглекоде.


Я что-то вообще не понимаю, зачем эти сайты нужны. Лежать будет здесь: http://phenopy.net,
как только запустимся, приду в себя и займусь выкладыванием в оперсорц. Бип это маленькая часть проекта.
Большая кувалда для забивания маленького обойного гвоздя.
Re[7]: Beep: первые результаты
От: Cyberax Марс  
Дата: 01.03.09 12:52
Оценка: +1
Здравствуйте, dmz, Вы писали:

dmz>И забить даже на си.

Ты про LLVM не думал, кстати? Просто сделать retargeting под твою архитектуру (повыбрасывав всё лишнее оттуда). Получишь автоматически нормальный компилятор, а рантайм ты уже написал.
Sapienti sat!
Re[8]: Beep: первые результаты
От: FR  
Дата: 01.03.09 12:57
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ты про LLVM не думал, кстати? Просто сделать retargeting под твою архитектуру (повыбрасывав всё лишнее оттуда). Получишь автоматически нормальный компилятор, а рантайм ты уже написал.


У него и биндинг к OCamly есть.
Re[7]: Beep: первые результаты
От: FR  
Дата: 01.03.09 13:11
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>Я что-то вообще не понимаю, зачем эти сайты нужны. Лежать будет здесь: http://phenopy.net,


Нередко натыкаешся на что-то интересное в поисковике и DNS Error
Re[8]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 13:14
Оценка:
dmz>>И забить даже на си.
C>Ты про LLVM не думал, кстати?

Думал. Только я что-то не уверен, что он может эффективно генерить код для 16-битных платформ, да и вообще как-то вопрос о применении бипа для чего либо, кроме скриптования не стоял до сих пор.

C>Получишь автоматически нормальный компилятор, а рантайм ты уже написал.


А мой чем не нормальный? Я просто думаю, что от оптимизации на уровне AST все равно не уйти, так как какие-то вещи удобнее оптимизировать там, а на уровне промежуточного кода семантика потеряется, и там ее придется восстанавливать с переменных успехом. Да и вообще это все так пока — неопределенное будущее. То есть я не уверен, что получится сильно закопаться в разработку бипа, если именно в этом не будет каких=то коммерческих перспектив.

Скоро микроконтроллеры будут все 32-битные, а там джава всякая, линукс и прочая, прочая.
Re[8]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 13:26
Оценка:
dmz>>Я что-то вообще не понимаю, зачем эти сайты нужны. Лежать будет здесь: http://phenopy.net,

FR>Нередко натыкаешся на что-то интересное в поисковике и DNS Error


Оч. странно. Буду посмотреть. Да там нет сейчас ничего интересного, просто сайт где фенопи — набор api для сайтостроения на питоне лежит.
Re[9]: Beep: первые результаты
От: Cyberax Марс  
Дата: 01.03.09 13:26
Оценка:
Здравствуйте, dmz, Вы писали:

C>>Ты про LLVM не думал, кстати?

dmz>Думал. Только я что-то не уверен, что он может эффективно генерить код для 16-битных платформ, да и вообще как-то вопрос о применении бипа для чего либо, кроме скриптования не стоял до сих пор.
LLVM портировали под 31-битные платформы, так что я не думаю, что с 16-бит будут проблемы

C>>Получишь автоматически нормальный компилятор, а рантайм ты уже написал.

dmz>А мой чем не нормальный? Я просто думаю, что от оптимизации на уровне AST все равно не уйти, так как какие-то вещи удобнее оптимизировать там, а на уровне промежуточного кода семантика потеряется, и там ее придется восстанавливать с переменных успехом. Да и вообще это все так пока — неопределенное будущее. То есть я не уверен, что получится сильно закопаться в разработку бипа, если именно в этом не будет каких=то коммерческих перспектив.
Ну так LLVM — как раз промежуточный код и есть, там достаточно информации для нормальной оптимизации.
Sapienti sat!
Re[10]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 13:36
Оценка:
C>LLVM портировали под 31-битные платформы, так что я не думаю, что с 16-бит будут проблемы

Ну, я в любом случае не осилю. Сейчас это не нужно, а если вдруг надо будет прикрутить нативную кодогенерацию,
то другое дело. Впрочем, с наличием парсер-генераторов или комбинаторов, функциональных языков и LLVM можно
делать новый язык в неделю Так что смысла заморачиваться с бипом, опять же, мало.

C>Ну так LLVM — как раз промежуточный код и есть, там достаточно информации для нормальной оптимизации.

Ну, я про него и говорю. Совсем отказаться от оптимизаций на уровне компилятора не получится.
Re[7]: Beep: первые результаты
От: maxp Россия http://penzin.ru/
Дата: 01.03.09 14:04
Оценка:
Здравствуйте, dmz, Вы писали:

M>>Очень может быть, что это просто личные предпочтения, как с Перлом, например


dmz>Я все таки тешу себя мыслью, что я его знаю довольно хорошо и довольно долго. Просто как-то внезапно и

dmz>резко его разлюбил.

dmz>
dmz>a = [1,2,3,4,5]
dmz>b = (i*i for i in a if i % 2)
dmz>


dmz>Лист компрехеншены есть и в статических языках.


В данном случае это не лист компрехеншен, там скобочки отличаются () и [],
это создание функционального объекта-генератора,
почти то же самое, что было написано выше через yield.

Вся хреновина помнит свой стекфрейм, а это иногда очень приятно.

M>>Надеюсь когда-нибудь увидеть Биип на каком-нибудь сорфорже или гуглекоде.


dmz>Я что-то вообще не понимаю, зачем эти сайты нужны.


Там удобный и, главное, всем привычный интерфейс взаимодействия с сообществом.
(зачем тогда опенсорс вообще?)

Ткнуть в рсс иконку на каком-нибудь github'е дело обычное и понятное,
как и написать чего-нибудь в стандартную вику или багтракалку.
Re[8]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 14:19
Оценка:
M>В данном случае это не лист компрехеншен, там скобочки отличаются () и [],
M>это создание функционального объекта-генератора,
M>почти то же самое, что было написано выше через yield.

А, да. А это отличается, например, от ленивого вычисления?


M>Ткнуть в рсс иконку на каком-нибудь github'е дело обычное и понятное,

M>как и написать чего-нибудь в стандартную вику или багтракалку.

Вики, морду к git-у и базару можно поставить свою; впрочем это все орг. моменты, все потом.
Re[8]: Beep: первые результаты
От: z00n  
Дата: 01.03.09 14:42
Оценка:
Здравствуйте, maxp, Вы писали:

dmz>>Лист компрехеншены есть и в статических языках.


M>В данном случае это не лист компрехеншен, там скобочки отличаются () и [],

M>это создание функционального объекта-генератора,
M>почти то же самое, что было написано выше через yield.

M>Вся хреновина помнит свой стекфрейм, а это иногда очень приятно.

В наше время это много где доступно:
Практически все имплементации языков ML-группы (Ocaml smlnj Mlton) поддерживают continuations (неформально).
Scheme поддерживает continuations по стандарту.
В луа есть корутины, которые хуже continuations, но лучше генераторов.

-- // lua 
local co = coroutine
local wrap, yield = co.wrap,co.yield


local function factory(t)
  return wrap(function() 
                for i,v in ipairs(t.a) do 
                  if v%2~=0 then yield(v) end
                end
              end)
end

--// using:
local gen = factory{a={1,2,3,4,5}}
for x in gen do print(x,x) end
Re[9]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 14:45
Оценка:
M>>Вся хреновина помнит свой стекфрейм, а это иногда очень приятно.
Z>В наше время это много где доступно:
Z>Практически все имплементации языков ML-группы (Ocaml smlnj Mlton) поддерживают continuations (неформально).

Кстати, о континюэйшенах. Я так понимаю, сделать их очень просто — просто при вызове класть на стек адрес возврата (ну и стекфрейм, наверное).
Вопрос — от них реально есть какая-нибудь прибыль? Стоит ими заморочиться или нет?
Re[10]: Beep: первые результаты
От: z00n  
Дата: 01.03.09 14:59
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>Кстати, о континюэйшенах. Я так понимаю, сделать их очень просто — просто при вызове класть на стек адрес возврата (ну и стекфрейм, наверное).

dmz>Вопрос — от них реально есть какая-нибудь прибыль? Стоит ими заморочиться или нет?
Треды, корутины, генераторы, бэктрекинг, ексепшены, вебсервера.
Re[10]: Beep: первые результаты
От: mkizub Литва http://symade.tigris.org
Дата: 01.03.09 15:11
Оценка: +1
Здравствуйте, dmz, Вы писали:

dmz>Кстати, о континюэйшенах. Я так понимаю, сделать их очень просто — просто при вызове класть на стек адрес возврата (ну и стекфрейм, наверное).

dmz>Вопрос — от них реально есть какая-нибудь прибыль? Стоит ими заморочиться или нет?

Continuation — это дерево биндингов (локальных переменных), вместо стека, immutable дерево. Поскольку у тебя стековая машина, continuation-ы у тебя не получатся, если ты только не будешь вызывать методы создавая под них фрейм в хипе, а не стеке (и значит, continuation внутри метода у тебя тоже не получится).
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[11]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 15:18
Оценка:
M>Continuation — это дерево биндингов (локальных переменных), вместо стека, immutable дерево.
Почему дерево?
Re[12]: Beep: первые результаты
От: mkizub Литва http://symade.tigris.org
Дата: 01.03.09 15:27
Оценка:
Здравствуйте, dmz, Вы писали:

M>>Continuation — это дерево биндингов (локальных переменных), вместо стека, immutable дерево.

dmz>Почему дерево?

Ну потому, что продолжение должно иметь сохранённое состояние биндингов ("стека"), чтоб продолжить выполнение. При этом оно дописывает чего-то в этот "стек", может делать return, их может выполняться несколько параллельно (и они не должны портить "стек" друг другу). Иначе чем через immutable дерево это не сделать.
SOP & SymADE: http://symade.tigris.org , блог http://mkizub.livejournal.com
Re[9]: Beep: первые результаты
От: FR  
Дата: 01.03.09 16:43
Оценка:
Здравствуйте, dmz, Вы писали:

FR>>Нередко натыкаешся на что-то интересное в поисковике и DNS Error


dmz>Оч. странно. Буду посмотреть. Да там нет сейчас ничего интересного, просто сайт где фенопи — набор api для сайтостроения на питоне лежит.


Я не про твой сайт, а вообще, все таки публичные сайты насчет этого надежнее.
Re[10]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 17:07
Оценка: :)
dmz>>Оч. странно. Буду посмотреть. Да там нет сейчас ничего интересного, просто сайт где фенопи — набор api для сайтостроения на питоне лежит.

FR>Я не про твой сайт, а вообще, все таки публичные сайты насчет этого надежнее.

Ага, и трафик в деньги конвертируют самостоятельно.
Re[10]: Beep: первые результаты
От: maxp Россия http://penzin.ru/
Дата: 01.03.09 17:10
Оценка:
dmz>>Оч. странно. Буду посмотреть. Да там нет сейчас ничего интересного, просто сайт где фенопи — набор api для сайтостроения на питоне лежит.

FR>Я не про твой сайт, а вообще, все таки публичные сайты насчет этого надежнее.


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

И эти самые разработчики не будут ходить по десятками разных сайтов,
они будут пользоваться чем-то унифицированным.
Re[11]: Beep: первые результаты
От: FR  
Дата: 01.03.09 17:14
Оценка:
Здравствуйте, maxp, Вы писали:

M>Смысл оперсорсных репозиториев вовсе не в надёжности, а в коммунити.


Просто ты не вытягивал кусочки нужной информации из вебархива и кеша поисковиков.
Re[11]: Beep: первые результаты
От: dmz Россия  
Дата: 01.03.09 17:16
Оценка:
M>Там уже есть разработчики, для которых проект и делается открытым.
M>И эти самые разработчики не будут ходить по десятками разных сайтов,
M>они будут пользоваться чем-то унифицированным.

Если проект интересный, то разработчики затусуются на любом сайте. Например, ядро линукса лежит на сорсфорже или на гитхабе?
И вообще, распределенный контроль версий этот фактор вообще убирает.
Re[12]: Beep: первые результаты
От: maxp Россия http://penzin.ru/
Дата: 01.03.09 17:43
Оценка:
Здравствуйте, FR, Вы писали:

FR>Здравствуйте, maxp, Вы писали:


M>>Смысл оперсорсных репозиториев вовсе не в надёжности, а в коммунити.


FR>Просто ты не вытягивал кусочки нужной информации из вебархива и кеша поисковиков.


Конечно не вытягивал

Так как мой рабочий код ежедневно копируется на пару серверов в разных странах,
а немного реже этот же код попадает на компакт диски и лежит потом в пожаробезопасном месте.
Re[13]: Beep: первые результаты
От: FR  
Дата: 01.03.09 18:03
Оценка:
Здравствуйте, maxp, Вы писали:

FR>>Просто ты не вытягивал кусочки нужной информации из вебархива и кеша поисковиков.


M>Конечно не вытягивал


M>Так как мой рабочий код ежедневно копируется на пару серверов в разных странах,

M>а немного реже этот же код попадает на компакт диски и лежит потом в пожаробезопасном месте.

А причем тут твой код, я писал про интересную мне информацию, которая стала недоступной по причине
того что авторы держали ее не на публичных и поэтому уже не доступных сайтах.
Re[5]: Beep: первые результаты
От: c-smile Канада http://terrainformatica.com
Дата: 01.03.09 20:15
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, c-smile, Вы писали:


CS>>runtime обязан сначала просканировать класс, а потом сам объект.

CS>>Т.е. имеем как минимум 2*O(1).

VD>2*O(1) == O(1)


VD>Точнее "2*O(1)" — это какое-то недоразумение. O(1) — означает константное время доступа, т.е. не изменяемое при увеличении количества элементов в коллекции и т.п. О том же сколько времени займет доступ O-нотация информации не дает. Ее задача описать масштабируемость алгоритма, а не его скорость.


"как минимум 2*O(1)" означает буквально следующее:

Стоимость исполнения
obj.prop = "something"

есть операция сложности O(d) * O(hash-lookup) где d это количество классов и суперклассов объекта плюс один.
Минимальное значение d в обсуждаемом случае это 2.
Re[7]: Beep: первые результаты
От: Tonal- Россия www.promsoft.ru
Дата: 14.03.09 17:07
Оценка:
Здравствуйте, dmz, Вы писали:
dmz>Ну вот у меня есть много-много-экранный вывод лога компилятора с таймстемпами вида

dmz>
dmz>СТРОКА ВСЯКИЙ БРЕД 0.XXXXX
dmz>....
dmz>


dmz>Мне надо написать фильтр для шелла, который отфильтрует по строке, отцепит крайние значение (таймстемп), и

dmz>результаты просуммирует. Можно это сделать коротким однострочником на питоне? Который набрать быстрее, чем
dmz>запустить электронную таблицу (как это сделал бы обычный пользователь). Питон многословен, и потребует импорты.
print sum(int(x.rsplit('.', 1)[-1]) for x in file('log'))
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[8]: Beep: первые результаты
От: dmz Россия  
Дата: 14.03.09 18:43
Оценка:
T>
T>print sum(int(x.rsplit('.', 1)[-1]) for x in file('log'))
T>


Только вот читать надо, обычно, из stdin, а это потребует импорта sys.
Re[9]: Beep: первые результаты
От: Tonal- Россия www.promsoft.ru
Дата: 16.03.09 04:30
Оценка:
Здравствуйте, dmz, Вы писали:
T>>
print sum(int(x.rsplit('.', 1)[-1]) for x in file('log'))

dmz>Только вот читать надо, обычно, из stdin, а это потребует импорта sys.
Чуть длиннее получится:
import sys; print sum(int(x.rsplit('.', 1)[-1]) for x in sys.stdin)
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.