Обсуждение

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

Идея витала давно. Даже на более мелких уровнях. Когда любая мелкая программа в винде все равно использовала виртуальную память.

Мне один знакомый как-то сказал, что под Виндой больше всего производительности дает не оптимизация по скорости, а оптимизация по памяти. Типа тогда прога в кэш влезать начинает. Вообще, требовательные алгоритмы давно оптимизируют относительно кэша, чтобы его эффективно использовать. Я просто стараюсь структуры данных покомпактнее делать (в лозунги типа что память дешевая я не верю), полокальнее и попоследовательнее. А вместо БД нужно напрямую с файлами работать. На практике, функциональность предоставляемая БД нужна не так уж и часто. Точнее, там где важна производительность, БД нужно изгонять, в остальных местах ее можно использовать, поскольку программеры к ним привыкли.

Так что дорога отныне раздваивается: десятикратные ускорения на обычных процессорах против десятикратных ускорений за счет использования спецпроцессоров видеокарточек. Если базу данных выкинуть, то десятикратной ускорение на многих задачах можно получить без особых ухищрений. Просто БД оптимизированы под какие-то общие типовые случаи, но их АПИ не дает возможностей оптимизации под данный конкретный случай. Точнее в принципе дает, но надо все переписывать сверху до низу и нетриваиальным образом нормализовывать/денормализовывать таблицы (иногда нормализация дает плюс, иногда денормализация дает плюс), а не просто индексы оптимизировать. Махровый DBA убъется об стену от такого богохультсва :).

Это ж всех программистов переучивать. И профессоров, кстати, тоже. :-)

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

Да нет там никакого раздвоения. На видеокарточках примерно та жэ морока из иерархий разных видов памяти. Методы работы с которыми постепенно развиваются. Рекордсмены в тепличных условиях показывают x10, нормальные люди прыгают от радости когда на обычной задаче эти x10 превращаются в x1.8. Я скорее верю в наоборот, что подход Cell окажэтся удачным, и умные векторные DSP в полной мере воткнут в процэссоры общего назначения. Кто это первым сделает — Nvidia (скомпилировав ядро linux на очередном GPU), Intel (вставив приличный графический акселератор с поддержкой CUDA в свои процы) или кто-то третий — вопрос любопытный, но для оцэнки развития несущественный.

БД вполне может получиться - для определенного класса задач, когда нужно работать с простой схемой данных очень_быстро. Билинг, многие вэбпроекты. Но сколько будет стоить "загнать в память" 300Тб данных некоторых корпоративных систем - я пока даже считать не хочу. А иначе вся сверхскорость споткнется там же, где и сейчас - IOPS storage. Для расчетных\переборных задач - я вне темы. Насчет профессоров не скажу, а программеров переучивать, скорее всего, не придется - они и так в своей массе к БД через прослойку (Hibernate и иже с ним) ходят.

Ассоциативная память жрет гораздо больше обычной. Потому что адрес требуется размножить на все компараторы.

Это как раз то, что мне больше всего нравится в таких историях. :) Табель о рангах через несколько лет может сильно поменяться.

Я и говорю - нафиг суперкомпьютеры :)

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

С БД это в новинку, потому что БД работают с гига-и терабайтами, которые в кэши не лезут. А в игростроении, например, это баян.

от темы потянуло на такую философию... часто с такими вещами приходится сталкиваться, например, работал давно с суперсистемой 1с. эта высокоинтеллектуальная программа выполняла центральную по значимости обработку в течение 4х суток (около 90 часов). неделю переписывал конфигурацию, в результате чего время выполнения сократилось до 3х минут. без никаких СУБД, всё через файлы работало, с учётом всей специфики задач. причём там кантора не лавочка, а крупное региональное предприятие, в базе милионы записей. (похвастался:) виндовс можно во стоько же раз ускорить. и вообще все программы в тысячи раз. щас дико всё происходит. за возможность участвовать в проекте большого количества программистов приходится платить чудовищными объёмами кода и прожорливостью к ресурсам. всё должно происходить как-то так: нет никаких ни субд ни языков алгоритмов(языки алгоритмов - зло, особенно компилируемые). нужен метаязык описания, на котором полностью прописывается вся логика работы системы. прописывается не блок-схемами, а какими-то средствами вроде регулярных выражений. на основании этого описания и описания имеющихся вычислительных ресурсов "самопрограммируецо" уже работающий продукт. внутри у него местами будет что-то похожее на субд, на множество внутренних языков типа хмл, слт и т.д. знать о них, их специально изучать нет никакого смысла. если это будет, то и архитектуру процессора можно будет обоснованную делать. ведь сейчас никто не знает какие команды в нём необходимы, оптимальны, эффективны - руководствуются чисто человеческой логикой набора "понятных" двоичных операций. или даже процессор без набора команд - например, под конкретную текущую ситуацию в нём устанавливается конфигурация, обеспечивающая преобразование входного потока данных в выходной, на основе описания моделей данных и преобразований. вот это быстро было бы! ...

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

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

А иначе вся сверхскорость споткнется там же, где и сейчас - IOPS storage. Суперкомпьютер - это устройство, которое преобразует проблему вычислений в проблему ввода-вывода (с) Не знаю кто

Например, сложение двух регистров выполняется за 1 такт, а загрузка регистра значением из памяти 4 такта. Вы видимо программированием последний раз в прошлом тысячелетии занимались. Тогда загрузка из памяти и правда 4 такта занимал, тогда и кэши не нужны были. А сейчас 4 такта загрузка из кэша занимает, да и то не из всякого. Там ведь целая иерархия кэшей с разной латентностью. Попробуйте на практике, а не в теории попрограммировать чего-нить. Например возьмите таблицу или хэш-таблицу и проверьте скорость доступа на разных размерах, когда (хэш-)таблица влезает в кэш и когда не влезает. Еще поиграйтесь с последовательным vs случайным доступом в большую таблицу. Впрочем, можно просто хорошую свежую статью прочитать про кэши, там это расписывается.

Вот к примеру статейка http://www.ixbt.com/cpu/rmma-phenom.shtml

Ну, насколько я понимаю не на все — а в среднем где-то по паре компараторов на каждую строку кэша (хотя сам их не делал, могу здесь несколько напутать). Учитывая, что для обычной — надо открыть все строки и столбцы адреса на все биты ячейки памяти — разница получается конечно в разы, но сравнимо с разницэй между DRAM и SRAM. Ну и в главных — сами операцыи поиска, выборки, арбитража между DRAM и сверхбыстрой SRAM никуда не денутся только из-за того, что их выкинут из аппаратной реализацыи. А чтобы программная реализацыя через CPU жрала меньшэ — это надо очень постараться, плюс должно немного повезти.