The first application was parsing 110 GB of log data spread over 11,000 text files in over 300 directories and importing it into a SQL database. The whole application is 90 lines long (including comments!) and finished the task of parsing the source files and importing the data in under 18 hours; that works out to a staggering 10,000 log lines processed per second! Note that I have not optimised the code at all but written the application in the most obvious way. I was truly astonished as I had planned at least a week of work for both coding and running the application
The second application was an analysis of millions feedbacks. We had developed the model equations and I literally just typed them in as an F# program; together with the reading-data-from-SQL-database and writing-results-to-MATLAB-data-file the F# source code is 100 lines long (including comments). Again, I was astonished by the running time; the whole processing of the millions of data items takes 10 minutes on a standard desktop machine. My C# reference application (from some earlier tasks) is almost 1,000 lines long and is no faster. The whole job from developing the model equations to having first real world data results took 2 days.
These are my first impressions but based on them and the things I learned along the way I would like to encourage each of you to give F# a serious try (and, if you get stuck then do not hesitate to ask James Margetson; he truly is an F# evangelist and will be glad to help you out). One of the extensions developed by Don and James is the interactive mode of F#; it gives you a MATLAB-like command prompt where you can execute single-line commands right away without any need to compile source or create solutions (its called F# Interactive, or FSI for short). Combine this with a full integration into Visual Studio 2005 (including Intellisense) and you can get started with F# without reading a 100 page manual! I could go on listing more and more reasons why you should consider F# (e.g., built-in infinite-precision arithmetic, built-in matrix type, accessibility of all .NET libraries, etc.) but if you are interested, just drop by my office and I am happy to give you a demonstration (and hopefully convince you).
Только вот недопонял, когда говорят о прелестях F# это они OCaml хвалят?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Превратим окружающую нас среду в воскресенье.
Re: F# for games and machine learning: .NET + performance +
Здравствуйте, ie, Вы писали:
ie>The first application was parsing 110 GB of log data spread over 11,000 text files in over 300 directories and importing it into a SQL database. The whole application is 90 lines long (including comments!) and finished the task of parsing the source files and importing the data in under 18 hours; that works out to a staggering 10,000 log lines processed per second!
При таких объёмах основная работа уйдёт на загрузку распаршенных данных в SQL. Сам парсинг там даже в микроскоп нельзя будет различить.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: F# for games and machine learning: .NET + performance
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, ie, Вы писали: ie>>The first application was parsing 110 GB of log .........
IT>При таких объёмах основная работа уйдёт на загрузку распаршенных данных в SQL. Сам парсинг там даже в микроскоп нельзя будет различить.
Собственно тут и никто не спорит:
The performance of the first application derives largely from that of the .NET database libraries
Просто подмечают, что приложение в первом случае получилось довольно компактное.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[3]: F# for games and machine learning: .NET + performance
ie wrote:
> Собственно тут и никто не спорит: > The performance of the first application derives largely from that of > the .NET database libraries > Просто подмечают, что приложение в первом случае получилось довольно > компактное.
Имхо на том же перле получилось бы не хуже, а скорее всего ещё компактнее с его суперрегекспами, что для логов — самое то.
Одна строка под регексп, пара строк — INSERT, да обвязка с построчным чтением, да подключение к БД. Может строк десять...
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: F# for games and machine learning: .NET + performance
Здравствуйте, kan_izh, Вы писали:
_>Имхо на том же перле получилось бы не хуже, а скорее всего ещё компактнее с его суперрегекспами, что для логов — самое то. _>Одна строка под регексп, пара строк — INSERT, да обвязка с построчным чтением, да подключение к БД. Может строк десять...
Тут остается только догадываться, сам код не приводится. Да и сравнение идет с C#, где такое приложение имело бы порядка 1000 строк.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
Превратим окружающую нас среду в воскресенье.
Re[4]: F# for games and machine learning: .NET + performance
Здравствуйте, kan_izh, Вы писали:
_>Одна строка под регексп, пара строк — INSERT, да обвязка с построчным чтением, да подключение к БД. Может строк десять...
Если ты сделаешь INSERT, то 110 гиг ты будешь парсить до пенсии.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: F# for games and machine learning: .NET + performance
IT wrote: > _>Одна строка под регексп, пара строк — INSERT, да обвязка с построчным > чтением, да подключение к БД. Может строк десять... > Если ты сделаешь INSERT, то 110 гиг ты будешь парсить до пенсии.
Если перед INSERT'ами отключить индексы — вполне нормально. На 20Гб
вставок лично проверял
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[5]: F# for games and machine learning: .NET + performance
Здравствуйте, ie, Вы писали:
ie>Тут остается только догадываться, сам код не приводится. Да и сравнение идет с C#, где такое приложение имело бы порядка 1000 строк.
Занимался я когда-то подобной фигней. 1000 строк — это универсальный парсер с UI с рабочим потоком и описанием схемы входных файлов в XML. Хотя, верю, если сильно захотеть, то можно и в 2к строк не уложиться. В общем, без исходного кода тут разговаривать вообще не о чем.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[6]: F# for games and machine learning: .NET + performance
Здравствуйте, Cyberax, Вы писали:
>> Если ты сделаешь INSERT, то 110 гиг ты будешь парсить до пенсии. C>Если перед INSERT'ами отключить индексы — вполне нормально. На 20Гб вставок лично проверял
20Гб чего? И какой у тебя сервер был и сколько времени это заняло?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: F# for games and machine learning: .NET + performance
IT wrote: >> > Если ты сделаешь INSERT, то 110 гиг ты будешь парсить до пенсии. > C>Если перед INSERT'ами отключить индексы — вполне нормально. На 20Гб > вставок лично проверял > 20Гб чего? И какой у тебя сервер был и сколько времени это заняло?
20Гб почтовых сообщений в крэш-тесте своего хранилища почты. Сервер —
FireBird Embedded, заняло времени около 20 минут.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[5]: F# for games and machine learning: .NET + performance
IT wrote:
> _>Одна строка под регексп, пара строк — INSERT, да обвязка с построчным > чтением, да подключение к БД. Может строк десять... > Если ты сделаешь INSERT, то 110 гиг ты будешь парсить до пенсии.
Не понял. Перл, J#, .net — тут ни при чём. Здесь уже проблемы БД, решаемые БД-зависимо — отключить индексы, использовать
режим bulk insert, вообще индексы грохнуть. А как кроме insert ещё можно данные в базу добавлять?
В общем возражение мимо кассы.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: F# for games and machine learning: .NET + performance
Здравствуйте, kan_izh, Вы писали:
>> _>Одна строка под регексп, пара строк — INSERT, да обвязка с построчным >> чтением, да подключение к БД. Может строк десять... >> Если ты сделаешь INSERT, то 110 гиг ты будешь парсить до пенсии. _>Не понял. Перл, J#, .net — тут ни при чём. Здесь уже проблемы БД, решаемые БД-зависимо — отключить индексы, использовать _>режим bulk insert, вообще индексы грохнуть. А как кроме insert ещё можно данные в базу добавлять? _>В общем возражение мимо кассы.
Выделенное как-то не очень стыкуется, не находишь? В две строки BULK INSERT не получится.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: F# for games and machine learning: .NET + performance
Здравствуйте, Cyberax, Вы писали:
>> 20Гб чего? И какой у тебя сервер был и сколько времени это заняло? C>20Гб почтовых сообщений в крэш-тесте своего хранилища почты. Сервер — FireBird Embedded, заняло времени около 20 минут.
А общее количество сообщений? Неужели несколько десятков миллионов?
Если нам не помогут, то мы тоже никого не пощадим.
Re[7]: F# for games and machine learning: .NET + performance
IT wrote: > Выделенное как-то не очень стыкуется, не находишь? В две строки BULK > INSERT не получится.
Спорим? Для MySQL, например, очень даже получится. Ну не в две, а в пять
точно влезет.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[9]: F# for games and machine learning: .NET + performance
IT wrote: >> > 20Гб чего? И какой у тебя сервер был и сколько времени это заняло? > C>20Гб почтовых сообщений в крэш-тесте своего хранилища почты. Сервер — > FireBird Embedded, заняло времени около 20 минут. > А общее количество сообщений? Неужели несколько десятков миллионов?
Около 5 миллионов.
Я для себя рассчитывал верхний предел в 1 миллион сообщений (больше
сложно представить зачем нужно, разве что RSDN сохранить локально), на
одном миллионе вообще все быстро и непринужденно работает.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[7]: F# for games and machine learning: .NET + performance
IT wrote:
>> > _>Одна строка под регексп, *пара строк — INSERT*, да обвязка с > построчным >> > чтением, да подключение к БД. Может строк десять... >> > Если ты сделаешь INSERT, то 110 гиг ты будешь парсить до пенсии. > _>Не понял. Перл, J#, .net — тут ни при чём. Здесь уже проблемы БД, > решаемые БД-зависимо — отключить индексы, использовать > _>режим *bulk insert*, вообще индексы грохнуть. А как кроме insert ещё > можно данные в базу добавлять? > _>В общем возражение мимо кассы. > > Выделенное как-то не очень стыкуется, не находишь? В две строки BULK > INSERT не получится.
Ещё раз. Попытайся понять что я говорю. Это database-specific!!! Например, в mysql достаточно вместо "INSERT INTO
Log(a,b,c) VALUES(?,?,?)" написать "INSERT DELAYED INTO Log(a,b,c) VALUES(?,?,?)" и он будет кэшить данные в память, не
пиша индексы на диск.
Это не зависит от языка программирования! Из любого языка программирования ты должен будешь вызвать те же операции базы
данных. И, скорее всего, займёт это одинаковое число строк.
В сабже обсуждается преимущество F# перед C# для парсинга логов, а не тонкости работы баз данных с пакетной вставкой.
Да, использовать F# круто, согласен. Но для парсинга логов, имхо, лучше всего подойдёт перл, т.к. он для этого
фактически и разрабатывался, так что скорее всего программа получится ещё компактнее.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[8]: F# for games and machine learning: .NET + performance
Здравствуйте, Cyberax, Вы писали:
>> Выделенное как-то не очень стыкуется, не находишь? В две строки BULK INSERT не получится. C>Спорим? Для MySQL, например, очень даже получится. Ну не в две, а в пять точно влезет.
Ты уже проспорил
Если нам не помогут, то мы тоже никого не пощадим.
Re[10]: F# for games and machine learning: .NET + performanc
Здравствуйте, Cyberax, Вы писали:
>> А общее количество сообщений? Неужели несколько десятков миллионов? C>Около 5 миллионов.
20kkk / 5kk = 4k
Охотно верю. При таком размере записи с 20Gb проблем быть не должно. Только чувак в статье упоминает 110 гиг, 18 часов и 10,000 записей в секунду. Т.е. 648,000,000 записей размером в 170 байт. Если он не врёт, то это очень хороший результат и мне хотелось бы посмотреть подробнее как он это делает и на каком оборудовании. Не на F#, конечно, посмотреть, от него как я уже сказал мало что зависит.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: F# for games and machine learning: .NET + performance
Здравствуйте, kan_izh, Вы писали:
_>Ещё раз. Попытайся понять что я говорю.
Я пытаюсь Но попридираться ведь надо
_>Это database-specific!!!
Какой бы это ни был специфик, а record by record будет работать в десятки раз медленнее bulk insert. Хоть кешируй, хоть не кешируй.
_>Это не зависит от языка программирования! Из любого языка программирования ты должен будешь вызвать те же операции базы данных. И, скорее всего, займёт это одинаковое число строк.
Но не две
_>В сабже обсуждается преимущество F# перед C# для парсинга логов, а не тонкости работы баз данных с пакетной вставкой.
Только цифры, которые там приводятся имеют смысл только в контексте тонкостей работы баз данных, что делает обсуждение преимуществ F# перед C# бессмысленным.
_>Да, использовать F# круто, согласен. Но для парсинга логов, имхо, лучше всего подойдёт перл, т.к. он для этого фактически и разрабатывался, так что скорее всего программа получится ещё компактнее.
Спорить не буду. Без примеров кода тут вообще не о чем спорить.
Если нам не помогут, то мы тоже никого не пощадим.
Re[11]: F# for games and machine learning: .NET + performanc
Здравствуйте, IT, Вы писали:
IT>Охотно верю. При таком размере записи с 20Gb проблем быть не должно. Только чувак в статье упоминает 110 гиг, 18 часов и 10,000 записей в секунду. Т.е. 648,000,000 записей размером в 170 байт. Если он не врёт, то это очень хороший результат и мне хотелось бы посмотреть подробнее как он это делает и на каком оборудовании.
Ключевой момент в том, что 110Gb исходных логов. Он не сказал, сколько оттуда реально данных идет в БД.
Я переодически такими задачами занимаюсь, так из одной строки лога в базу идет максимум 40% от общего объема строки. Все остальное -- это различное оформление информации в логе и не относящаяся к делу информация. К тому же он сказал об обработке 10K строк лога в секунду. Не факт, что одна строка лога -- одна запись в БД.
Совсем недавний пример. На Ruby парсился лог, формировался файл с извлеченными данными, этот файл скармливался утилите psql (из PostgreSQL) через команду copy ... from stdin (для эффективной массовой вставки данных в БД). На файле в 50Mb (~270K строк) Ruby скрипт отрабатывал за 25-30 секунд (в выходной файл помещалось порядка 130K строк) и за такое же время отрабатывала psql. Если же Ruby скрипт только читал лог (без записи выходного файла и запуска psql), то весь парсинг занимал секунд 13-15. Все это на ноутбуке с не очень быстрым винтом. Причем, если исходный лог-файл имел размер 50Mb, то выходной файл, который попадал в psql -- всего 10Mb. Все остальное -- это синтаксический мусор лога, или описания других типов событий.
Так что интересно не только, сколько было исходных логов, но и сколько реально данных писалось в БД.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Если нам не помогут, то мы тоже никого не пощадим.
Ты уже проспорил 
