пятница, 30 декабря 2016 г.

В чем разница между CACHE HIT и BYTE HIT

Мои маленькие мохнатые друзья, поскольку меня уже сугубо задолбало объяснять, в чем заключаются различия между CACHE HIT и BYTE HIT применительно к различным системам кэширования - язык до крови стер и на пальцах кровавые мозоли - пришла пора на пальцах объяснить между ними разницу и раз и навсегда закрыть эту тему.

CACHE HIT

Данный показатель является значимым в следующих случаях:
  1. Размер кэшируемых объектов (единиц кэширования) одинаков или очень близок. Пример: страницы оперативной памяти, кластеры файловой системы, блоки базы данных.
  2. Размер кэшируемых объектов не имеет значения с точки зрения конкретной подсистемы и конкретного показателя эффективности этой системы.  Пример: Кэш DNS.
Фактическая расчетная формула для показателя:

(Количество единиц кэширования, давших HIT/Общее количество запрошенных единиц кэширования)*100

BYTE HIT

Данный показатель значим в одной и только одной ситуации:
  1. Размер кэшируемых объектов значительно отличается (на порядок и более). Пример: Прямой или реверсивный кэш веб-контента.
Фактическая расчетная формула для показателя:

(Объем единиц кэширования в байтах, давших HIT/ Общий объем запрошенных единиц кэширования)*100

Примеры и выводы

Конкретные пример на пальцах. 

У вас есть 10 файлов по 1 Кб. CACHE HIT равен 90%. Это значит, что вы кэшировали 9 Кб, а для 1 Кб зафиксирован промах. Это означает, что эффективность кэширования в точности равна 90%. Для этого же случая - если BYTE HIT равен 90%, это означает, что 9 Кб попали в кэш и дали HIT, а 1 KB - нет. Очевидно, что в данном конкретном случае показатели CACHE HIT и BYTE HIT идентичны. То есть, если размер единиц кэширование идентичен, показатели совпадают и в применении показателя BYTE HIT нет смысла.

Обратный пример.

У вас есть 9 файлов по 1 Кб, и 1 файл 1 Гб. CACHE HIT равен 90%, при этом закэшированы файлы 1 Кб, а файл 1 Гб - нет. Что это означает? Это означает, что фактическая эффективность вашего кэша - нет, не 90% - а менее 1%. 9 Кб вы взяли из кэша, а 1 Гб - нет. В этом же примере, если BYTE HIT равен 99%, то есть файл 1 Гб дал HIT, а 9 файлов по 1 Кб дали MISS, то эффективность превосходна, несмотря на то, что CACHE HIT в этом случае будет 10%. Таким образом, чем больше разброс величин единиц кэширования, тем больше вероятность того, что корреляция между CACHE HIT и BYTE HIT будет в большей степени стремиться в разные стороны.

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

Что следует из вышесказанного?

Из вышесказанного следует, что, в случае, скажем, кэширующего прокси, CACHE HIT как таковой, ничего общего с эффективностью работы не имеет. От слова "совсем". И единственным показателем в этом случае является только BYTE HIT. Поскольку чем он выше, тем меньше данных мы запрашиваем из интернета (по объему) и тем больше получаем их из кэша.

Q.E.D.

вторник, 27 декабря 2016 г.

15 признаков того, что вы - гнуторас

1. Вы знаете основные отличия свободных и частично свободных лицензий друг от друга. Вы понимаете, чем отличается MIT от BSD, и обе они от GPL. O GPLv3 вы мало что знаете, кроме того, что она частично рестриктивная, а EULA для вас совершенно темный лес- вы никогда ее не читали дальше преамбулы, но она - порожденье Сатаны Гейтса. :)

2. Вы всегда требуете исходники программы, хотя не понимаете на С, или, тем более, на С++, ни-че-го. Передаю по буквам - Николай-Иван-Харитон-Ульяна-Яков, ни-че-го. (Вы знаете, чем отличается мьютекс от мутанта и оба от спинлока? Правильно, я тоже не знаю :)) Зачем вам  тогда исходники? А хер его знает, швободка опять же, ну и пальцы погнуть перед окошечниками есть чем. :) Понимать код, а, тем более, читать перед сборкой совершенно не обязательно - правда же? - в него другие 10 миллионов мух глаз смотрят, может, хотя бы они фигу не видят и спасут человечество от дятла. :)

3. Ваш первый вопрос потерпевшему собрату - "Какую версию Линукс ты используешь и как ставишь софт из репов". (вариация для седого гнутораса 50+ - "Кто устанавливал тебе Линукс?" Операционные системы, не являющиеся Линукс, для вас не существуют - это чистой воды некрофилия и образцовое "ненужно", которое уже сдохло, "закопайте обратно".

4. Вы знаете, что означает RMS и вам пофигу, что оно жрет бородавку с ноги - оно бох. :)

5. Вам известно, что такое "палец Линуса животворящий", какой палец, кому и по какому поводу был показан. Вас не смущает полное отсутствие воспитания оного Линуса и смысл жеста - предельно похабный. Причем истинный смысл жеста вам не слишком известен.

6. Вы знаете, что означает "Ленарт Поттеринг" и вы знаете, почему он отличается от "Гарри Поттера". :) Фраза "Вышла версия 235 systemd" вызывает в вас праведный гнев, хотя лично вы не написали ничего, кроме программы на паскале для диплома в институте и пары простеньких скриптов на Bash в компании "Рога-и-Копыта-Инкорпорейтед", в которой работали после.

7. Кстати, о Bash. Вас охватывает священный гнев при словах "маловразумительная простыня на Bash", а при необходимости писать подобное - вас охватывает смесь ужаса, стыда и праведного гнева - "Я выше этого!" и "В 2016м не пишут на Баше!". Помимо того, что вы просто не были в состоянии освоить скриптинг на мало-мальски сносном уровне. А сейчас вы готовы скорей взять мельничный жернов типа Perl, лишь бы только не писать на шелле. Хоть на С - но Баш - не наш метод! По той же причине вы готовы скорей стать геем, чем использовать sysv init. Вы даже готовы наступить себе на глотку и использовать п.6, но не писать на шелле. Ни-ког-да.

8. Кстати, о скриптах. Хотя недоязыки программирования Perl, и Pyton - одинаково находятся за гранью добра и зла, вы миритесь с монструозностью Perl и готовы заживо спалить питонятников, пишущих то, что называете "поганая бидонятина". По мнению нормальных админов, интерпретируемые языки, требующие объектных библиотек для мало-мальски внятного функционала не имеют права на жизнь, но вы же - не нормальные админы, а на локалхосте эти языки та-акие уютненькие! :) Кстати, чтоб два раза не вставать - Lua тоже за гранью добра и зла - на нем пишут окошечники.

9. Вы знаете, что такое www.opennet.ru. Хотя этот местечковый междусобойчик тоже находится за гранью добра и зла, вы хотя бы раз в месяц его посещаете под тем предлогом, что "там можно узнать о новой версии гнутого софта или услышать об уязвимости раньше, чем придет рассылка". :) На самом деле вам просто нравиться читать срачи сектантов в каментах, а иногда и участвовать в перепалке местных анальных клоунов. Анонимно, разумеется.

10. Если случайно вам все же потребуется написать что-либо на С или С++, вы бежите на stackoverflov.com, задаете там панический вопрос, который местные гуру - которые уже давно не программируют, но кого это волнует? - сразу помечают как уже заданный овер 10 лет назад,
затем местные аборигены дают вам дюжину ответов, один из которых отсылает вас к древнему коду на С, два рекомендуют использовать Boost (для всего на свете, это такая омнибиблиотека, написанная геями-инопланетянами для геев-инопланетян), а пара новообращенных школоло
советуют воспользоваться instringstream, о чем бы не был вопрос - но кого это волнует? Случайно надыбав или получив правильный ответ методом угадывания и панической компиляции, вы уволакиваете код в свой уголок и с чистой совестью присваиваете как написанный лично вами. :)


PS. Шикарнейшая иллюстрация прилагается. Посмотрите, что за вопрос был задан, как оп уточняет, что желает решение с STL, и первый же ответ - use Boost, Luke! Мне всегда было интересно - эти мудаки-гуру вообще читать умеют, блеать? Это ведь не единственный подобный вопрос и не единственный подобный ответ. Или это они и есть те самые геи-инопланетяне? :)

Ну и чтобы два раза не вставать:

Пoртрет среднего пользователя Boost:

А это сама команда разработчиков Boost:

Во главе со своим тим-лидом, разумеется:

11. Вы считаете, что STL написали геи, но сами не написали ничего и даже не зарепортили ни одного по-настоящему серьезного бага. Хотя все время собираетесь.

12. Вы считаете, что Linux имеет прямое отношение к UNIX, более того, превосходит его во всем, и не знаете, кто сказал фразу "Linux is NOT UNIX".

13. Вы снисходительно относитесь к разработчикам СПО нетрадиционной ориентации, однако мерзко хихикаете, услышав название "Pidora".

14. Все пользователей Windows вы огульно считаете недоумками, способными лишь нажимать мышкой кнопки Next-->next->next->Finish. Однако вам не приходит в башку, что последовательность, которую вы повторяете минимум еженедельно: yum install - в общем-то, от окошечной ничем не отличается по существу. Да и вы, по сути, мало чем отличаетесь от пользователя винды. ;)

15. Вы знаете, кто такой Шаттлворт, чем плоха Красная Шапка (нет, она не минет Серому Волку плохо делала, отнюдь), и считаете, что Cisco, Oracle и до кучи Google - ось зла. Хотя вам все равно очень хочется работать в одной из них, получая деньги и показывая по вечерам фигу в кармане на форумах таких, как вы, сектантов, проповедуя им, что швобода - оно, конечно, хорошо, но швободно - не значит бесплатно, а презренный металл позволяет вам оплачивать счета в ожидании наступления всеобщего Коммунизма. :)

Если вы кивнули гривой хотя бы на 10 пунктов - срочно к психиатру, вам начинает промывать мозги секта под названием GNU. Если вы отметили в себе более 12 пунктов и обращались ранее к психиатру - обращайтесь снова, пусть он вам вернет деньги!

суббота, 3 декабря 2016 г.

C++: Разбивка строки на токены с составными разделителями и сохранением токенов и разделителей в векторе

Известно множество решений данной задачи. 

Однако довольно часто разбивка строки требуется несколько в более сложном варианте. А именно, требуется использовать составные разделители (более, чем один символ или пара одинаковых символов), и требуется в последовательности токенов сохранять разделители, например, для последующей обработки с заменой в качестве placeholders ну и тому подобное.

Действительно, наиболее простое решение - использовать регулярные выражения. Обработка строк в стиле C слишком замысловата и, зачастую, не является общим решением, а частности образуют массу граничных случаев.

В этой связи библиотека регулярных выражений C++ достаточно эффективна.

Данный алгоритм является видоизменением хорошо известного опубликованного алгоритма.

Допустим, что у нас есть вот такая строка:

 Quick#1brown#2fox#3jump#4over#5lazy#6white#7rabbid  

в которой разделителем является сочетание символа # и цифр от 0 до 99.

Для решения вышеописанной задачи модифицируем алгоритм с использованием std::sregex_token_iterator, сохраняющий токены в vector:

 #include <iostream>  
 #include <vector>  
 #include <string>  
 #include <regex>  
   
 // Split string with save separators  
 std::vector<std::string> split(const std::string & s, std::string rgx_str = "\\#([\\d][\\d]?)+")  
 {  
      std::vector<std::string> elems;  
      std::regex rgx (rgx_str);  
   
      std::sregex_token_iterator iter(s.begin(), s.end(), rgx, -1);     // Get token  
      std::sregex_token_iterator iter1(s.begin(), s.end(), rgx, 0);     // Get separator  
      std::sregex_token_iterator end;  
   
      while (iter != end) {  
           elems.push_back(*iter);               // Put token  
           if (iter1 != end) {  
                elems.push_back(*iter1);     // Put separator if found  
                ++iter1;  
           }  
      ++iter;  
      }  
      return elems;  
 }  
   
 int main() {  
   std::string test_string = "Quick#1brown#2fox#3jump#4over#5lazy#6white#7rabbid";  
   std::cout << test_string << std::endl;  
   
   std::vector<std::string> tokens = split(test_string);  
   for (std::vector<std::string>::const_iterator it = tokens.begin();   
     it != tokens.end(); it++)  
       std::cout << *it << std::endl;  
 }  

Скомпилируем его и выполним:

 root @ khorne /tmp # g++ -O3 -std=c++11 -m64 -c -o split1.o split1.cc  
 root @ khorne /tmp # g++ -s -m64 -o split1 split1.o  
 root @ khorne /tmp # split1  
 Quick#1brown#2fox#3jump#4over#5lazy#6white#7rabbid  
 Quick  
 #1  
 brown  
 #2  
 fox  
 #3  
 jump  
 #4  
 over  
 #5  
 lazy  
 #6  
 white  
 #7  
 rabbid  
   

Теперь можно очень легко идентифицировать разделители и выполнить дальнейшую обработку.

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