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

[wizzard0]

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

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

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

Comments

[nponeccop]

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

[wizzard0]

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

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

[nponeccop]

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

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

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

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

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

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

[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]

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

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

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