то 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 . Вам не надо будет заново "напрягать всю вашу ВТ систему", так результат можно будет считать с Устройства .

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