А формат этих файлов где-нибудь описан?

Для их загрузки/сохранения используется аналог pickle из python.

Дополню второй вопрос:

Сответствует ли он тому формату, который будет в «метапроге-на-себе»? Или человек, решившийся поэкспериментировать с прототипом, должен быть готов к тому, что после выхода метапрога-на-себе его эксперименты превратятся в тыкву?

ТС не в состоянии поделить 4 на 0.1 а ты тут про грамматику русского языка и какие то форматы… Нельзя быть таким жестоким!

Так я уже все расписал в чем заключается «ШО». Тогда будьте честны до конца и называйте вещи своими именами, это бенчмарк неважного С кода и всего остального. С таким же успехом любой может написать скрипт который генерирует С код, собрать его С компилятором и рассказывать потом как его скрипт «уделывает» по скорости любые другие скрипты, но ведь это ложь в чистом виде. У вас это и выходит сейчас.

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

Вообще то базарная разработка не обязательно приводит к слому обратной совместимости, но эти ребята ее несомненно сломают - просто потому, что сами не понимают что творят.

Ну дык всегда можно нарисовать еще диаграмм, это же так легко и главное приятно!;-)

А можно автограф от тебя на мой школьный портфель?

Если ты про антоновский бенчмарк, то точно ли там 25 раз? Может в 2,5? Я там не разглядел внешний цикл на 10 итераций.

Одна итерация антоновского бенчмарка ~0.150s твоего бенчмарка ~3.9s

Хотя зачем смотреть сишные трансляции, если ты сам не являешься разработчиком транслятора Метапрога?

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

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

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

abcq: удаляешь последний в цепочке, далее я, потом опять ты.

Все что мог удалил )

Это теперь если только AntonI вот это удалит…

Э… А что вы делаете?:-)

И ты тоже, кстати. Я тут Метапрогу (человеку) каверзный вопрос задал, ожидаю, что он подумает мозгами и ответит. Но поскольку за него начали отвечать другие, появилось подозрение, что тема утонет во флуде… Можешь удалённые посмотреть, если права есть.

Удаляют комментарии свои. Жаль старые не удалить. Ну что обьявляем режим тишины. Пусть ТС сам с собой разговаривает :).

Я тот свой коммент удалить не могу почему то…

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

Повтори вопрос несколько раз?

Ок.

Я тот свой коммент удалить не могу почему то…

Ах да, забыл, это в течение часа только можно сделать.

Повтори вопрос ещё раз и попроси больше не флудить?:-)

Опять диагармме

Опечатка. Буквы А и Р находятся недалеко и когда пишу в две руки случается «состояние гонки» (race condition). Не считаю это критичным, поскольку это текст, предназначенный для чтения людьми, которые и так поймут, а не код на текстовм ЯП, в котором даже на одну буковку ошибиться нельзя.

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

Прототип Метапрога это умеет уже около года.

А формат этих файлов где-нибудь описан?

Диаграммы существуют в виде кластера (аналог структуры). Кластера и стандартный лабвьюшный функционал бинарной сериализации-десериализации в строку, как-то так:

https://zone.ni.com/reference/en-XX/help/371361R-01/glang/flatten_to_string/

https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/type_descriptors/

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

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

И соответствует ли он тому формату, который будет в «метапроге-на-себе»?

Я еще и сам не знаю каким он будет в Метапроге «на самом себе». Да и функционал бинарной сериализации-десериализации можно реализовать очень даже по-разному. Постараюсь сделать как можно более оптимальный. В любом случае, для сериализации-десериализации надо еще реализовать свич по многотиповому и цикл по структуре (по сути структуры-макросы, определяемые во время компиляции и не переходящие в готовый код).

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

Собственные диаграммы

Сответствует ли он тому формату, который будет в «метапроге-на-себе»? Или человек, решившийся поэкспериментировать с прототипом, должен быть готов к тому, что после выхода метапрога-на-себе его эксперименты превратятся в тыкву?

Вряд ли он ему соответствует, я, опять же, пока сам не знаю каким будет формат в Метапроге «на самом себе». Но в любом случае обязательно будет транслятор диаграмм с лабвьюшного прототипа на «Метарпог на самом себе» - схемы, сделанные на прототипе Метапрога, не пропадут.

При изменении формата (обычно это просто изменение кластера) я сохраняю совместимость с данными старых версий благодаря бинарным версионированным форматам. С метапроговскими СУВТ и бинарными версионированными форматами (что по сути подвид СУВТ) это станет еще проще.

я, опять же, пока сам не знаю каким будет формат в Метапроге «на самом себе»

А не кажется ли, что всё-таки пора начинать проектировать свой метапрог? Ты же понимаешь, что когда твой проект зарисован где-нибудь на бумаге (условно) в подробности (архитектура, описания форматов и т.п.), то тебе самому будет намного проще.

это бенчмарк неважного С кода и всего остального

Я и так писал, что это бенчмарк, сравнивающий Си, сгенерированный прототипом Метапрога, рукописный Си и другие ЯП.

С таким же успехом любой может написать скрипт который генерирует С код, собрать его С компилятором

Напиши. И такой, чтоб диаграммы строить (удобнее чем в Лабвью, а не как у Рината в шоутайме), чтоб был универсальным и при этом генерировал быстрый сишный код. Если он будет лучше Метапрога - перейду на него и признаю твою правоту.

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

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

Было бы удивительно, если бы си в кружочках был значительно медленнее си.

Но тем не менее «Си в кружочках» оказался медленнее богомерзких плюсов в СОРОК РАЗ. Самое смешное что у ТС банально не хватает знаний арифметики что бы это осознать (4 поделить на 0.1 выдающийся конструктор паровозов не в состоянии) и принять.

Ну так это же прекрасно. Хотя кружочков я на своих диаграммах не вижу, так как спиртного (или что там у тебя) не употребляю.

А не сложно будет запустить питоновский вариант бенчмарка вот отсюда для сравнения?

По поводу 0.1 я не заметил то сообщение, видел только твое, где время - секунда. Да, у меня медленная реализация из-за отсутствия аппаратного ускорения которое, скорее всего, присутствует «под капотом» функций из твоей реализации. Вернемся к теме бенчмарков позже, когда сделаю быструю функцию поиска по массиву и вкручу параллелизм.

И, как бы то ни было, питон и прочая скриптуха сливает даже корявой реализации на прототипе Метапрога.

Выпуск 10 версии

Выпущена 10 версия прототипа Метапрога. Содержит хотфиксы, исправляющие всплывшие в 8 и 9 версиях проблемы с транслятором диаграмм и онлайн-функционалом.

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

Какое аппаратное ускорение, Вы бредите?! Код хоть гляньте…

Слив в 40 раз это совершенно эпичный фейл, особенно после Ваших многочисленных излияний про тормознутые плюсы и архибыстрый С, скорость которого перейдет метапрогу 1:1.

И, как бы то ни было, питон и прочая скриптуха сливает даже корявой реализации на прототипе Метапрога.

Только в Вашей альтернативной вселенной. Сейчас посмотрим что provaton напишет по поводу питоньего варианта бенча, нужно сравнивать результаты запуска разных бенчей на одной машине.

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

Кстати, нашел как оно в Лабвью: https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/type_descriptors/

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

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

Не, лучше вот этот:

#!/usr/bin/python

import sys, random, time
s0 = ''.join(map(chr, range(97,123)))

r100, r20, r80 = range(100), range(20), range(80)

t0 = time.time()
stable = [''.join(s0[int(random.random()*26)] for j in r100) for i in xrange(100000)]
t1 = time.time()
print 'generate strings', t1-t0

htable = {}
for I in xrange(len(stable)):
    s = stable[I]
    for k in r80: htable.setdefault(s[k:k+3], []).append((I, k))
t2 = time.time()
print 'generate hash', t2-t1, len(htable)

matches = 0
for i in range(1000):
    s =  ''.join(s0[int(random.random()*26)] for k in r20)
    for k, off in htable.get(s[:3], []): matches += s==stable[k][off:off+20]
t3 = time.time()
print 'search time', t3-t2
print 'total time', t3-t0

print 'matches', matches

у меня на ноуте

$ ./bench2.py 
generate strings 2.6742589473724365
generate hash 4.789047002792358 17576
search time 0.37021803855895996
total time 7.833523988723755
matches 0

это в полтора раза быстрее чем предыдущий вариант.

На машине с аналогичной Вашемц процессором

$ ./bench2.py 
generate strings 1.60851407051
generate hash 2.87159490585 17576
search time 0.239169120789
total time 4.71927809715
matches 0

но плюсовый бенч на этой же машине вдвое медленнее чем у Вас, так что есть надежда что питон таки тоже обгонит метапроговскую реализацию;-)

В твоём сгенерированном коде — UB. Поэтому как оно будет работать, зависит от того, как звёзды сложились. И нет, «у меня работает» не прокатит.

И ещё я не заметил проверки совпадения строк после поиска в массиве хешей. Так что даже без оглядки на неопределённое поведение реализация просто некорректная. Какой смысл меряться секундами, если ты вообще не ту задачу решаешь?

Кстати, до результата AntonI тебе с твоим подходом никак не добраться, как ни старайся. Он очень удачно заюзал особенности задачи и особенности устройства процессоров, чтобы кардинально уменьшить число необходимых вычислений. А ты даже не понимаешь, где и на что твоя программа тратит время. Волшебный Си тебя не спасёт, тут мозгами нужно шевелить.

Выпуск 10 версии

От же ё, я ищу новую тему, а ты, оказывается, эту переименовал. Через некоторое время кто-то будет читать и сразу запутается, почему сначала речь шла про 8 версию, потом про 9, потом про 10, хотя тема вроде бы сразу про 10.

«Конец, конец… концы в воду»!

~/tmp/mp » python2 test-anton.py                                                                               
generate strings 1.62847805023
generate hash 2.37565588951 17576
search time 0.158673048019
total time 4.16280698776
matches 0

Чуть-чуть медленнее чем метапроговская реализация.

Запусти ещё под PyPy, пожалуйста.

блин я в своих проектах никак не могу добраться до точки v. 1.0 как правило, потому что по идее пока продукт не обеспечивает 100% задуманную функциональность он не может быть версии 1.0))) А тут уже версия 10))) Ну каждый конечно сам выбирает систему версионирования, но на мой взгляд она не должна вводить конечного пользователя в заблуждение

~/tmp/mp » pypy test-anton.py                                                                                  
generate strings 0.361654996872
generate hash 2.65547704697 17576
search time 0.0308878421783
total time 3.04801988602
matches 0

А вот pypy уже уделывает реализацию ТСа почти на секунду. Что скажете, metaprog ?

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

Вообще указывали;-)

У меня в плюсовом бенчмарке уходит по 4-8 байт дополнительно на каждую подстроку, т.е. исходный набор строк 1e5*100=10Мб, а на хранение хэшей еще 1e5 x 80 x 4=32 или 64 Мб.

Но если бы обрабатывать надо было не 1000 вхождений подстрок а так 1e6 или 1e9, то боюсь даже питоновская реализация порвала бы метапрог на британский флаг.

ЗЫ впрочем и так тоже порвала.

Мдя, немножко не дотянули… ну ничего, я сейчас с array еще поколдую;-)

У меня pypy дает выигрыш по генерации строк, но тормозит набивку хэшей, общее время с ним растет.

МЕТАПРОГ СЛИВАЕТ ПИТОНЬЕЙ "НЕНУЖНОЙ СКРИПТУХЕ" ВТРОЕ

третий вариант

#!/usr/bin/python

import sys, random, time, array
s0 = ''.join(map(chr, range(97,123)))

r100, r20, r80 = range(100), range(20), range(80)

t0 = time.time()
stable = [''.join(s0[int(random.random()*26)] for j in r100) for i in xrange(100000)]
t1 = time.time()
print 'generate strings', t1-t0

htable = {}
for I in xrange(len(stable)):
    s = stable[I]
    for k in r80: htable.setdefault(s[k:k+3], array.array('L')).append(I&(k<<24))
t2 = time.time()
print 'generate hash', t2-t1, len(htable)

matches = 0
for i in range(1000):
    s =  ''.join(s0[int(random.random()*26)] for k in r20)
    for Ioff in htable.get(s[:3], []):
        off = Ioff>>24
        matches += s==stable[Ioff&0xffffff][off:off+20]
t3 = time.time()
print 'search time', t3-t2
print 'total time', t3-t0

print 'matches', matches

на процессоре аналогичном Вашему (чуть медленней, Intel(R) Core(TM) i7-7800X CPU @ 3.50GHz):

$ ./bench3.py 
generate strings 1.60451602936
generate hash 3.33608698845 17576
search time 0.122756004333
total time 5.06335902214
matches 0
$ pypy ./bench3.py 
generate strings 0.392395973206
generate hash 1.08700585365 17576
search time 0.0150151252747
total time 1.49441695213
matches 0

вот тут, с array, pypy выстрелил!

А как лучше всего забенчмаркать объем памяти? Я написал маленький скрипт, который парсит вывод ps во время работы программы, может есть лучше способ?

Итак, результаты через ps:

Реализация metaprog на момент выхода имела RSS 2359428кб, но у него 10 итераций и судя по всему память после каждой итерации не очищается. Потребление памяти вырастает после каждой итерации.

Прямая сишная реализация - 13236кб, потребление почти не росло за время выполнения (в этой реализации тоже 10 итераций).

Антоновская реализация на C++ на хешах - 148096кб

Антоновская реализация на питоне через python2 - 744432кб

Антоновская реализация на питоне через pypy - 495192кб

Реализации на метапроге, C и C++ я еще прогнал через валгринд, результат практически такой же. С питонами валгринд работает как-то непонятно, видать у питона аллокация работает как-то особо.

ОТЛИЧНО

~/tmp/mp » python2 test-anton-optimized.py                                                                     
generate strings 1.61826086044
generate hash 3.18939113617 17576
search time 0.129806995392
total time 4.937458992
matches 0

~/tmp/mp » pypy test-anton-optimized.py                                                                        
generate strings 0.3619120121
generate hash 0.793593168259 17576
search time 0.0114970207214
total time 1.16700220108
matches 0

И по памяти стало гораздо лучше, реализация на pypy съела всего 177708кб

Ну ок ;)

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

Итого - метапрог жрет памяти в ПЯТЬ раз больше чем чем питон и работает ВТРОЕ медленнее. Про плюсы и говорить не приходится…

Интересно что нынче будет делать ТС?;-)

Интересно что нынче будет делать ТС?;-)

Начнёт читать книгу по алгоритмам, что прокачать свой уровень? :)

Звучит как анекдот