пятница, сентября 23, 2011

Логирование в С++. Сравнительный мини-обзор

Вполне стандартная задача(логирование) имеет слишком много инструментов для решения в C++. В том плане что ярко выраженного лидера нет(ну если не считать за лидера "свой велосипед"). Пришлось мне ковыряться. Дело усугубилось тем что среди c++ девелоперов очень много людей считающих что подробная документация не нужна (кому надо - в исходник заглянут).

После поверхностного поиска я выделил следующее:
log4j клоны для c++ - log4cxx , log4cpp , log4cplus;
Pantheios;
boost-log;
google-glog.

Попробовав log4cxx  я заподозрил плохое увидев что по сути в проекте не было изменений с 2004 года. Увидев незакрытые баги связанные с многопоточностью(что для меня критично), я на него забил и решил пока не трогать другие log4j клоны (судя по датам релизов живой только log4cplus и если вам хочется во чтобы-то ни стало использовать клон log4j то наверное стоит обратить внимание именно на него).

Далее идут не клоны log4j, так что стандартная схема log4j включая все плюсы и минусы в них отсутствует. Это не значит что они слабее функционально (хотя некоторые объективно нацелены на простоту), они просто другие.

Pantheios выглядит отлично в плане документации/описаний, по отзывам вроде у всех работает без проблем. Я почти остановился на нём, но решил уж посмотреть оставшиеся альтернативы.

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

Наконец очередь дошла до google-glog. И тут я понял что это то что мне нужно. Очень мощный и одновременно простой функционал. DLOG (ну и DCHECK и тд) например позволяет выкинуть мысли о том во что выльется слишком подробное логирование в плане производительности - как только вы скомпиляете релиз-версию все DLOG вызовы превратятся в тыкву просто исчезнут. Но у glog есть и минусы. Например встроенной ротации логов нет. Документация очень куцая, часто приходится заглядывать в исходники (особенно в http://code.google.com/p/google-glog/source/browse/trunk/src/logging.cc ) для поиска настроек (например для максимального размера логфайла).

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

Достоен внимания и Pantheios особенно если вам импонирует его архитектура.

понедельник, сентября 05, 2011

Ubuntu One vs Dropbox на ubuntu server

Есть у убунты Ubuntu One - очередная sync/share тулза на облаке. Имея несколько безголовых(для тех кто не в курсе - сервер без монитора,клавы и мыши) убунту серверов и необходимость синхронизировать некоторые некритичные несекретные(достаточно несекретные чтобы использовать сторонний сервис для синхронизации) данные не только между ними но и наружу(в том числе на не *nix системы) решил я попробовать Ubuntu One. Но оказалось что из консоли это можно сделать только с помощью жутких хаков (например, да и то там в комментах пишут что уже не работает). Вобщем удивительное рядом - продукт компании не работающий на другом продукте компании.

В итоге пришлось использовать dropbox. Вот тут например написано как это сделать: http://ubuntuservergui.com/ubuntu-server-guide/install-dropbox-ubuntu-server.

P.S. Впрочем если погуглить то становится понятно что и на десктопе убунты большинство выбирают dropbox.

среда, августа 24, 2011

Параллелим на многоядерный кластер. C/C++ или Java.

Этот пост не даст ответа на чём лучше писать программы работающие на кластере многоядерных машин, но даст немного информации к размышлению.

Любой кто начнет искать "как бы написать что-нибудь для кластера" наткнётся на аббревиатуру MPI. И наверняка наткнется на аббревиатуру OpenMP когда речь зайдёт о программировании для многоядерных систем.

Когда заходит речь о таких сложных системах желание снизить влияние программистких ошибок на систему(ну или снизить порог уровня годных для этой задачи программистов) вполне имеет право на жизнь. Понятно что если вы сражаетесь за каждый такт процессора на каждом ядре - то у вас нет альтернативы C/C++ библиотекам MPI/OpenMP и команде сильных программистов с крепкой нервной системой. Если же копейки процессорного времени вас не очень волнуют и сильной команды C/C++ спецов нет, то можете взглянуть на Java с её библиотеками-аналогами (MPJ Express и какой-то субъективно сомнительный на вид JOMP). Но будьте готовы что для совсем простых задач "копейки" выльются в двукратное отставание как например тут.

Что лучше "в среднем по больнице" сложно сказать. Явовские либы определённо имеют некоторые баги со стабильностью на некоторых системах (можете погуглить - вроде на солярке точно были проблемы у mpj), но в целом есть примеры работающие в продакшне, так что ничего критичного нет. На плюсах же наверняка у малоопытных несильных программистов будут большие проблемы одной из которой будет нахождение собственно проблемного кода. Но это мое субъективное мнение.

Да, если у вас нету кластера, но есть относительно мощный компьютер вы можете запустить пару виртуалок и сделать кластер из них. Например если соберетесь под виндой запустить пару(ну или больше если система и здравый смысл позволяют) линуксов, то вот это поможет вам настроить сеть между двумя виртуалками: много букоф на английском. Лично у меня этот вариант с парой убунту серверов и небольшой MPI программой на C++ сработал на ура.

P.S. На всякий случай: если вы пишете что-то распределённое это вовсе не значит что вам необходим MPI. Но если у вас получается велосипед который повторяет функционал MPI - это повод задуматься.

среда, марта 02, 2011

Всё меняется

Помнится давным-давно, году так в 2000-2001 читал я предсказания Билла Гейтса(если память не изменяет то в компьютерре) о том как всё будет с компьютерами очень скоро. Говорил он о том что почти весь десктопный софт будет скоро(вроде бы он говорил о 10-15 годах) переориентирован на тонких клиентов. И ведь многие смеялись тогда...

Так о чём я. Если бы мне в 2000 году сказали бы что когда мне понадобится быстренько визуализировать некоторые сложные данные для внутреннего редкого использования, то в 2011 я возьму js-библиотеку и быстренько напишу на java генератор html для отрисовки нужных графиков с использованием этой js библиотеки - я бы повертел пальцем у виска.

С одной стороны я конечно давно уже далёк от десктопных приложений и такое решение мне показалось оптимальным в том плане, что на совсем уж незнакомые грабли наступать не придётся. Ну и js либа уж больно красиво рисует. Года 4 назад я бы наверное налабал скрипт на perl с графической либой какой-нибудь (правда вышло бы уродливо, но наверняка ещё быстрее). В 2000 году мне даже мысль об использовании js для отрисовки не пришла бы в голову.

Библиотека для рисования графиков выбралась сама по себе - я вспомнил что недавно Сироткин искал такую, и тупо позаимствовал у него первую попавшуюся ссылку: http://highcharts.com/.

На всё про всё у меня ушло несколько часов (там порядочно данных надо было обработать хитро прежде чем рисовать, ну и всё guice'фицировать и минимум unit-тестов сделать на случай если вдруг придётся потом в этом что-то менять) и в итоге нарисовалось всё очень наглядно и так красиво что аж жалко стало что это для внутреннего использования.

Что будет через 10 лет сложно представить. Наверняка появится ещё пара концептуально других опций для решения этой задачи.