студент и основоположник (басня в прозе)

[juan_gandhi]

Широко известна в народе так называемая бигтейбл, внедрённая в дискурс гуглом. Что за бигтейбл такой? Это пакеты данных, индексированные ключом; ключ - строка неограниченной длины. Пакет не обязательно читать-писать целиком, он состоит из групп колонок, так что целиком читается-пишется только группа; группа состоит из колонок. В каждой ячеечке (ключ + колонка) хранится какое-то данное; можно по желанию хранить и историю, т.к. к данному приложена отметка времени; юзер сам выбирает, хранить последнюю или всё что есть.

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

Одно неудобство - всё это на си, и работает через арписи. Сишникам раздолье, у них есть соответствующие классы; а джавщики страдали. Наконец выдающийся основоположник Ф.Е. осчастливил население, написав джавный интерфейс; программист судьбу благословил.

В это время в Сингапуре учился студент Маниш, родом из индийской деревни. В Сингапуре учёба, как в СССР, халявная, только потом надо три года отработать как молодому специалисту. А работа в Сингапуре одна: в банке потеть над банковским софтвером.

Но есть же Гугл; и вот Маниш посылает своё резюме, чтоб приехать практикантом.

В Гугле с практикантами порядок такой: все эти левые резюме сваливаются в базу; их там десятки тысяч; желающие инженера копаются в этой базе и иной раз лениво выдёргивают какой-нибудь пёрл (всё та же Пирамида Лебедева), и отправляют на доследование, т.е. в кадры. Кадры организуют телефонные интервью, ну и т.д. Обычно на этом и кончается: спросишь у будущего практиканта, может ли он запрограммировать Фибоначчи на каком-либо языке, он и вянет. Маниш не отвял, а браво ответил на все вопросы и осенью явился в Маунтин Вью.

Как это осенью? А так: кроме летней, бывает ещё зимняя практика, на два семестра. Ну там сначала-то он записался на один семестр, но вскоре это переиграл. Да и то; зарплаты в гугле практикантам плотят больше иной раз, чем инженерам в стартапах в Пало Альто. Так что у меня завёлся весёлый умный практикант. Быстренько освоил язык питон, а также гугловский стиль джавы.

А нам как раз об это время шибко надоел майсиквел, на котором вся трансляция держится. Надо было бы, конечно, просто добавив серверов, но кто же даст компьютер (один!) на такое пустяковое дело как перевод сотни с лишним проектов на сотню с лишним языков! Растрата одна... этак на кофейную машину ценой в 11 штук денег не останется.

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

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

И что Маниш? А Маниш обнаруживает такую простую вещь: если у нас таблица разбита на 20 таблеток, и вся информация, где какие ключи, известна, то почему бы нам в 20 threadов не читать эту самую таблицу, со всех таблеток параллельно. И пишет Маниш такую параллельную читалку.

Дело в том, что это особенность джавы - лёгкость, с которой ты пишешь multithread code. В си сдохнуть можно такое написать.

Ну и, после непродолжительного вылизывания стиля и рисования грамотных юниттестов, сабмитит он это дело; я аплодирую. Теперь следующий этап, впарить этот код Выдающемуся Основоположнику.

Пишем ченджлист, посылаем ему на ревью.

Тишина. Две недели - ни слова.

Пишем Вежливое Письмо.

Тишина. Две недели, тишина.

Пишем ещё письмо. В ответ нам сообщают, что а) надо ещё разобраться; б) есть недоработки; в) мы сами над аналогичным вопросом думаем.

И так мы провели оставшиеся полгода. Пока Маниш не уехал обратно в Сингапур.

Потом я ещё три месяца надоедал основоположнику. Потом я пошел в другую команду. В той, предыдущей, все эксперименты с бигтейблом выкинули на помойку. Включая, очевидно, и код Маниша.

Так что воз и ныне там.

А Маниш нормально; полученной в Гугле зарплатой он расчитался с Сингапуром и поехал в Цюрихское отделение Гугла, на постоянку. И ныне там; катается на лыжах, сделал себе модную татуировку. Думаю, у него всё хорошо.

Но Гугл так и не умеет читать бигтейблы параллельно.

Comments

[illy-drinker.livejournal.com]

Вы про многопоточность?
ДУмаете библиотеки заменяют родную поддержку в языке (со всей оптимизацией и пр)?

[sab123.livejournal.com]

А что там можно особо оптимизировать? Вот разве что стек сделать в виде списка.

[illy-drinker.livejournal.com]

так в Яве сообществе они этим занимаются с 90х
лок стратегии или общение процессора с локальными кешами на многоядерных архитектурах

[sab123.livejournal.com]

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

[illy-drinker.livejournal.com]

Лок стратегии везде одинаковы. Р

Я помню ИБМ много работала над локами в вирт машине и они писали, что достаточно сильно повышают перформанс

Я ни в коей мере не являюсь специалистом по Яве и не знаю, что сейчас в этом мире делают лучшие вирт машины и компиляторы, просто видел несколько публикаций типа в Др добссе или форумах, где утверждалось, что простые программы с многопоточностью лучше скейлятся на многоядерных архитектурах

[illy-drinker.livejournal.com]

в смысле простые явовские программы лучше масштаб их аналогов на С++


вс еэто были какие-то простые примеры

[faceted-jacinth.livejournal.com]

Так ведь насколько я знаю в жаве встроенная поддержка сосёт как пылесос Вулкан. Например, замечательное слово volatile оказывается совершенно бессмысленным и бесполезным, потому что охочий до оптимизаций конпелятор может переносить через него все другие чтения и записи. То есть если вы считаете, что код

volatile bool flag;
int something = 0;
...
flag = 0;
something = 10;
sleep(1000);
if (flag)
{
   if (something == 20)
   {
       doSomething();
   }
}

гарантирует вам, что тело ифа может исполниться вообще, то вы глубоко заблуждаетесь, ололо. Это в сишарпе assignment to a volatile memory location acts as a memory barrier, preventing relocation of reads and writes from/to ANY memory locations to be cached by the compiler. А в жаве как нефиг - something не volatile, значит, можно её зачитать в регистр вначале функции и больше не трогать никогда.

[faceted-jacinth.livejournal.com]

* assignment to or a read from

[faceted-jacinth.livejournal.com]

s/to be cached/to be performed/
О чём-то не о том я думал

[illy-drinker.livejournal.com]

а ну этот конкретно пример интеракции оптимизации компилятора и многопот известен давно
Они с ним что-то сделали или все также?

[faceted-jacinth.livejournal.com]

В жаве? Не знаю, подозреваю, что нет.

В сишарпе такие майндфаки исправляются - например, была совершенно прекрасная в своей глючности вещь: finalizer объекта мог быть вызван по ходу исполнения метода этого объекта, если там дальше ни разу не использовался this. То есть если я зачитываю вендовую Handle в локальную переменную и собираюсь с ней дальше что-нибудь сделать, то где-то посередине может случиться сборка мусора, которая замечательно соберёт тот объект, в котором сейчас исполняется код (ну, раз он не обращается ни к каким полям уже, всё нужное сохранено в локальных переменных), вызывается деструктор, закрывающий хэндл, и мой метод замечательно сосёт всякое. Реальный пример: я пишу метод Close для свого файлообразного потока, ну, понятно.

То есть проблема была в том, что IntPtr, использовавшийся для ссылок на объекты оси, нифига не понимался GC как ссылка. Это исправли добавлением классов вроде SafeHandle. Исправили! А не как в жаве!

[skavish.livejournal.com]

> В жаве? Не знаю, подозреваю, что нет.

прекрасный аргумент

[illy-drinker.livejournal.com]

то что обсуждается выше - действительно неприятный баг в понимании волатайл явой

[skavish.livejournal.com]

в чем состоит баг? то о чем вы говорите исправлено лет 6 назад. не говоря уже о том что бага никогда не было, все соотвествовало спекам. просто в 1.5 решили volatile немного затянуть.

[skavish.livejournal.com]

какая то чушь, уж извините

[alexclear.livejournal.com]

Это в сишарпе assignment to a volatile memory location acts as a memory barrier, preventing relocation of reads and writes from/to ANY memory locations to be cached by the compiler.

Вот это-то как раз и есть майндфак, как и многое у M$.

[faceted-jacinth.livejournal.com]

Забавно получилось.

Оказывается, я был не прав, в пятой жаве таки сделали всё как в дотнете (там есть ещё какие-то совсем дико суровые тонкости в дотнетовской имплементации, но неважно).
http://en.wikipedia.org/wiki/Java_Memory_Model
http://www.javamex.com/tutorials/synchronization_volatile_java_5.shtml
http://java.sun.com/docs/books/jls/third_edition/html/memory.html

Но зато как весело теперь ваш комментарий выглядит!

[alexclear.livejournal.com]

Да, да, отлично, теперь это вопрос для собеседований!

И мой комментарий следует читать так:

"...как и многое у M$ и Sun".

[faceted-jacinth.livejournal.com]

Да нет же, это как раз правильный подход именно к мультитредовой синхронизации.

Слово volatile в C и C++ имело несколько другой смысл и для другого предназначалось - для прямой работы с железом, например. Ну и вот компилятор гарантирует, что каждое чтение-запись дойдёт до железа, и что относительный порядок волатильных чтений/записей будет как в коде (а все остальные чтения/записи могут прыгать как угодно вокруг, если это не меняет семантику).

Естественно, поверх такой абстракции можно и многотредовое взаимодействие сделать: тогда весь без исключения шаред стейт должен быть помечен как volatile (причём видимо любой доступ к полю волатильного поля тоже должен считаться волатильным).

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

[alexclear.livejournal.com]

Да нет же, это как раз правильный подход именно к мультитредовой синхронизации.

Я почитал первую и третью ссылку и понял (вторую ссылку я читал как-то давно, но понял совсем не то, что понял сейчас).

Слово volatile в C и C++ имело несколько другой смысл и для другого предназначалось - для прямой работы с железом, например.

К этому и претензия - почему в современной Java тоже есть "volatile", а не какое-нибудь там что-нибудь, я не знаю.
Это весьма запутывает.
На самом деле, речь ведь идет об определении блоков, связанных отношением happened-before.