Category: компьютеры

Category was added automatically. Read all entries about "компьютеры".

animated

Retina-хуина

Enterprise-сайты точатся под 1280x600px. На 600 БЛЯДЬ ПИКСЕЛЕЙ ПО ВЫСОТЕ. Потому что у большинства менеджеров - казенные ноуты, в которых по высоте сука блять столько же пикселей, сколько на моем первом CTR-мониторе Samsung SyncMaster во времена pentium-1 (а именно - 768 строчечек). И хром с виндой еще сверху-снизу свои палки рисует.

Я несколько лет назад заебался себе 14" ноут искать из-за этого. Какого блядь хуя они до сих пор ставят в настоящие компьютеры, матрицы разрешением меньше чем на самом засраном китайском смартфоне-то?
animated

Многопоточность и прочее

Я вот реально не понимаю этой всей суеты вокруг concurency. Возьмем, к примеру, .net. У нас есть lock, куча всяких ManualResetEvent и ReadersWritersLock, потом delegate.BeginInvoke с тремя способами засинхронизироваться, Thread, затем Task Parallel Library, потом parallel foreach и PLINQ, а скоро еще async/await прямо в языке.

Вопрос один - нахуя?

С одной стороны решительно неясно зачем вообще вымучивать конкурентные программы. Почему не выделить весь стейт и повесить сверху на него один lock? Зачем давать васям возможность и соблазн слепить себе в веб-серверах свои базы данных с inconsistency, дедлоками и рейскондишнами? 7 из 8 ядер простаивать будут из-за того что мы там один поинтер из хеш-таблицы вынимаем? Обязательно надо кэш лочить отдельно, какую-нибудь еще хуйню отдельно и иметь геморрой непонятно за что?

С другой стороны есть места, где от concurency не убежать. Например Дима открывает таблицу с зарплатами сотрудников, уходит в отпуск, приходит, и поднимает зарплату Маше, которая успела уволиться не дождавшись.

Вот это, собственно, и есть concurency. А вся эта хуйня на lock-ах, соплях, и с пафосными статьями про страшное будущее с 16-ти ядерными процессорами - она не про concurency. Она от гадания за перформанс на кофейной гуще и маниакальной ООП-шной идеи растащить стейт по кускам и потом как-то с этим жить.

Короче идея в чем. Берем CAP-теорему. Там где нет риска partition-га, а процессоры редко разваливаются на части ровно по границам ядер, можно иметь C и A тупо с lock-ом поверх всего стейта. Если внутри lock-а отчего-то считается PI до стомилионного знака - никто не запрещает распараллелить алгоритмы внутри lock-а. Если у нас есть ввод-вывод, то мы имеем все три буквы из CAP и выбираем две. Все.

Напоследок - пример весьм распространенного кода, показывающего весь ужос происходящего:

private object lockObject = new object();

public T Get(string key) {
   lock (lockObject) { return getValue(key); }
}

public void Set(string key, T value) {
  lock (lockObject) { setValue(key, value); }
}


Код как бы говорит нам: если тебе, вась, нужно будет из моего кэша переложить элемент в другой кеш и незапомоиться, то хуй тебе, вась. Это ООП, вась.

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