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

Не ожиданно для себя, включился в одном уважаемом форуме, и высказал тезис об аппратной поддержки функции 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-процессорах.

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

то Gluk (Kazan) и miksoft

Спасибо большое за подержку диалога. Я признаться гововоря не совсем хорошо поступил, задал в некотором роде, провакационный вопрос - как сложить два числа. Спроси у программиста как сложить два + два, и сразу узнаешь все что о тебе думают:-)

Позвольте, описать немножко иной подход к сложению чисел. (как сложить два числа - не складывая их самих!).

Сначала уточним термин "процессор" = "черный ящик, умеет принимать Данные, Инструкции и выдавать Новые Данные".

Обратим внимание, что "миллион" процессоров образуют собой...пространство (плоскость, объем..). Или просто - среда. Тогда, любое Число, в пространстве из N-процессоров, может получить свою Область Определения. Или = Тень ("след", площадь, объем...). Или Образ.

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

В общем, имея N-процессоров, легко представить - что для сложения двух чисел - достаточно будет их отразить на пространство N-процессоров (передать по шине) и изучить объем (площадь) их области определения. Это делается в принципе за 1 такт.

Теперь задача на умножение. Сводится к задаче на построение "площади фигуры" (прямоугольника) в простанстве из N-процессоров.

Я не ошибся??

miksoft UK0IAIНапример, путем сложения (преобразования) областей определения чисел (их "теней").тут я совсем теряю нить обсуждения...

Дайте, пожалуйста, ваше определение операции "сложение областей"

Прошу прощения - я опять скатываюсь в область "измерений".
(триз - "если доступ к объекту затруднен - используйте его копию". Т.е если Вычислять (складывать по битам) = тяжело, попробуйте поработать с "тенью". вдруг, это будет "легче").

Не вычислять - а измерять. Образ числа в пространстве из N-процессоров -это есть ничто иное как "тень". "Геометрическая фигура". "Отрезок". А каждый процессор, по сути выполняеет роль простого "датчика". Тогда, для сложения двух чисел (отрезков на прямой), достачно узнать их суммарную длину (площадь фигуры). Это делается путем простого "измерения". Например, достаточно просто "узнать" координату конца отрезка (вектора) - если у нас есть некая система координат.

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

Но не важно. Суть вопроса не меняется. Есть N-процессоров. Где каждый процессор - есть некое устройство (логическое, физическое..). Нужен Алгоритм (принципиальная идея) которая обеспечит прирост производительности в N-раз.

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

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

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

ИМХО.

ErikВы зря ломеете копья, такие системы уже есть. Они применяются с супер-компютерах. Например у нас есть 10000 физических процесоров. Это представляестя как виртульная вычислительная мощность для большого количества потоков. Такм обзаром мы обстрагируется от физической схемы. Для таких машин прменаются спецпльные языки, их компилятор сам распаралеливает исходный текст на потоки, там где можно. А привыполнении операционая система выполняет их паралельно или если нехватает ресурсов последовательно.
Ненадо изобретать велосипед.

Да конечно велосипед. Исключая вопрос о неком компактном устройстве на шине - для поддержки функции SUM. И попытка понять - на каких принципах это может быть реализовано. Скажем так - еще не понятно: -)

В принципе, тему надо закрыть.

miksoft UK0IAI(очень элегантно и просто - опрашиваем N-процессоров, каждый из которых принадлежит "отрезку", и выбираем тот - где конец отрезка (правый "сторона" свободна). Номер процессора - есть абсолютная величина слогаемого.) ....Что-то мне это машину Поста напоминает... А еще - унитарный код... UK0IAIНо не важно. Суть вопроса не меняется. Есть N-процессоров. Где каждый процессор - есть некое устройство (логическое, физическое..). Нужен Алгоритм (принципиальная идея) которая обеспечит прирост производительности в N-раз.

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

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

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

ИМХО.Даже если все это математически возможно (я это не совсем понял), то вряд ли практически реализуемо, т.к. будет требовать просто несусветного количества оборудования, то бишь транзисторов.

UK0IAIВ принципе, тему надо закрыть.абсолютно согласен!

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

Пусть у нас есть аналог числа. Стакан с водой. В одном стакане 15 см2, в другом = 12 см3.
Это наш эквивалент чисел 15 и 12. Надо сложить 15 + 12.

1. Берем первый стакан и сливаем его содержимое в мерную емкость с поплавком. Затем сливаем второй. Поплавок установится на отметке 27 см3. Зачитываем показания поплавка и сообщаем.

Быстродействие системы зависит от скорости заливки (толщины струи и давления) + скорости измерения положения поплавка.

2. Вариант = делаем тоже самое = но в момент заливки, у нас в канале, есть расходомер. Поплавок не нужен, важна непрывность процесса (подряд два стакана залить). Но результат - узнаем сразу в момент окончания заливки (закачки).

Если воду и стаканы заменить своими аналогами (данными), то мы в принципе можем построить аналог.

На шине ПК ставится свой "расходомер", который "узнает" тотал (сумму) в момент прокачки порции данных по шине, между чем? ну устройствами, наверно, или приложениями...

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

Эти два варианта имееют одно общее - нет никаких циклов, итераций, битовых операций. Скорость системы зависит от "широты канала" и его быстродействия.

Если в шину "воткнуть" N "счетчиков-расходомеров", то мы можем одновременно, прокачать по шине N-порций данных. И знать N их тоталов.

Пример.
Дано: массив из 100 строк. Есть 10 "счетчиков-расходомеров". Качаем 100 строк (10 по 10 узлам) = получаем 10 тоталов, затем "сложим эти 10 тоталов и получим результат.
Это будет быстрее в (10 раз -1 раз), чем просто в цикле, сложить 100 строк массива.

В общем понятно, что здесь нет ничего особенного. Так просто, закрываем тему.

Виноват.

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

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

Одно приложение сделало запрос типа
select A, B, C from table а другое
select sum(A), sum(B), sum(C) from table

При некоторых условиях, эти запросы, с точки зрения СУБД будут одинаковыми, данные = уже кэшированы, а тоталы уже известны. Следовательно, второй запрос, физически, может не исполняться.

Запросы типа select A, B, sum(C) from table group by A, B.... = в принципе тоже самое. Так как в момент исполнения базового запроса select A, B, C from table все возможные варианты тоталов в разрезе group by = тоже будут (могут быть) известны.

BrianES2 UK0IAI
Почитай Численные Методы или Вычислительную Математику, как раз идея приближенных вычислений) Всё украдено до нас... (с)

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

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

На самом деле, я всего лишь последовательно пытался применить сугубо инженерные методы ТРИЗ(теорию решения изобретательских задач) к вопросам конструирование вычислительных систем.
Если полагать что ТРИЗ - это инструмент прежде всего, так сказать инженера (механика), а ВТ
а базируется прежде всего на Математике, то мне было интересно посмотреть - куда и к чему это может привести.

В первые,мы это обсуждали здесь
/topic/180705&pg=3

Я пытался сформулировать простое техническое противоречие и искал способы его разрешения.
В итоге , был сделан вывод о возможности добавления к "рядовому" ПК некого устройства. Которое, (чисто по ТРИЗ = САМО), само, на всякий случай считает Тоталы (суммы).

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

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

И попытался применить ЭТО к ...СУБД. Но не только - а вообще, к задачам Сложения. Начиная таких простых вещей как i++ , до скажем задач о сортировке массивов или к задачам оптимизации.

Я хотел только посмотреть, что может получиться. Я понимал , что "N-процессоров" это круто, но не знал - как их можно задействовать в архитектуре "по условиям задачи = рядового ПК, а не суперкомпьютера". Теперь я понял - что можно просто добавить "устройство". Которое будет "тупо считать Тоталы". Когда они нам понадобятся - мы можем их "прочитать" (извлечь).

Другими словами словами - "5 минут назад, вы делали select A, B, C from table "
А через пять минут вам понадобился select sum(A) from table . Вам не надо будет заново "напрягать всю вашу ВТ систему", так результат можно будет считать с Устройства .

Трудно сказать - есть ли здесь практический смысл. Все это всего лишь следствие от применения ТРИЗ.