Здравствуйте, WolfHound, Вы писали:

WH>Или даже так:
WH>1)Приложение графической системе: Держи поток с текстурой.
WH>2)Графическая система видеодрайверу: Держи поток с текстурой.
WH>3)Видеодрайвер графической системе: Текстура загружена.
WH>4)Графическая система приложению: Текстура загружена.
Вот примерно так попробовали сделать товарищи из Tungsten Graphics (только вместо потоков использовали асбтрактные буфферы), когда затеяли обобщённый менеджер памяти (TTM — Translation Table Map) для X-сервера. Фигня получилась. Тормозило всё из-за того, что слишком часто нужно сбрасывать кэши — так как на уровне менеджера памяти нельзя было понять откуда ноги растут у буфферов.

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

Или ещё вариант — для некоторых случаев нужно гарантированно иметь данные в памяти. То есть, к примеру, для некоторых IRQ-обработчиков нужно гарантировать, что страницы с данными будут точно готовы, а не будут лежать на диске или сервере на Марсе.

Здравствуйте, WolfHound, Вы писали:

C>>Но там опять есть проблемы — нужно байндить их в специальную область физической памяти, отображаемую на видеопамять (GART Aperture), т.е. опять течёт абстракция. А ещё память в GART весьма странно ведёт себя с кэшированием — кэши надо явно сбрасывать (командой процессора cflush), иначе видеокарта их не увидит.
WH>1)Приложение графической системе: Нужна память под текстуру.
WH>2)Графическая система видеодрайверу: Нужна память под текстуру.
WH>3)Видеодрайвер графической системе: Забирай.
WH>4)Графическая система приложению: Забирай.
WH>5)Приложение: Гружу текстуру.
WH>6)Приложение графической системе: Забирай.
Тут всё так.

WH>7)Графическая система видеодрайверу: Забирай.
WH>8)Видеодрайвер графической системе: Текстура загружена.
WH>9)Графическая система приложению: Текстура загружена.
А вот так делать уже нельзя. Команда "текстура загружена" должна сбросить кэш процессора, чтоб видеокарта увидела данные (а некэшируемая работа с памятью тормозит как рендеринг в software). А это дико дорого, нужно делать это массово. Кроме того, для чтения из текстурной области (если так захочется) нужно сбросить ещё кэш видеокарты.

А, там ещё веселуха есть. GART Aperture ограничен архитектурно на AGP 512 мегабайтами, так что если на карте более 512Мб, то используется переключение банков (...вспомним старый добрый Спектрум...). Так что у буфферов ещё будет признак "в системной памяти".

Так что стройная картинка вдруг обрастает нестройными подробностями.

C>>А если мы занимаемся HPC (который сейчас пишут на суровом C++) и нам надо минимальную латентность иметь?
WH>Ты же вроде уже согласился что оно будет как минимум не хуже чем сейчас.
Будет.

C>>Да кто же спорит-то? Но сейчас (да-да, вот прямо сейчас) в том же Линуксе это уже сделано нормально (с полным zero-copy в fastpath) и работает быстро. Но там и не пытались делать текущие абстракции.
WH>Опять 25. Куда и чего протекло?
Выравнивание страниц. Требование выравнивания надо передать на самый верхний уровень.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Тот факт, что MS начала разработку SQL FS, говорит о том, что такая задача может быть поставлена. Вряд ли они бы начали эту разработку, не продумав идею.
PD>Тот факт, что эта FS так и не появилась и теперь неясно, когда появится, говорит о том, что имеются , по-видимому, достаточно серьезные проблемы в ее реализации.
Тот факт, что появились FILESTREAMы в MS SQL, говорит о том, что проблем в реализации, собсно, нет. Нет потребности в таком ракурсе, который вначале казался актуальным.
PD>Обсуждать же вообще возможность такой FS в деталях я просто не имею никакого желания.
Это правильно. А то окажется, что современные SQL сервера вполне себе могут работать на том же уровне, что и FS.

PD>Мои замечания относились просто к утверждениям WolfHound о MySQL, который к SQL FS и вообще к какой бы то ни было FS не имеет ни малейшего отношения.
Какое трогательное неумение видеть общее за частностями.

Здравствуйте, Sinclair, Вы писали:

C>>Ладно, у меня ещё примеры есть Скажем, для графического ускорителя неплохо бы сразу уметь байндить текстуры (и прочие объекты, у нас же GPGPU и всё такое) в видеопамять.
S>Не очень понятно, что такое "сразу".
После создания, без лишних копирований.

C>>Но там опять есть проблемы — нужно байндить их в специальную область физической памяти, отображаемую на видеопамять (GART Aperture), т.е. опять течёт абстракция.
S>Гм. Это как бэ проблемы драйвера видеокарты, разве нет?
Нет. Если делать всё абстрактно, то буффер может выделить кто угодно.

S>В том смысле, что он может озаботиться выделением текстуры таким образом, что нужный виртуальный адрес отмаплен внутрь апертуры. Тогда я могу делать вещи типа file.Read(myGARTBuffer) в своём приложениии, и обходиться минимумом копирований.
А не получится...

C>>А если мы занимаемся HPC (который сейчас пишут на суровом C++) и нам надо минимальную латентность иметь?
S>А какое отношение HPC имеет к сети? Если мы обращаемся к файлухе, то за DMA-friendly выравниванием будет следить её драйвер.
Для кластеров в HPC нужны низколатентные сети.

C>>По сравнению с текущим 2*c...
S>Текущий 2*c, как я понял, мгновенно просасывает на сценариях, чуть выходящих за пределы sendfile. Для этого конкретного случая и в винде fastpath предусмотрен.
В Линуксе оно с помощью splice() работает для почти любых дескрипторов.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Мои замечания относились просто к утверждениям WolfHound о MySQL, который к SQL FS и вообще к какой бы то ни было FS не имеет ни малейшего отношения.
S>Какое трогательное неумение видеть общее за частностями.

Ну если для тебя вслед за WolfHound разница между приложением, реализующим SQL и хранение данных на его основе, и драйвером ФС, реализующим доступ к логическому диску — хоть NTFS, хоть FAT, хоть SQLFS есть лишь общее и частности — велкам в форум "Низкоуровневое программирование", объясни там всем, что разница между процессом и драйвером только в том. что драйвер работает в нулевом кольце, а MySQL есть подсистема управления дисками. Попробуй, интересно будет на реакцию тамошних жителей посмотреть.

Здравствуйте, Cyberax, Вы писали:

C>Или ещё вариант — для некоторых случаев нужно гарантированно иметь данные в памяти. То есть, к примеру, для некоторых IRQ-обработчиков нужно гарантировать, что страницы с данными будут точно готовы, а не будут лежать на диске или сервере на Марсе.

Маленький комментарий. В Windows это требование не связано с быстродействием, а является принципиальным. Если на высоких IRQL допустить подкачку страниц, то эта подкачка может вызвать прерывание, что приведет к дурной бесконечности. Поэтому при IRQL>=2 подкачка страниц запрещена.

Здравствуйте, Cyberax, Вы писали:

C>А вот так делать уже нельзя. Команда "текстура загружена" должна сбросить кэш процессора, чтоб видеокарта увидела данные (а некэшируемая работа с памятью тормозит как рендеринг в software). А это дико дорого, нужно делать это массово. Кроме того, для чтения из текстурной области (если так захочется) нужно сбросить ещё кэш видеокарты.
Кешь сбросит драйвер видюхи между пунктами 7 и 8.
А "текстура загружена" это не команда, а ответ приложению что все ОК.

C>А, там ещё веселуха есть. GART Aperture ограничен архитектурно на AGP 512 мегабайтами, так что если на карте более 512Мб, то используется переключение банков (...вспомним старый добрый Спектрум...). Так что у буфферов ещё будет признак "в системной памяти".
И чё?
Буфер выделяет драйвер по всем правилам.
Отдает приложению.
Приложение его заполняет и отдает драйверу.
При это система типов гарантирует что у приложения не останется ссылок на этот самый буфер.
Ну и где проблемы?

C>Так что стройная картинка вдруг обрастает нестройными подробностями.
В твоем воображении.

WH>>Ты же вроде уже согласился что оно будет как минимум не хуже чем сейчас.
C>Будет.
И что тогда опять споришь?

C>Выравнивание страниц. Требование выравнивания надо передать на самый верхний уровень.
Никуда оно не протекло.

Здравствуйте, WolfHound, Вы писали:

WH>Кешь сбросит драйвер видюхи между пунктами 7 и 8.
Нельзя так делать.

WH>А "текстура загружена" это не команда, а ответ приложению что все ОК.
Я так и понял.

C>>А, там ещё веселуха есть. GART Aperture ограничен архитектурно на AGP 512 мегабайтами, так что если на карте более 512Мб, то используется переключение банков (...вспомним старый добрый Спектрум...). Так что у буфферов ещё будет признак "в системной памяти".
WH>И чё?
WH>Буфер выделяет драйвер по всем правилам.
WH>Отдает приложению.
WH>Приложение его заполняет и отдает драйверу.
WH>При это система типов гарантирует что у приложения не останется ссылок на этот самый буфер.
WH>Ну и где проблемы?
Уже нет красивых потоков, а есть специальные буфферы. А ещё нужны мутируемые буфферы, в которые можно рисовать.

Я к чему это? К тому, что ради скорости придётся делать частные случаи. Одним из таких случаев является файловая система — там большое количество оптимизаций для хранения и работы с блоками данных. Попытки сделать что-то обобщённое вполне реальны, но обычно сильно тормозят.

C>>Выравнивание страниц. Требование выравнивания надо передать на самый верхний уровень.
WH>Никуда оно не протекло.
Ты как мантру это повторяешь? Нужно получить как-то выровненный буффер. Как это сделать, если он может быть распределён как угодно?

Здравствуйте, Cyberax, Вы писали:

WH>>Кешь сбросит драйвер видюхи между пунктами 7 и 8.
C>Нельзя так делать.
Почему?

C>Уже нет красивых потоков, а есть специальные буфферы.
А куда они делись?
Там где были потоки там они и остались.
А тут естественное представление это буфер.
И тут сделан буфер.

C>А ещё нужны мутируемые буфферы, в которые можно рисовать.
Ты про DiractDraw? Так его даже мелкософты из новых версий DirectX выкинули.
Но если очень хочется то будет такой же диалог как в случае с текстурой.

C>Я к чему это? К тому, что ради скорости придётся делать частные случаи.
Не придется.

C>Одним из таких случаев является файловая система — там большое количество оптимизаций для хранения и работы с блоками данных. Попытки сделать что-то обобщённое вполне реальны, но обычно сильно тормозят.
Я вроде уже написал как все обобщить и ты согласился что все будет работать как минимум не хуже чем в современных ОС.
А теперь снова по кругу

C>Ты как мантру это повторяешь?
Это ты как мантру повторяешь. Протечки! Протечки!

C>Нужно получить как-то выровненный буффер. Как это сделать, если он может быть распределён как угодно?
Еще раз: Его выделит драйвер как надо.
В прикладной код буфер приедет уже выделенный так как надо.
Никаких протечек.

Если ты отправляешь HTTP ответ то тебе все равно придется отдельно отправлять заголовки и отдельно картинку.
В любой ОС.

Здравствуйте, WolfHound, Вы писали:

WH>>>Кешь сбросит драйвер видюхи между пунктами 7 и 8.
C>>Нельзя так делать.
WH>Почему?
Если на каждую текстуру кэш сбрасывать — задолбаешься.

(работа с кэшем CPU — вообще сейчас самое сложное в программировании видеокарт)

C>>А ещё нужны мутируемые буфферы, в которые можно рисовать.
WH>Ты про DiractDraw? Так его даже мелкософты из новых версий DirectX выкинули.
WH>Но если очень хочется то будет такой же диалог как в случае с текстурой.
И опять те же проблемы с кэшем. А ещё я сейчас смотрю на драйвер видеокарты — там бывает ещё и специальное некэшируемое копирование. И ещё sharing части данных между буфферами. Уууххх.

C>>Одним из таких случаев является файловая система — там большое количество оптимизаций для хранения и работы с блоками данных. Попытки сделать что-то обобщённое вполне реальны, но обычно сильно тормозят.
WH>Я вроде уже написал как все обобщить и ты согласился что все будет работать как минимум не хуже чем в современных ОС.
WH>А теперь снова по кругу
Только для данного случая. Я пока не уверен, что в общем случае это удастся.

C>>Нужно получить как-то выровненный буффер. Как это сделать, если он может быть распределён как угодно?
WH>Еще раз: Его выделит драйвер как надо.
WH>В прикладной код буфер приедет уже выделенный так как надо.
WH>Никаких протечек.
Тогда прикладной код должен заранее создавать буфферы, зная что они будет позднее использоваться в FS. Я про это и говорю.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Тот факт, что MS начала разработку SQL FS, говорит о том, что такая задача может быть поставлена. Вряд ли они бы начали эту разработку, не продумав идею.
PD>Тот факт, что эта FS так и не появилась и теперь неясно, когда появится, говорит о том, что имеются , по-видимому, достаточно серьезные проблемы в ее реализации.

Этим делом в MS (тогда это было WinFS) занималась команда, о которой в MS уже ходят легенды. Эти парни загубили не одну интересную идею и в данный момент весьма успешно это делают с EF. WinFS таки даже появилась и вышла как отдельное дополнение, но кривыми ручками видимо сложно сделать что-то прямое. Вскоре её не стало даже как дополнения.

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

Здравствуйте, IT, Вы писали:

PD>>Объяснять я ничего не буду. Этот флейм тут уже не раз устраивался, да и Cyberax ответил, я мог бы добавить, но и этого не буду.
IT>Cyberax упомянул только оптимизации, но ничего принципиального. А оптимизации как известно имеют тенденцию устаревать и отсыхать. Вчера мы оптимизировали наши программы под 640 KB памяти, завтра будем оптимизировать под 640 ядер процессора.
Кстати, а как там себя чувствует NUMA-aware аллокатор буфферов?

Здравствуйте, Cyberax, Вы писали:

C>Кстати, а как там себя чувствует NUMA-aware аллокатор буфферов?

Кто это такой?

Здравствуйте, Cyberax, Вы писали:

C>Если на каждую текстуру кэш сбрасывать — задолбаешься.
Это блин мелкие детали реализации.
Никто не мешает копить текстуры пока они не понадобятся, а потом сбросить один наз на всех кешь.

C>Только для данного случая. Я пока не уверен, что в общем случае это удастся.
Куда оно нахрен денется?
В самом худшем случае получится DirectX.
Что сильно сквозь DirectX драйверы протекают?

C>Тогда прикладной код должен заранее создавать буфферы, зная что они будет позднее использоваться в FS. Я про это и говорю.
Про FS уже ВСЕ обсудили и ты согласился что будет как минимум не хуже.
Блин. Ты хуже Дворкина. Соглашаешься, а через полтора сообщения выходишь на второй круг

Здравствуйте, Cyberax, Вы писали:
C>Нет. Если делать всё абстрактно, то буффер может выделить кто угодно.
Если делать всё абстрактно, то и производительность будет совершенно абстрактной. Никто не обещал полной прозрачности. А вот отсутствие межпроцессного маршаллинга никуда не денется.

C>А не получится...
С чего бы?

C>Для кластеров в HPC нужны низколатентные сети.
Про HPC я знаю слишком мало, чтобы осмысленно что-то обсуждать. Но что-то мне подсказывает, что только в очень экзотических сетях 1 лишний вызов DMA на операцию будет заметен на фоне стоимости трансфера через сеть. Всё-таки внутренняя шина обычно на порядок шустрее.

C>В Линуксе оно с помощью splice() работает для почти любых дескрипторов.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Тот факт, что MS начала разработку SQL FS, говорит о том, что такая задача может быть поставлена. Вряд ли они бы начали эту разработку, не продумав идею.
PD>>Тот факт, что эта FS так и не появилась и теперь неясно, когда появится, говорит о том, что имеются , по-видимому, достаточно серьезные проблемы в ее реализации.

IT>Этим делом в MS (тогда это было WinFS) занималась команда, о которой в MS уже ходят легенды. Эти парни загубили не одну интересную идею и в данный момент весьма успешно это делают с EF. WinFS таки даже появилась и вышла как отдельное дополнение, но кривыми ручками видимо сложно сделать что-то прямое. Вскоре её не стало даже как дополнения.

IT>В общем, "тот факт, что эта FS так и не появилась и теперь неясно, когда появится, говорит" лишь о том, что кривыми руками достаточно легко устроить любые серьезные проблемы в реализации чего угодно.

Может, ты и прав в своем выводе (насчет кривых рук), но тут одно "но" есть. Если бы эта ФС была МС действительно нужна, то она, обнаружив, что команда ее разработчиков имеет кривые руки, разогнала бы ее и создала новую уже не с кривыми руками. Но не стала. Видимо, не так уж нужна.

Здравствуйте, Sinclair, Вы писали:

C>>Нет. Если делать всё абстрактно, то буффер может выделить кто угодно.
S>Если делать всё абстрактно, то и производительность будет совершенно абстрактной. Никто не обещал полной прозрачности. А вот отсутствие межпроцессного маршаллинга никуда не денется.
Обещал WolfHound. Про то и речь идёт.

C>>Для кластеров в HPC нужны низколатентные сети.
S>Про HPC я знаю слишком мало, чтобы осмысленно что-то обсуждать. Но что-то мне подсказывает, что только в очень экзотических сетях 1 лишний вызов DMA на операцию будет заметен на фоне стоимости трансфера через сеть.
Очень даже заметен.

S>Всё-таки внутренняя шина обычно на порядок шустрее.
Часто всего лишь в разы.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Может, ты и прав в своем выводе (насчет кривых рук), но тут одно "но" есть. Если бы эта ФС была МС действительно нужна, то она, обнаружив, что команда ее разработчиков имеет кривые руки, разогнала бы ее и создала новую уже не с кривыми руками. Но не стала. Видимо, не так уж нужна.

Нужность — это не совсем то, что здесь обсуждается. С этим я как раз согласен. Нужна ли FS based on SQL? Лично мне нет.