Доброго все вечера.

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

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

И сказали мне что это все чепуха. Дескать расчет тотала - это не самое главное.

И возник интересный вопрос - какой реально процент процессорного времени используется для вычисления функции SUM (средствами СУБД) при различных нагрузках.

Можно ли утверждать, что время непосредственного вычисления всех операций суммирования (например) при расчете (ну например, годового баланса крупной конторы) пренебрежимо мало по сравнению со времением потраченным на отбор и поиск рекордов в БД.

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

Ну в общем, прошу дать какую либо экпертную оценку.

Что то подсказывает мне, что эта самая SUM - субд типа ОРАКЛЕ, имеет в себе массу накладных расходов (связанных с непосредственной, поддержкой например, целостности, транзакций...где функция SUM яляется весьма часто используемой).

И возможно, все актуально для очень крупных БД?

а как часто функция SUM исполняется в мормент этих самых накладных расходов:?

miksoftИ здесь раскритикуют!

Я спрашивал на официальных ораковых курсах, почему Оракл не использует всякие современные процессорные расширения типа MMX, SSE и т.п.
Ответ - во-первых, у Оракла исходники одни для большинства аппаратных платформ, во-вторых, даже если все данные закэшены, накладные расходы значительно превышают расходы на само суммирование.

По видимому, основная идея "аппратной поддержки" функции SUM, должна быть такая реализация - когда это все САМО происходит, вне зависимости от "желания" вендора использовать/не использовать эту фичу.

(я пока не понимаю - как это можно сделать, но что то мне все время ....думается об этом :-)

Собственно вопрос звучит примерно так - какие могут пути развития современных компов??.

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

Понятно, что минимизация размеров элементной базы - рано и поздо позволит создавать компы (процессоры) обладающие большим кол-вом "встроенных" вычислительных устройств. Например, самих ЦП.

Также, понятно, что это поли_процессорность, может буквально "свалиться на голову вендора" = вдруг, неожиданно. Вот вчера - все работали на одно процессорных компах, а сегодня у юзеров "вдруг", уже "автоматом" стоят на столах 4-х ядерные комты (Intel core dual qx6700 :-).

Или просто, очередной технологический прорыв в производстве микросхем, позволит клепать такие ЦП "пачками" (гроздьями).

И возникнет вечный вопрос - как реально заставить "последовательные алгоритмы", реально использовать возможности "много_процессорности", когда по своей природе - это вроде как физические не возможно (без нарушения законов причинно-следственности).

Кажется одним из таких путей, является идея, исполнения на "вспогательных" ЦП, вспомогательных, накладных операций, производимых собственно СУБД. Например, функции SUM. Точнее - вообще, задачки о суммировании (расчета) тотала по строкам ЛЮБОГО массива.

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

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

Что то мне все время подсказывает, это собака (свинья 2007 :-) зарыта именно здесь.

Хрен UK0IAI
Кажется одним из таких путей, является идея, исполнения на "вспогательных" ЦП, вспомогательных, накладных операций, производимых собственно СУБД. Например, функции SUM. Точнее - вообще, задачки о суммировании (расчета) тотала по строкам ЛЮБОГО массива.

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


К сожалению субд как правило :) многопользовательские приложения. Двадцать соединений - каждое выполняет sum - как вы себе представляете использование железного сумматора в таком случае? один процесс суммируется остальные ждут?

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

Мне интересен, наверно, крайний случай - (фантазируем - расшатываем воображение...)

Допустим, у нас на "шине" , или просто где то в системе имеется сразу МИЛЛИОН вычислительных устройств. (сумматоров OR процессоров OR со_процессоров). И всего одно пользовательская нагрузка. Что можно сделать вообще? при таком изобилии мощностей...

UK0IAIДопустим, у нас на "шине" , или просто где то в системе имеется сразу МИЛЛИОН вычислительных устройств. (сумматоров OR процессоров OR со_процессоров). И всего одно пользовательская нагрузка. Что можно сделать вообще? при таком изобилии мощностей...

Локшин Марк
Не прото где-то, а эти сумматоры должны непосредственно иметь доступ к ячейкам памяти, т.е. по всей видимости распологаться в них (микросхемах памяти).

Возможно, через некоторое время, оперативная память и процессор будут единым устройством.
Мне, наверно, нравится тезис о "черном ящике", где есть "миллион" процессоров и неограниченный объем оперативной памяти. Т.е я предельно обостряю техническое противоречие - вот есть программа (сложная, типа СУБД) - а вот вам ВЦ - где памяти и процессоров немерянно. И мы можем тогда сосредоточить внимание на физическом смысле.

Локшин Марк
Тогда за 21 такт работы такой системы при наличии дополнительной памяти для сохранения миллиона промежуточных результатов ( если считать без учета переполнения) можно сложить 2 миллиона чисел.
Только зачем это нужно? А если требуется найти min\max? А если выражение более сложное, чем просто сложение по аттрибуту (например сложение произведений - типичная задача если складываемые величины в разные единицах измерения хранятся)? А если нужно обработаь значения типа null и т.д.?
Получится крайне не универсальное, дорогое устройство всего лишь с одной функций, а с учетом
того, что данные еще туда нужно как-то передать, то для типичных задач СУБД это будет неприменимо, т.к. быстрее будет сразу все посчитать, чем пользоваться таким устройством.

На первый взгляд, есть несколько идей-направлений.

Первая - наверно такая, что обычная программа, может быть подвергнута процедуре parse (так как это делает субд с запросами) на предмет проверки возможности параллельных вычислений. И затем она должна делать свое execute .

Возможно, сама процедура parse, в условиях "многопроцессорности" (ну и термин) - может быть выполнена по некому, совершенному алгоритму...(грубо - "режем" код проги на миллион кусков, кидаем на миллион процев и мгновенно узнаем - что можно вычислить параллельно.)

Самое интересное, что для простых программ - многопроцессорность - как припарка. А вот для сложных... Ну на примере СУБД....

Прежде чем дело дойдет до собствено исчисления SUM в запросе, СУБД исполняет массу накладных действий. Начиная от проверки привелегий доступа юзера, до проверки наличия необходимых екстентов (памяти)...для резервирования или скажем, расшифровки ситуации по грязным чтениям... вот запрос, это понятно - а где собственно данные есть (в кэше, на дисках, в логах....).

Не знаю как это все работает, но там (наверно) милльоны строк программного кода. И понятно, что (очевидно) есть масса ситуаций - которые могут быть реально распаралеллены. И если у нас УЖЕ есть мильон процессоров (OR) сумматоров, то мы можем реально придумать некий алгоритм PARSE, который однозначно ( САМ) найдет "куски кода" которые могут быть распараллелены.

Возможно - есть разные вещи. Одна - расчет SUM, вторая - логическое исполнение алгоритма по шагам.

И если наш алгоритм НИКАК не позволяет исполнить отдельные шаги - одновременно и параллельно, это вовсе не означает - что мы не может пытаться при этом, на стадии parse, произвести параллельные вычисления. (расчет промежуточных значений как на пример)

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

Забегая вперед, вообще наперед, наши технические системы, которыми мы управляем - никогда не оперируют абсолютно точными значениями - все измеряемые и управлемые величины - имеют свой допуск точности. (диаметр детали на токарном станке измеряется как +- доли миллиметра)

В то время как наши ИТ системы, которые мы привлекаем для управления техническими устройствами - всегда производят абсолютно точные вычисления.

Возможно, по жизни, это и не требуется. Вот яркий пример. Задача о компановке. Надо подобрать варианты компановки (укладки) деталей в контейнер. Оптимально.

1. решение - в лоб, путем перебора всех возможных вариантов. (долго...!!)
2. решение - "случайно потрясти" (выбрать) штук 100 вариантов компановки, из них выбрать самый лучший. (но не абсолютно оптимальный).

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

Второй вариант - идеально использует идею многопроцессорности. Понятно, да? (если привлечь ТРИЗ для анализа - мы видим - что мы получили идеальную компановку - не делая ее как таковую, т.е идеальное решение САМО получается (случайно!!!). А это однозначно (по триз) - верный метод = самый лучший.)


А теперь мы экстраполируем эту тему до безобразия. Задача - сложить две больших величины (числа).

1 вариант - по байтам, по регистрам...абсолютно точно (с-л-о-ж-и-ть).

2 вариант - заюзать некий случайный алгоритм, кторый будучи исполнен одновременно миллион раз (испытаний) выдаст результат с требуемой степенью точности, но в миллион раз быстрее.

Интересно - куда можно при этом зайти :-))))))))))

Локшин Марк UK0IAIПервая - наверно такая, что обычная программа, может быть подвергнута процедуре parse (так как это делает субд с запросами) на предмет проверки возможности параллельных вычислений. И затем она должна делать свое execute. Кстати, определенный уровень параллелизма уже обеспечивают современные процессоры, но то, что хотите Вы - это уже задачи из области ИИ.
Чтобы представить, во что превращается автоматизация распараллеливания программы написанной на алгоритмическом языке даже в простых случаях - прочитайте, например
http://www.books.ru/shop/books/30896
Дальше - вообще какие-то фантазии идут...

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

Но иногда, пролезают "фантазии". Иногда, бывает интересно их как то понять.

Ситуация предельно проста. Очень скоро, ЦП рядого ПК може иметь "мильон" ядер. Возникает вопрос по существу - что можно с этого получить. Можно ли ускорить работу ВТ в мильон раз.
В принципе.

Вообще то, (по триз), мы имеем дело с Развитием Технической Системы. Которое отлично описывается своей теорией. Там есть простой постулат (идея) - что ТС развивается и выходит на следующий уровень - всегда - после некого фундаментального открытия.

Т.е - не надо даже и пытаться строить алгоритмы "автоматизация распараллеливания программы"
сколь угодно простые или сложные надежные/не надежные.

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

Нужно фундаментальное открытие, прорыв. Не больше и не меньше.

Но в какой области??? В области производства микросхем??? Или в области построения ИИ (метод обучения произвольного ИИ отличающийя тем, что произвольный ИИ после обучения становится идеально "умным")

Или - в области математики??????? Ха, вот это наверно будет сверх_эффект. Придумать постулат, теорему, и доказать ее. (чисто на пальцах :-))))

Кажется я "сбрендил" :-)

Не вычислять ПРЯМО (долго, тупо, последовательно, нудно), прогоняя прогу (перфоленту по сути своей!!!) через "очко" считывающего устройства!!!

А проводить (что??? измерения???, испытания???, предсказания:???....), задействуя "мильоны" ВЦ одновременно, получая при этом ГАРАНТИРОВАННО ДОСТОВЕРНЫЙ РЕЗУЛЬТАТ. За 1 такт.

Интересно однако....

в развитие воображения...

Давайте например, откажемся о концепции целых чисел. Вообще. И строим ИТ систему, где никогда не бывает целых (круглых, точных, не дробных) чисел. Допустимо??. Работать будет??
Баланс, сальдо (деньги в банке) считать будет??? Будет. Погрешность может быть?? Ну конечно, пару центов туда-сюда... но не более. Согласны?? Устроит такая ИТ система??
А почему бы и нет.

Ха, а вот мы и пришли к нашим фантазиям. И строим в такой ИТ системе, центральный процессор, который НИКОГДА не далает точных вычислений. По шагам надежного алгоритма. А тупо, что там у себя "трясет" (быстро) и выдает ПРИМЕРНЫЙ результат.

Ну и что???

Dried Gagarin UK0IAIв развитие воображения...

Давайте например, откажемся о концепции целых чисел. Вообще. И строим ИТ систему, где никогда не бывает целых (круглых, точных, не дробных) чисел. Допустимо??. Работать будет??
Баланс, сальдо (деньги в банке) считать будет??? Будет. Погрешность может быть?? Ну конечно, пару центов туда-сюда... но не более. Согласны?? Устроит такая ИТ система??
А почему бы и нет.

Ха, а вот мы и пришли к нашим фантазиям. И строим в такой ИТ системе, центральный процессор, который НИКОГДА не далает точных вычислений. По шагам надежного алгоритма. А тупо, что там у себя "трясет" (быстро) и выдает ПРИМЕРНЫЙ результат.

Ну и что???

авторORACLE developor/DBA

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

Это что - ругательство или прикол? Судя по использованному набору знаков, мистер обладает достаточно продвинутым интеллектом. Мистер видел (читал) заголовок поста? Там четко написано
В развитие воображения... И многоточие добавленно. Многоточие, однозначно определяет что данный текст содержит за собой расширенный контекст, опущенный по тексту, целях сокращения текста.

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

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

В данном случае, я специально нарушил базовую идею Информатики - основанную на целочисленной математике (логическом 0 и 1). Мне стало интерено - что из этого может получится.

Второе - одно из требований предъявлемой к любой ИТ - является Достоверность и Проверяемость. Однако, с развитие и усложнением ИТ - это становится проблематичным.

(современные крупные программные продукты не соотвествуют, и УЖЕ развиваются по технологии, которую можно сравнить с теорией итераций - на рынок выпускается коммерчекий продукт, который отлаживается в процессе эксплуатации, путем использовения методов массовой обработки (тестирования!!) на стороне пользователя, с использованием так сказать медотов распеределенных вычислений! ... задействуя бесплатный ресурс - пользователя (и его ВТ))..

Поэтому, мне стало интересно (по триз) подумать - а зачем? А зачем иметь абсолютно точный результат. Путь компьютер выдает приближенный, но быстро!!! (мгновенно). И что тогда будет???

Я не знаю ...пока.

miksoft UK0IAIПоэтому, мне стало интересно (по триз) подумать - а зачем? А зачем иметь абсолютно точный результат. Путь компьютер выдает приближенный, но быстро!!! (мгновенно). И что тогда будет???Это уже было! И, в значительной степени, прошло...
Почитайте про аналоговые ЭВМ. В частности, они давали приближенное решение многих диффуров значительно быстрее, чем дискретные ЭВМ 20-летней давности.

Да, конечно мне это известно. Да, аналоговая система - может быстрее на порядки работать. Да нет проблем. Да это было. Вопрос в другом - нужно ли ЭТО?????? (то что было - нет проблем, все развивается иногда по спирали)...

Вопрос задан более конкретно - допустим, есть эвм (пк), в которой имеется миллион процессоров.
И хочется, чтобы, например, программы (рядовые?) работали при этом в миллион раз быстрее. Что для этого нужно сделать?.

Я пока вижу реально как минимум две категории задач (алогоритмов) что могут быть эффективны.

1. Задача на компановку (оптимизации) которая исполняется на основе вероятностных алгоритмов
2. Задача на сортировку (в системе из n-процессоров, сортировка может быть произведена в n-1 раз быстрее).

3. Задача на вычисления (сложение). Ответьте мне на простой вопрос - можно ли сложить всего лишь ДВА больших числа (на скажем 8 порядка) - скажем так - в k-раз быстрее при n-процессорах.

Ну и так далее...