[must-read repost] Обманчиво простая задачка или немного про системное программирование

[wizzard0]

Если вы претендуете на то, чтобы быть называться программистом, это надо обязательно прочитать. Ну то есть много кто про это знает, но много кто, увы, нет.

Я в свое время славно походил по этим граблям, и у других их видел в количестве.

Оригинал взят у zamotivator в Обманчиво простая задачка или немного про системное программированиеВыношу из своего поста и

Comments

[nponeccop]

Единственное* нормальное решение - это евент-луп библиотека с промисами или чем-то получше (reactive properties, reactive event streams, ...) Остальное - годится и "оно же работает"™, но в-общем, ёбаный стыд в соответствии с тезисом "sleep никогда не бывает разумным".

select и poll вообще следует считать лигаси апи и фейспалмом - есть нормальные механизмы давно, и следует использовать именно их. К сожалению, их нормальность заканчивается на производительности, т.е. ни epoll, ни kqueue, ни IOCP неюзабельны без обвязки, поэтому обвязка должна делаться один раз специально обученными людьми, а не под дедлайнами.

Блокирующие вызовы - день старому однопоточному миру. Годятся, если фейспалм находится на нижнем уровне и описан в RFC. Но в новом нелигаси-коде наступать на старые грабли и проектировать SMTP, а потом через год на него навешивать PIPELINING, когда станет ясно что лишняя синхронизация была ошибкой молодости - это педерастия.

Потокодрочерам советую написать нормальный (с т.з. отсутствия избыточной синхронизации) вариант с двумя потоками на каждой стороне, одним читающим и одним пишущим, и поебаться с синхронизацией этого дела. В отличие от случая прошлого абзаца, где этого можно избежать ценой избыточной синхронизации, возникает mutable state shared between threads, что конечно пустяки, но только до первой серьёзной проблемы с неатомарными апдейтами или если код разукрашивать критическими секциями "на всякий случай" и снова создавать избыточную синхронизацию, но на другом уровне.

Имхо три самых больших проблемы современности - это избыточная синхронизация, использование лигаси средств и подходов в новом коде** и буферы недостаточного размера.

Подытоживая, есть евенты в высокоуровневой обвязке, есть потоки без shared state, всё остальное для школьников и квик фиксов в 3 часа ночи.

* потоки с (высокоуровневой обвязкой вокруг) message passing - тоже кул

** mission critical - это отдельная песня

[wizzard0]

> буферы недостаточного размера.
тут мы начинаем вспоминать про C10K и прочее веселое.

ну, точнее, даже C1K становится интересным вопросом, если линк к серверу 10GE и надо не висеть холостым коннектом а очень даже хуячить

[nponeccop]

Наиболее печально, как мне кажется, в области юзер интерфейса и обычных аппов и сайтов. О хай-теке беспокоиться не надо, он сам справится.

Ассумпшены 10-летней давности о соотношении производительности разных компонентов системы не соответствуют действительности.

IO и CPU внезапно столько, хоть обожрись, а количество приложений, которые в состоянии их утилизировать - нулевое. Всё пишется, как будто у нас 1980-е на дворе, я хуею, дорогая редакция.

Какой-нибудь файловый серч в фаре запустить - плакать хочется. Я заранее знал что там говно, но сейчас специально посмотрел

http://farmanager.googlecode.com/svn/trunk/unicode_far/findfile.cpp

// Открываем файл

if(!file.Open(Name, FILE_READ_DATA, FILE_SHARE_READ|FILE_SHARE_WRITE, nullptr, OPEN_EXISTING, FILE_FLAG_SEQUENTIAL_SCAN))
{
return false;
}
...

// Основной цикл чтения из файла
while (!StopEvent.Signaled()
&& file.Read(readBufferA, (!SearchInFirst || alreadyRead + readBufferSize <= SearchInFirst)
? readBufferSize
: static_cast(SearchInFirst - alreadyRead), readBlockSize))

И это всё вызывается из однопоточного и синхронного же FindFiles::DoScanTree, первый класс вторая четверть, турбо паскаль под дос, чтение 1.44" на 286.

И такое везде, везде блядь.

[wizzard0]

ну да, поэтому фар выбрасываем нахуй и юзаем Everything, который отсканивает мои 8 млн файлов за 15 секунд и потом ищет за <30ms

[nponeccop]

The interesting part of this example is that it's broken on so many levels

[wizzard0]

Maybe.

[vp]

На обычном жестком диске? какая-то магия? :)

[wizzard0]

try it ;-)

[vp]

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

У вас ССД или обычный диск?

[wizzard0]

Не, не, не, не полнотекстовый. По именам. 15 сек занимает вычитать в память структуры NTFS.

[vp]

Тьфу, у вас просто выше по тексту коммент с примером из фара - он меня сбил с толку, что речь о полнотекстовом поиске. Думаю, что за магия такая.

[wizzard0]

А, блин, в натуре сверху полнотекстовый.

Теперь я понял, о чем говорил nponeccop когда говорил что "wrong in so many ways" %)

Ыыы.

[vp]

я у него спросил в жж то же самое - он меня забанил заскринил. Не знаете, за что? :)

http://nponeccop.livejournal.com/368146.html

[nponeccop]

http://en.wikipedia.org/wiki/Native_Command_Queuing например

http://dtrace.org/blogs/brendan/2011/05/11/file-system-latency-part-1/

и т.п.

[vp]

Это все хорошо, но я думал, что вы именно о многопоточности. Вот потому и спросилось.

"...IO и CPU внезапно столько, хоть обожрись, а количество приложений, которые в состоянии их утилизировать - нулевое....Какой-нибудь файловый серч в фаре запустить - плакать хочется. Я заранее знал что там говно, но сейчас специально посмотрел"

Я естественным образом подумал, что вы о многопоточном поиске в файлах на одном диске в одной папке. Но раз вы о то, что Фар не использует возможности SATA - тогда прошу прощения. Действительно, это никуда не годится :)

[nponeccop]

Да я обо всём сразу. В ЦПУ тоже упретесь, при поиске регуляркой в гигабайтном файле, при чтении с ССД и т.п.

Помимо этого есть простаивание конвейера во время системных вызовов, которое при многопоточности размазывается по ядрам и т.д.

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