Хочется менять 2 32-битных счётчика, но сохранять их в одном 64-битном числе.Как в C++ коде оформить такую штуку, чтобы это не зависело от endianness?

Это кросс-эндианно?

// счётчики
uint32_t a = 18;
uint32_t b = 77;

// упаковка
uint64_t p = ((uint64_t)a << 32) | b;

// распаковка
uint32_t aaa = p >> 32;
uint32_t bbb = p & 0xffffffff;

В принципе могу заюзать структуру

struct Value {
    uint32_t a;
    uint32_t b;
};

Тут тётя прикладывает какую-то карточку к мигающему прямоугольнику на мониторе, потом убирает карточку, смотрит на карточку и набирает какой-то пин-код на клаве. Что это такое?

https://youtu.be/vyOulC3hxfM?t=11m7s

P.S. Ох ты ёкарны бабай! Нагуглилось:

https://www.bloomberg.com/bunit/bl_step4/

https://www.youtube.com/watch?v=_juj1MIRJVE

Какие скилы прокачиваются в Teknavo у C++ девелоперов? Ну, скажем, где-то упор на структуры данных в современных базах данных, где-то на обработку сигналов, где-то на понимание современных архитектур процов. А что в Teknavo? «Низколатентные unix-демоны» - слишком общо. Много ли у них легаси-кода? Там скучно и третий этап S-образной кривой или ещё нет? Что они делают с bloomberg API? Какие данные гоняют (конкретно)?

Есть кусок шареной памяти, часть которого хочется рассматривать как массив 64-битных атомарных переменных.

Обычно я юзал GCC atomic buildins, например __sync_fetch_and_add для сложения с моей атомарной переменной. Кстати, должен ли я юзать при этом только выровненные адреса? Или MOV на платформе x86 атомарен на любых кривых адресах? По-моему не должен, ну ладно.

Так вот, такой код перестал казаться кошерным, захотелось заюзать std::atomic<uint64_t> в шареной памяти. Есть способы трактовать уже выделенный кусок памяти как последовательность нескольких таких объектов? Или надо вызвать несколько раз placelent new, чтобы отработал конструктор? На моей платформе std::atomic в конструкторе делает ничего (как я понял), стейта никакого не хранит и оверхеда по памяти ноль. Казалось бы, я могу просто скастить указатель и счастье, но на других платформах такое может рвануть не по-детски.

Как я понял, нормального кросс-платформенного решения на тему «трактовать уже выделенную память как массив std::atomic - ов для простого интегрального типа» нет. Народ говорит о каких-то полиморфных аллокаторах, которые на стадии экспериментов и вне стандарта пока.

Выскажитесь по сабжу.

Чисто интересно как они так умудрились. Просто волоёпили и бухали или злые хакеры?

Смотрю на ютубе какие-то семплы, сравнивающие 3-матричные панасоники и их 1-матричные ценовые братья от SONY. Не вижу критичной разницы. Ну например если погуглить «panasonic x920 VS», то ютуб подскажет что там VS такой же ценовой категории от SONY. Я тупой и слепой? Или 3 матрицы — это реально замануха и обман?

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

Пример: http://savepic.ru/11433254.png

Ну допустим прикручу я такую штуку на сайт, а с государством как взаимодействовать на тему дохода и налогов? Надо быть ООО?

Есть запись (entry). Она делится на условные Key и Value. Key состоит из 5 строковых полей и пары INT-овых, по каждому из которых хотелось бы выбирать Value, на которое показывает этот составной Key. Value состоит из 5 int-значений и хотелось бы выбирать всегда какое-то одно из них. Т.е. Value — это вектор INT-ов. Т.е. это база для аналитики. Т.е. быстрее всего будет column-based.

Обозначим все поля Key как Key:0, Key:1 и т.п. Все поля Value как Value:0, Value:1, Value:2 и т.п. Тогда:

Варианты запросов, которые должны летать:

вот Key:1, дайте последовательность всех Value:2 за последний день

нет Key («любое значение»), дайте последовательность всех Value:2 за последний день

вот Key:0 И Key:1, дайте последовательность Value:2 за последний день

Минимальное пожиралово диска побочными структурами данных, минимальное пожиралово ОЗУ, возможность безопасно удалить большой интервал старых данных без проседания операций записи-чтения, сжатие исторических данных желательно, транзакции не нужны никакие вообще.

Что стоит посмотреть? Yandex ClickHouse?

Снимаю HD-видос на samsung note 3, но сцена с множеством мелких деталей выглядит как мыло - например шевелящаяся трава, плескание воды и т.п. Понимаю, что они в предельный битрейт не влезают. А вот тут плескание воды передано нормально: https://www.youtube.com/watch?v=sbios0u2Px8 , но у них там бюджет не ограничен. И ютуб видимо позволяет разгуляться.

Короче, сколько надо мегабит/сек, чтобы такие плескания нормально передавались? В ручных видеокамерах предел до 28 Мбит/с, например panasonic HC-X800. Вот тут чувак снял шевеление колючего дерева камерой panasonic X920 https://youtu.be/TU04wksrBe0 , получилось норм, а предел у камеры 25...26 мбит/сек.

Короче, обсудите.

(Ахтунг! Рассматриваем только исправное оборудование, файловую систему и ядро без глюков.)

Требуется добавлять записи переменной длины (от байта до сотни МБ) в конец файла так, чтобы при любом фейле питания можно было бы надёжно отличить последнюю ошибочную запись (если такая была) от предыдущих нормальных.

Решение такое:

запись
- пример: хотим добавить 76 кб данных
- добавляем в конец файла header фиксированного размера, в который пишем hash данных + размер данных (76*1024). Можно записать hash этого header прямо перед ним самим
- вызываем fsync() — это как барьер памяти, не позволяющий переупорядочить операции записи перед ним и за ним
- дописываем наши данные (76 kb payload)
- вызываем fsync()

чтение после сбоя
1. Открываем файл сначала и последовательно проверяем: если очередной header в неадеквате (файл кончился раньше размера header (он фиксир.), hash header-a не совпало) — считаем всё пространство файла начиная с header-а далее пустым. Потеряем только 1 запись, ведь в середине ничего не переписывали.
2. если header вменяем, но в файле осталось меньше данных чем сказано в header или данных хватило, но их hash не совпал с указанным в header - пункт (1) - считаем файл пустым, начиная с начала header

Данная фигня как-бэ гарантирует, что мы можем потерять только последнюю запись и надёжно её выкинуть без утечек «дисковой памяти» и можем продолжить дописывать в файл с правильного места, не создав далее ошибок для его разбора. Обсудите, так ли это?

Предложите алгоритм.

Хочется добавить в файл 128MB данных, чтобы это переживало отрубание питалова в любой момент с такими последствиями: либо я вижу консистентные 128MB добавленных данных, либо я вижу некий кусок мусора с консистентным заголовком, из которого ясно какого точно размера мусор.

«добавить в файл» не означает строго то, что файл надо открыть в режиме O_APPEND и буквально добавить. Файл на пару гигов можно выделить заранее и манипулировать какими-то страницами в нём.

Т.е. хочется чего-то типа double-buffer, когда сначала куча страниц пишется в специальную временную область файла, потом вызывается fsync(), а потом они пишутся в нормальное место. Если в процессе записи в нормальное место рубанут питалово, то процесс находит во временном буфере то, что недописалось в «нормальное место» и пишет это туда. Ну в общем, интересуют всякие такие истории, не буквально этот подход.

Вся эта тема предполагает некоторые атомарные операции с файлом (сектор HDD, меньше которого нельзя записать; или даже несколько дорог в черепичной записи, меньше которых черепичный HDD не умеет записывать). Скажем, если размер атомарной записи = 512 байт, то нужно ещё и выравнивать - нельзя с позиции 12 записать 512 байт, ведь такая запист будет физически из 2 кусков - 512 + 512 — первый для 500, второй для 12.

Короче, куда копать?

Почитаем вражеских сайтов.

http://en.cppreference.com/w/cpp/atomic/memory_order

If an atomic store in thread A is tagged memory_order_release and an atomic load in thread B from the same variable is tagged memory_order_acquire, all memory writes (non-atomic and relaxed atomic) that happened-before the atomic store from the point of view of thread A, become visible side-effects in thread B...

Перевод примерно такой: если атомарная запись в потоке A сделана с флагом «memory_order_release» и атомарное чтение в потоке B из той же переменой сделано с флагом «memory_order_acquire», то любая запись в память перед вышеуказанной атомарной записью будет видна потоку B.

Как-то тупо звучит. Даже без атомарности, барьеров памяти и т.п. поток B увидит в памяти всё, что нафигачил поток А. Правда в неопределённом порядке. Но тут про порядок ничего сказано и не было.

Во-вторых зря они написали «same variable». Барьеры памяти разве следят за тем КУДА пишут и ОТКУДА читают? Они вроде просто препятствуют переходу через себя ЛЮБЫХ операций некого типа (напр. записи или чтения), неважно с какой именно переменной идёт работа - с той же или не с той же.

Конечно там дальше написано

...that is, once the atomic load is completed, thread B is guaranteed to see everything thread A wrote to memory.

Сайт писали тормоза?

Есть кусок шареной памяти (128MB), куда часто ломятся разные процессы-читатели и читают случайные куски по 1-32 КБ. Есть один процесс «Master», которому раз в 10 сек надо обновить целиком 128 MB так, чтобы никакой читатель не прочитал полкилобайта фигни.

Решение: т.к. любой процесс-читатель могут убить админы в любой момент, глупо рассчитывать на то, что процесс обязательно добровольно отпустит некий мьютекс, размещённый в этой шареной памяти.

Предлагается такая фигня:

В шареной памяти есть атомарные INT-переменные: fence, num, lasttime.

fence:    если 1, значит закрыто для читателей
num:      число читателей, копошащихся сейчас
lasttime: время успешного захода последнего читателя

1. На входе читатель с помощью CAS пытается заинкрементить num, если было открыто (0 == fence).

2. Отметившись в num, читатель атомарно пишет текущее микросекундное время (CLOCK_MONOTONIC) в lasttime, если там лежит меньшее (СAS-ом). Если там лежит время <= текущего, то читатель ничего не делает.

3. Читатель с помощью CAS на выходе декрементит num обратно.

4. Если Master хочет сделать своё дело, он ставит fence = 1, затем бесконечно ждёт num == 0. Если в этом ожидании он замечает, что lasttime устарел на секунду от текущего времени, то Master считает что кто-то из читателей подох посреди пути и делает своё дело вероломно, записывая num = 0 и затем открывая fence = 0.

Взлетит? Может есть чё попроще? Есть решение, при котором всё это не нужно, но это уже другая тема. Интересуют заморочи. Т.е. допустим, авто-отпускающийся мьютекс нужен.

https://jekyllrb.com/docs/templates/

Всю жизнь подсветка кода в Markdown была через ``` code ```.

Тут идёт речь о каком-то левом

{% highlight ruby %}
def foo
  puts 'foo'
end
{% endhighlight %}

``` тупо не работает. Причём работает ~~~ code ~~~ - откуда это вообще? И почему оно даёт результаты, отличные от {% highlight %}? Короче, почему нет единого стандарта, какой хелп считать центральным? Как заставить работать ``` ?

Вопрос звучал так: почему в этом коде течёт память. Может троллили и она не течёт, но когда я ответил, они радостно приняли ответ, показав что его и ждали и поехали дальше.

T() исключений не кидает, память внутри не выделяет.
f() память внутри не выделяет, возвращает int, но может кинуть исключение.

std::shared_ptr<T> t(new T( f() ) );

Короче, я стал сомневаться в том, что собеседующий был вменяем. Течёт скорее всего у него где-то в другом месте.

В JS вызвать 2 функции по 4 аргумента - дешевле, чем вызвать 1 с 8 теми же аргументами? Ну допустим в V8.

Просто когда ты в Питере получаешь от московского яндекса предложение приехать, то к желаемой ЗП накидываешь аренду (которую тут не надо оплачивать, например) и некую цифру около 40-50 тыров, плюсом к текущей ЗП, ради которого (плюса) стоило бы всё бросать и мотать в нерезиновск. Получается почти 200К. Они столько не платят, я правильно понимаю? )

Есть чё? Запускаю кривой JS-скрипт на iPad в Chrome и в Safari. Скрипт падает, но хочется посмотреть консоль. Причём не ту консоль, которую я пишу через console.log(), а со всеми эксцепшенами и красными-жёлтыми надписями. Поэтому всякие онлай-сервисы, перехватывающие console.log() - не круто.

Есть 1000 задач, которые повторяются с переменным интервалом. Когда очередная выполняется, то следующий раз она выполнится, ей придумывается следущее время исполнения через рандомное время, например rand()%0xfff миллисекунд.

Реализовано так: есть heap (std::vector + pop_heap, push_heap). Число задач в долгосрочном периоде постоянно, поэтому ресайз вектора крайне редок.

Засыпаю до времени, которое имеет задача на вершине хипа. Просыпаюсь и делаю некоторое число задач, которые имеют текущее время (или меньше). Выполняя каждую задачу, делаю её pop из хипа, придумываю ей новое время выполнения и сразу push её в heap. Когда на вершине оказывается задача с временем «не сейчас», то засыпаю до этого времени.

Что я делаю с точки зрения производительности хуже, чем можно было бы?

WARNING!!! Пост больше не имеет смысла. Гипотеза со слов «похоже на то» оказалось бредом окаянным. Оставим для истории.

Когда вкладка неактивна или окно браузера свёрнуто, вкладка переходит в режим лени и тунеядства. Троттлинг. Вставляет много sleep() в поток выполнения JS кода (FPS падает до 7 с 60).

Но эффект странный получается. Вот кусок моего быдлокода.

Вначале где-то на старте скрипта создаётся и долго живёт вебсокетный сокет «sock». Далее в коде периодически дёргается send_packet_x() для отправки 4-байтового WebSocket пакета бинарного. Обычно всё это работает.

Но когда вкладка свёрнута, начинается пока не совсем изведанное странное. Похоже на то, что вместо посылки 1 пакета с 4 байтами, присылаются 2 пакета - в одном 1 байт, в другом оставшиеся 3. Я так понимаю, вебсокет имеет право бить поток вебсокет-дейтаграммы как ему вздумается, даже если они мелкие?

//
// WebSocket socket.
//
var sock = new WebSocket(some_address);
sock.binaryType = 'arraybuffer';

...


function send_packet_x() {
    var b = new ArrayBuffer( 1 + 2 + 1);
    var dv = new DataView(b);
		
    var off = 0;

    dv.setUint8(off, 11, true); off += 1;
    dv.setUint16(off, 2222, true); off += 2;
    dv.setUint8(off, 11, true); off += 1;

    //
    // SEND
    //
    sock.send(b);
}

UPDATE Я тупое животнае, ошибка была в сервере, а JS отправляет всё нормально.