<?xml version="1.0" encoding="UTF-8"?>

<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" >

  <channel>
    <title><![CDATA[Статьи]]></title>
    <link>https://habr.com/ru/users/drbasic/publications/articles/</link>
    <description><![CDATA[Хабр: статьи пользователя drbasic]]></description>
    <language>ru</language>
    <managingEditor>editor@habr.com</managingEditor>
    <generator>habr.com</generator>
    <pubDate>Mon, 04 May 2026 22:32:09 GMT</pubDate>
    
    
      <image>
        <link>https://habr.com/ru/</link>
        <url>https://habrastorage.org/webt/ym/el/wk/ymelwk3zy1gawz4nkejl_-ammtc.png</url>
        <title>Хабр</title>
      </image>
    

    
      
        
    
    <item>
      <title><![CDATA[Многопоточная сказка о потерянном времени]]></title>
      <guid isPermaLink="true">https://habr.com/ru/articles/318066/</guid>
      <link>https://habr.com/ru/articles/318066/?utm_campaign=318066&amp;utm_source=habrahabr&amp;utm_medium=rss</link>
      <description><![CDATA[В публикации <a href="https://habrahabr.ru/post/317588/">«Сказка о потерянном времени»</a> пользователь <a href="https://habrahabr.ru/users/crea7or/" class="user_link">crea7or</a> рассказал, как он опровергал <a href="https://ru.wikipedia.org/wiki/Гипотеза_Эйлера">Гипотезу Эйлера</a> на современном CPU.<br/>
<br/>
Мне же было интересно узнать как покажет себя GPU, и я сравнил однопоточный код с многопоточным для CPU и совсем многопоточным для GPU, с помощью архитектуры параллельных вычислений <a href="http://www.nvidia.ru/object/cuda-parallel-computing-ru.html">CUDA</a>.<br/>
 <a href="https://habr.com/ru/articles/318066/?utm_campaign=318066&amp;utm_source=habrahabr&amp;utm_medium=rss#habracut">Читать дальше &rarr;</a>]]></description>
      
      <pubDate>Wed, 21 Dec 2016 16:16:23 GMT</pubDate>
      <dc:creator><![CDATA[drBasic]]></dc:creator>
      <category><![CDATA[C++]]></category><category><![CDATA[Алгоритмы]]></category><category><![CDATA[Ненормальное программирование]]></category><category><![CDATA[Параллельное программирование]]></category>
      <category><![CDATA[с++]]></category><category><![CDATA[cuda]]></category><category><![CDATA[pgo]]></category>
    </item>
  

  

  

	
  

  

  

    
    <item>
      <title><![CDATA[Одним махом 100 миллионов убивахом. Или lock-free распределитель памяти]]></title>
      <guid isPermaLink="true">https://habr.com/ru/articles/182722/</guid>
      <link>https://habr.com/ru/articles/182722/?utm_campaign=182722&amp;utm_source=habrahabr&amp;utm_medium=rss</link>
      <description><![CDATA[<h4>Постановка задачи</h4><br/>
Один из алгоритмов, который я реализовывал, имел интересные особенности при работе с памятью:<br/>
<ul>
<li> Могло выделяться огромное количество, до десятков и сотен миллионов небольших объектов одного типа.</li>
<li>Объекты представляли собой POD- типы.<br/>
<div class="spoiler"><b class="spoiler_title">POD</b><div class="spoiler_text">A Plain Old Data Structure in C++ is an aggregate class that contains only PODS as members, has no user-defined destructor, no user-defined copy assignment operator, and no nonstatic members of pointer-to-member type.</div></div></li>
<li>Заранее было неизвестно какое количество объектов понадобится, могло так случится, что потребуется сотня, а может и сто миллионов.</li>
<li>Объекты никогда не удаляются по одному, в какой-то момент они становятся не нужны все сразу. </li>
<li>Алгоритм хорошо распараллеливается, по этому выделением объектов занимается одновременно несколько потоков, по количеству ядер процессора(ов).</li>
</ul><br/>
Использование в таких условиях стандартного new – delete приводит к очень большим потерям времени на удаление объектов. Если без отладчика удаление происходило хотя бы за несколько секунд, то в присутствии отладчика освобождение памяти замедляется примерно в 100(!) раз, и отладка проекта становится просто невозможной. Кроме того из-за большого количества выделенных объектов достаточно ощутимым становился перерасход памяти на внутренние данные распределителя памяти.<br/>
Для решения задачи выделения огромного количества объектов одного типа, и их пакетного удаления, был сделан lock-free контейнер MassAllocator. Код компилируется Visual Studio 2012. Полный код проекта выложен на <a href="https://github.com/drbasic/MassAllocator">github</a>.<br/>
 <a href="https://habr.com/ru/articles/182722/?utm_campaign=182722&amp;utm_source=habrahabr&amp;utm_medium=rss#habracut">Читать дальше &rarr;</a>]]></description>
      
      <pubDate>Mon, 10 Jun 2013 05:41:06 GMT</pubDate>
      <dc:creator><![CDATA[drBasic]]></dc:creator>
      <category><![CDATA[C++]]></category><category><![CDATA[Параллельное программирование]]></category><category><![CDATA[Программирование]]></category>
      <category><![CDATA[c++11]]></category><category><![CDATA[lock-free]]></category><category><![CDATA[atomic]]></category><category><![CDATA[threads]]></category>
    </item>
  

  

  

	
  

  

  

    
    <item>
      <title><![CDATA[Динамические Linq-запросы или приручаем деревья выражений]]></title>
      <guid isPermaLink="true">https://habr.com/ru/articles/181065/</guid>
      <link>https://habr.com/ru/articles/181065/?utm_campaign=181065&amp;utm_source=habrahabr&amp;utm_medium=rss</link>
      <description><![CDATA[<h4>Введение</h4><br/>
Linq to Entity позволяет очень выразительно со статической проверкой типов писать сложные запросы. Но иногда надо нужно сделать запросы чуть динамичнее. Например, добавить сортировку, когда имя колонки задано строкой.<br/>
Т.е. написать что то вроде:<br/>
<pre><code class="cs">var query = from customer in context.Customers
    select customer;
//ошибка! не компилируется.
query = query.OrderBy(&quot;name&quot;);
var data = query.ToList();
</code></pre><br/>
На помощь в этом случае придет динамическое построение деревьев выражений (expression trees). Правда одних выражений будет недостаточно, потребуется динамически находить и конструировать шаблонные методы. Но и это не так сложно. Подробности ниже.<br/>
 <a href="https://habr.com/ru/articles/181065/?utm_campaign=181065&amp;utm_source=habrahabr&amp;utm_medium=rss#habracut">Читать дальше &rarr;</a>]]></description>
      
      <pubDate>Mon, 27 May 2013 08:01:25 GMT</pubDate>
      <dc:creator><![CDATA[drBasic]]></dc:creator>
      <category><![CDATA[C#]]></category><category><![CDATA[Visual Studio]]></category><category><![CDATA[Программирование]]></category>
      <category><![CDATA[c#]]></category><category><![CDATA[linq]]></category><category><![CDATA[linq to entity]]></category><category><![CDATA[expression tree]]></category><category><![CDATA[generics]]></category>
    </item>
  

  

  

	
  

  

  

    
    <item>
      <title><![CDATA[Еще один Linq для С++]]></title>
      <guid isPermaLink="true">https://habr.com/ru/articles/180859/</guid>
      <link>https://habr.com/ru/articles/180859/?utm_campaign=180859&amp;utm_source=habrahabr&amp;utm_medium=rss</link>
      <description><![CDATA[<h4>Введение</h4><br/>
После продолжительного перерыва мне пришлось вернуться к программированию на C++. После C# очень не хватало ключевого слова var и возможностей построения запросов linq. Однако как оказалось прогресс не стоит на месте и за время моего отсутствия вышла новая версия С++11, имеющая новые интересные возможности, к тому же реализованная в большинстве компиляторов. Я занимался кросс-платформенным проектом и меня интересовали компиляторы GCC для Linux, Visual Studio и mingw для мира Windows. Попытка найти linq-like библиотеку не увенчались успехом, все, что я находил, было нежизнеспособной поделкой на коленке. Смирившись, я бросил поиски, однако в апреле 2012 вышла обнадеживающая статья <a href="http://habrahabr.ru/post/142632/">LINQ to Objects на языке C++</a>, в которой описывалась библиотека, которая мне подходила. Попробовав ее в деле и разобравшись в ее устройстве, я был разочарован неэффективностью, но некоторые идеи я подчерпнул. Оставалось одно – написать такую же, только с блэк-джеком, что я и сделал <a href="https://github.com/drbasic/CppLinq">github.com/drbasic/CppLinq</a>, заодно разобравшись автоматическим выводом типа (auto) и лямбда выражениями. <br/>
<br/>
Проектировалась библиотека так, что бы с помощью fluent-синтаксиса и лямбда выражений пользователь мог построить граф преобразований. Эти графы можно копировать, достраивать, объединять, т.е. реализовать поведение максимально близкое к прообразу Linq to Objects из мира C#. Функционал библиотеки, недолго думая, я позаимствовал из C#, добавив, явный left join и full join. Важным ограничением библиотеки является перемещение по графу преобразования не копий, а указателей на элементы исходной последовательности. Это позволяет эффективно обходиться со сложными элементами коллекций, ведь теперь не происходит накладных расходов на копирование, но исходная последовательность из-за этого не должна быть «виртуальной». Т.е. к началу работы у каждого элемента исходной последовательности должен быть уникальный адрес и элементы не должны перемещаться в памяти во время работы linq-преобразований. В общем, для этого подходят массивы, контейнеры Qt, все стандартные контейнеры, кроме std::bitset. Сложности возникли лишь с константными последовательностями, которые так и не доделал, так как мне они были не особо нужны. Библиотека проверена и успешно компилируется Visual Studio 2010 и 2012, gcc 4.8, mingw 4.8. Проще всего совладать оказалось с компилятором Microsoft, сделать счастливыми gcc было куда сложнее, причем с внутренней ошибкой бывало падали все компиляторы, порой даже без вразумительных криков. <br/>
 <a href="https://habr.com/ru/articles/180859/?utm_campaign=180859&amp;utm_source=habrahabr&amp;utm_medium=rss#habracut">Читать дальше &rarr;</a>]]></description>
      
      <pubDate>Sat, 25 May 2013 03:58:33 GMT</pubDate>
      <dc:creator><![CDATA[drBasic]]></dc:creator>
      <category><![CDATA[C++]]></category><category><![CDATA[Visual Studio]]></category><category><![CDATA[Программирование]]></category>
      <category><![CDATA[c++11 linq]]></category>
    </item>
  

  

  

	
  

  

  

      

      

      

    
  </channel>
</rss>
