Здравствуйте, alex_public, Вы писали:
_>Ты про это http://parabix.costar.sfu.ca/wiki/ParabixTransform? Хм, любопытный подход. Хотя программировать потом такое конечно очень извратно. Но если кто-то всё же найдёт силы и напишет что-то (тот же парсер), то потом должен быть очень приятный результат.
Я так понял, что "потом" уже наступило:
У меня есть парсер на SSE3 (тот же подход, что в Parabix), который даёт что-то около 2Гб парсинга в секунду на одном CPU.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Хыхы, промышленный парсер JSON? Хм... ))) Вообще то на том же boost.spirit'e полноценный парсер json записывается в несколько строк (собственно грамматика) и при этом не уверен, что есть "профессиональные" специализированные json парсеры, которые обойдут такое решение по скорости. )))
Целое стадо разных людей до падежа скота пилит джсон парсеры, но похоже, посоны просто не разобрались в кунфу boost.spirit. Эх, измельчали сиплюсники, измельчали.
P.S. boost.spirit == парсер-комбинаторы. Его область применения это простые грамматики, которые всерьез обработаны вручную. Фактически, recursive descent только без единой оптимизации. Ну, ты понял
Здравствуйте, alex_public, Вы писали:
_>Моя мысль была в том, что json парсер — это достаточно простая вещь, чтобы без проблем реализовывать её без всяких бутылочных горлышек.
Что-то не верю я в это смелое утверждение. Интуитивно кажется, что ваши представления о том, как в три строки реализовать парсер JSON дадут во-первых — некорректную, а во-вторых — неоптимальную реализацию. Про SSE3 уже откомментировали.
Про то, что до сих пор неясно, как обрабатывать одноименные атрибуты, уже тоже откомментировали. Вот ваш мегапарсер на спирите, он что будет делать в таком случае? И почему вы думаете, что это — правильное решение?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
_>>Ты про это http://parabix.costar.sfu.ca/wiki/ParabixTransform? Хм, любопытный подход. Хотя программировать потом такое конечно очень извратно. Но если кто-то всё же найдёт силы и напишет что-то (тот же парсер), то потом должен быть очень приятный результат. S>Я так понял, что "потом" уже наступило: S>
S>У меня есть парсер на SSE3 (тот же подход, что в Parabix), который даёт что-то около 2Гб парсинга в секунду на одном CPU.
Ну на сайте того же Parabix есть упоминание только о реализации grep в качестве примера их технологии. Понятно, что json парсер даже проще, так что задача вполне выполнима. Но и её кто-то должен сделать, что совсем не тривиально с учётом особенностей данного подхода. Так что подождём ответа Cyberax'а с деталями.
Здравствуйте, alex_public, Вы писали:
_>Моя мысль была в том, что json парсер — это достаточно простая вещь, чтобы без проблем реализовывать её без всяких бутылочных горлышек.
Если бы написал хотябы несколько нетривиальных парсеров, то знал бы, что даже простой (на первый взгляд) парсер может быть очень сложным реализации. Более того, самые быстрые парсеры оказываются на практике самыми сложными. Так что "без проблем реализовать" и "без бутылочных горлышек" зачастую взаимоисключающие вещи.
вот пример парсера JSON с нуля на F# http://fsharpforfunandprofit.com/posts/understanding-parser-combinators/ 4 статьи и куча зубодробительного кода, просто чтобы сделать парсер (и понять как сделать) на комбинаторах, который по сути самый медленный из всех возможных.
Аналогичный код на C++ будет по объему в 2-3 раза больше. Я для проверки делал решение Problem K на C++ и на F#, разница в объеме кода примерно в 3 раза.
Здравствуйте, Sinclair, Вы писали:
_>>Моя мысль была в том, что json парсер — это достаточно простая вещь, чтобы без проблем реализовывать её без всяких бутылочных горлышек. S>Что-то не верю я в это смелое утверждение. Интуитивно кажется, что ваши представления о том, как в три строки реализовать парсер JSON дадут во-первых — некорректную, а во-вторых — неоптимальную реализацию. Про SSE3 уже откомментировали.
Про использование SIMD для текстовых парсеров я действительно был не в курсе, признаю. Правда я вот очень сомневаюсь, что данная хитрая технология применяется в каком-то из так называемых "промышленных" парсеров json. ) Максимум там применяется что-то вроде пропусков пробелов с помощью SIMD, но это даже близко не имеет отношения к описываемой технологии битовых потоков и не даёт каких-то ощутимых эффектов.
Здравствуйте, gandjustas, Вы писали:
_>>Моя мысль была в том, что json парсер — это достаточно простая вещь, чтобы без проблем реализовывать её без всяких бутылочных горлышек. G>Если бы написал хотябы несколько нетривиальных парсеров, то знал бы, что даже простой (на первый взгляд) парсер может быть очень сложным реализации. Более того, самые быстрые парсеры оказываются на практике самыми сложными. Так что "без проблем реализовать" и "без бутылочных горлышек" зачастую взаимоисключающие вещи.
CSV подходит под нетривиальный парсер? ) А JSON подходит? )
G>вот пример парсера JSON с нуля на F# http://fsharpforfunandprofit.com/posts/understanding-parser-combinators/ 4 статьи и куча зубодробительного кода, просто чтобы сделать парсер (и понять как сделать) на комбинаторах, который по сути самый медленный из всех возможных. G>Аналогичный код на C++ будет по объему в 2-3 раза больше. Я для проверки делал решение Problem K на C++ и на F#, разница в объеме кода примерно в 3 раза.
А зачем писать парсер с нуля?) Естественно надо пользоваться удобными инструментами. О чём и было сказано в моём первом сообщение.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>Моя мысль была в том, что json парсер — это достаточно простая вещь, чтобы без проблем реализовывать её без всяких бутылочных горлышек. G>>Если бы написал хотябы несколько нетривиальных парсеров, то знал бы, что даже простой (на первый взгляд) парсер может быть очень сложным реализации. Более того, самые быстрые парсеры оказываются на практике самыми сложными. Так что "без проблем реализовать" и "без бутылочных горлышек" зачастую взаимоисключающие вещи.
_>CSV подходит под нетривиальный парсер? ) А JSON подходит? )
CSV на несколько порядков проще, так как CSV описывается регулярной грамматикой. JSON в этом плане почти также сложен, как XML.
G>>вот пример парсера JSON с нуля на F# http://fsharpforfunandprofit.com/posts/understanding-parser-combinators/ 4 статьи и куча зубодробительного кода, просто чтобы сделать парсер (и понять как сделать) на комбинаторах, который по сути самый медленный из всех возможных. G>>Аналогичный код на C++ будет по объему в 2-3 раза больше. Я для проверки делал решение Problem K на C++ и на F#, разница в объеме кода примерно в 3 раза. _>А зачем писать парсер с нуля?) Естественно надо пользоваться удобными инструментами. О чём и было сказано в моём первом сообщение.
Написание парсера с нуля полезно как упражнение на понимание проблем и их решений. Если не понимаешь этих проблем, то вряд ли сделаешь парсер с приемлемой производительностью.
Задача парсинга — одна из немногих, которая "в лоб" не решается. Максимум что может написать человек без предварительной подготовки — простой парсер рекурсивного спуска, который довольно слаб или сильно тормозит.
Здравствуйте, Sinclair, Вы писали:
S>Что-то не верю я в это смелое утверждение. Интуитивно кажется, что ваши представления о том, как в три строки реализовать парсер JSON дадут во-первых — некорректную, а во-вторых — неоптимальную реализацию. Про SSE3 уже откомментировали.
Это, кстати, не так. JSON настолько простой, что наивная реализация на каком-нибудь генераторе парсеров вполне может быть верной с первого раза.
Причём, будет работать со скоростью, вполне достаточной для подавляющего большинства практических применений. Для XML такое себе представить трудно — до сих пор в крупных парсерах ошибки находят.
В нашем случае экстремальный парсер делался для кода, который с помощью DPDK коммутирует JSON-сообщения на паре 10Гб сетевых интерфейсов. Причём он особо не нужен оказался, и без него можно было бы обойтись, но хотелось позаниматься спортивным программированием для разнообразия.
S>Про то, что до сих пор неясно, как обрабатывать одноименные атрибуты, уже тоже откомментировали. Вот ваш мегапарсер на спирите, он что будет делать в таком случае? И почему вы думаете, что это — правильное решение?
Одноимённые атрибуты запрещены. Кидать исключение в этом случае надо.
Здравствуйте, alex_public, Вы писали: _>Ну на сайте того же Parabix есть упоминание только о реализации grep в качестве примера их технологии. Понятно, что json парсер даже проще, так что задача вполне выполнима. Но и её кто-то должен сделать, что совсем не тривиально с учётом особенностей данного подхода. Так что подождём ответа Cyberax'а с деталями.
Несколько лет назад на этом форуме пробегала ссылка на парсер XML на основе данной технологии. Не думаю, что JSON парсер принципиально сложнее.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Про использование SIMD для текстовых парсеров я действительно был не в курсе, признаю. Правда я вот очень сомневаюсь, что данная хитрая технология применяется в каком-то из так называемых "промышленных" парсеров json.
Пока — нет. Но те, кто выбирает "три строки на спирите" для таких вещей, гарантированно отрезают себя от передовых достижений.
Весь смысл опоры на 3rd-party — в том, что там пацаны специализируются на своей работе, и пока мы пилим наше супер-приложение, они улучшают парсер независимо от нас.
И ключ к такой международной кооперации как раз во внятной спеке, на которую мы можем полагаться.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
DO>>Видимо их задолбал xml. Все-таки xml читать и править руками неудобно, он больше для автоматической обработки. Не, конечно есть всякие тулзы, типа XMLnotepad, но и они задалбывают. Если нужно что-то быстро добавить, удобнее файлик открыть в far'e. DA>а в чём проблема редактирвоания XML в FARе?
В том, что XML — это в общем случае бинарь, а не текстовик. И иногда эта кажущаяся текстовость формата сильно бьёт в лоб любителям "подправить тут по-бырику английский на русский" и т.п.
Здравствуйте, gandjustas, Вы писали:
_>>CSV подходит под нетривиальный парсер? ) А JSON подходит? ) G>CSV на несколько порядков проще, так как CSV описывается регулярной грамматикой. JSON в этом плане почти также сложен, как XML.
JSON почти также сложен, как XML?
_>>А зачем писать парсер с нуля?) Естественно надо пользоваться удобными инструментами. О чём и было сказано в моём первом сообщение. G>Написание парсера с нуля полезно как упражнение на понимание проблем и их решений. Если не понимаешь этих проблем, то вряд ли сделаешь парсер с приемлемой производительностью.
В качестве обучения конечно же полезно. Но мы тут вроде бы совсем другое обсуждаем...
G>Задача парсинга — одна из немногих, которая "в лоб" не решается. Максимум что может написать человек без предварительной подготовки — простой парсер рекурсивного спуска, который довольно слаб или сильно тормозит.
Здравствуйте, Mr.Delphist, Вы писали:
DO>>>Видимо их задолбал xml. Все-таки xml читать и править руками неудобно, он больше для автоматической обработки. Не, конечно есть всякие тулзы, типа XMLnotepad, но и они задалбывают. Если нужно что-то быстро добавить, удобнее файлик открыть в far'e. DA>>а в чём проблема редактирвоания XML в FARе?
MD>В том, что XML — это в общем случае бинарь, а не текстовик. И иногда эта кажущаяся текстовость формата сильно бьёт в лоб любителям "подправить тут по-бырику английский на русский" и т.п.
Тогда и код на C/Delphi/LISP/etc. — бинарь, а не текстовик.
Здравствуйте, Sinclair, Вы писали:
_>>Про использование SIMD для текстовых парсеров я действительно был не в курсе, признаю. Правда я вот очень сомневаюсь, что данная хитрая технология применяется в каком-то из так называемых "промышленных" парсеров json. S>Пока — нет. Но те, кто выбирает "три строки на спирите" для таких вещей, гарантированно отрезают себя от передовых достижений. S>Весь смысл опоры на 3rd-party — в том, что там пацаны специализируются на своей работе, и пока мы пилим наше супер-приложение, они улучшают парсер независимо от нас.
Думаю что в подавляющем большинстве обсуждаемых тут случаев (посмотри о чём была речь выше), возможностей парсера на базе спирита более чем хватит.
Однако если мне потребуется работа с JSON в моём проекте, я не побегу делать парсер на спирите, а возьму готовую библиотечку. Но совсем не потому что такой парсер медленный или некорректный. А потому что кроме парсера для работы с JSON понадобится ещё и соответствующая иерархия классов с перегрузками нужных операторов (это ещё более тривиально чем парсер, но ещё более лениво делать самому) и преобразование обратно в строку (ещё более тривиально, но опять же лень). Так что готовое интегрированное решение (кстати внутри оно может быть на чём угодно, включая и spirit) очевидно удобнее. А спирит скорее подходит для более редких форматов, для которых нет удобных готовых библиотек.
Ну а про "несколько строк на спирите" я упомянул в качестве оценки сложности парсера JSON и сомнительности выражения "промышленные парсеры json". )))
S>И ключ к такой международной кооперации как раз во внятной спеке, на которую мы можем полагаться.
Это о чём вообще речь? ) Об api библиотек? Так он же у каждой библиотеки свой...
Здравствуйте, netch80, Вы писали:
N>В старых применениях оно может жить ещё хоть вечно, за компанию к упоминавшемуся тут, не к ночи будь сказано, X12, но если ты мне покажешь хоть один пример новой технологии (а не расширения/дополнения существующих), где применён ASN.1, за последние 15 лет, я буду удивлён. По-моему, последним героическим движением в эту сторону было H.323.
Открывай любую спецификацию LTE и вот он ASN.1 для всего. Вряд ли там где нужен будет в будущем бинарный и стандартизированный формат передачи данных возьмут что-то другое.
Откройте этот файлик в FAR и замените "something" на "что-то" и сохраните изменения. Теперь попробуйте распарсить этот якобы Xml любым десериализатором. Скорее всего, получите ошибку типа "Invalid character in the given encoding. Line 2, position 14".
Здравствуйте, Kernan, Вы писали:
N>>В старых применениях оно может жить ещё хоть вечно, за компанию к упоминавшемуся тут, не к ночи будь сказано, X12, но если ты мне покажешь хоть один пример новой технологии (а не расширения/дополнения существующих), где применён ASN.1, за последние 15 лет, я буду удивлён. По-моему, последним героическим движением в эту сторону было H.323. K>Открывай любую спецификацию LTE и вот он ASN.1 для всего.
LTE это логически такое же продление GSM, H.323 и прочего ISO'шного голоса, даже если переведено на IP. Поэтому я считаю его расширением существующего, а не новым.
K> Вряд ли там где нужен будет в будущем бинарный и стандартизированный формат передачи данных возьмут что-то другое.
Да вот берут, постоянно. Предпочитают изобретать собственные стандарты (bencode, protocol buffers и тому подобное), gzip-овать XML и JSON, лишь бы к ASN.1 не приближаться. Мне это тоже немного непонятно, чисто практические наблюдения.
N>Да вот берут, постоянно. Предпочитают изобретать собственные стандарты (bencode, protocol buffers и тому подобное), gzip-овать XML и JSON, лишь бы к ASN.1 не приближаться. Мне это тоже немного непонятно, чисто практические наблюдения.
Емнип, ASN.1 сложен для реализации, и в мире существует практически только полтора парсера, поддерживающих его хоть в каком-либо полном объеме. Из известных мне — asn1c и ASN.1 в Эрланге. При том, что и тот и другой используются прямо-таки в промышленных масштабах, и то в обоих автор asn1c недавно нашел баг.
