Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
UK0IAI
Member

Откуда: питер
Сообщений: 13567
Доброго все вечера.

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

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

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

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

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

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

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

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

И возможно, все актуально для очень крупных БД?
29 авг 06, 21:00    [3068722]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
miksoft
Member

Откуда:
Сообщений: 38919
И здесь раскритикуют!

Я спрашивал на официальных ораковых курсах, почему Оракл не использует всякие современные процессорные расширения типа MMX, SSE и т.п.
Ответ - во-первых, у Оракла исходники одни для большинства аппаратных платформ, во-вторых, даже если все данные закэшены, накладные расходы значительно превышают расходы на само суммирование.
29 авг 06, 21:38    [3068802]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
UK0IAI
Member

Откуда: питер
Сообщений: 13567
а как часто функция SUM исполняется в мормент этих самых накладных расходов:?
29 авг 06, 21:56    [3068831]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
Nikolay Kulikov
Member

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



автор

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


И вообще не надо говорить про отдельное ускорение какого-то функционала. Нужно говорить о сбалансированной производительности. Ибо все даже самые крутые сервера ждут с одинаковой скоростью. А почему ждут надо разбиратся, не хватает IO/CPU/Memory etc.
1 сен 06, 13:04    [3081800]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
hvlad
Member

Откуда:
Сообщений: 11553
Сравните SELECT COUNT(*) и SELECT SUM(x) по одинаковом набору данных, без использования индексного покрытия есс-но
1 сен 06, 14:40    [3082603]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
Коляныч
Member

Откуда:
Сообщений: 279
hvlad
Сравните SELECT COUNT(*) и SELECT SUM(x) по одинаковом набору данных, без использования индексного покрытия есс-но

Что сравнивать-то...
COUNT(*) - в простом случае не делает вообще никакй выборки
3 окт 06, 16:52    [3216346]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
hvlad
Member

Откуда:
Сообщений: 11553
Коляныч
hvlad
Сравните SELECT COUNT(*) и SELECT SUM(x) по одинаковом набору данных, без использования индексного покрытия есс-но

Что сравнивать-то...
COUNT(*) - в простом случае не делает вообще никакй выборки
Ты сначала вопрос почитай, потом совет перечитай, а потом подумай почему именно этот совет дан именно для этого вопроса, да ?
3 окт 06, 17:01    [3216414]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
UK0IAI
Member

Откуда: питер
Сообщений: 13567
miksoft
И здесь раскритикуют!

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


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

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

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

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

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

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

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

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

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

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

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

Что то мне все время подсказывает, это собака (свинья 2007 :-) зарыта именно здесь.
4 янв 07, 10:00    [3606169]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
Изопропил
Member

Откуда:
Сообщений: 31628
Назад, в будущее
http://www.bashedu.ru/konkurs/tarhov/russian/ps-3000.htm
4 янв 07, 11:49    [3606396]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
UK0IAI

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

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


К сожалению субд как правило :) многопользовательские приложения. Двадцать соединений - каждое выполняет sum - как вы себе представляете использование железного сумматора в таком случае? один процесс суммируется остальные ждут?
4 янв 07, 17:55    [3607436]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
Скорость работы жесткого диска даже при линейном чтении в сотни раз меньше, чем доступ к памяти - следовательно ускорение будет в десятых долях процента.
А когда говорят про "очень крупных БД" обычно понимается, что их содержимое в кэш памяти не умещается.
Кроме того, чтобы брать хоть какие-то данные из кэша, необходимо знать его структуру, каким образом записи на страницах помечаются как удаленные, как они блокируются, как создаются версии данных, структуру записей в строке и т.д.
Более того, если все эти данные не будут сидеть в кэше процессора (т.е. иметь размер ~1МБ), то время доступа к ним уже будет в 10-ки раз меньше (т.е. ни о каком 1 такте и речь идти не может принципиально) - все равно все будет ограничено пропускной способностью памяти, а не отсутствием такой команды в CPU - процессор просто будет ждать данные.
Тогда уж лучше кэшировать результаты выполнения такого запроса или компилировать запрос в исполяемый файл, чтобы ускорить исполнение.
4 янв 07, 21:21    [3607861]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
UK0IAI
Member

Откуда: питер
Сообщений: 13567
Хрен
UK0IAI

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

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


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


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

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

Допустим, у нас на "шине" , или просто где то в системе имеется сразу МИЛЛИОН вычислительных устройств. (сумматоров OR процессоров OR со_процессоров). И всего одно пользовательская нагрузка. Что можно сделать вообще? при таком изобилии мощностей...
4 янв 07, 21:45    [3607902]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
Локшин Марк
Member

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

Не прото где-то, а эти сумматоры должны непосредственно иметь доступ к ячейкам памяти, т.е. по всей видимости распологаться в них (микросхемах памяти). Тогда за 21 такт работы такой системы при наличии дополнительной памяти для сохранения миллиона промежуточных результатов ( если считать без учета переполнения) можно сложить 2 миллиона чисел.
Только зачем это нужно? А если требуется найти min\max? А если выражение более сложное, чем просто сложение по аттрибуту (например сложение произведений - типичная задача если складываемые величины в разные единицах измерения хранятся)? А если нужно обработаь значения типа null и т.д.?
Получится крайне не универсальное, дорогое устройство всего лишь с одной функций, а с учетом того, что данные еще туда нужно как-то передать, то для типичных задач СУБД это будет неприменимо, т.к. быстрее будет сразу все посчитать, чем пользоваться таким устройством.
4 янв 07, 23:00    [3608027]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
UK0IAI
Member

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


Локшин Марк

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


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

Локшин Марк

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Интересно - куда можно при этом зайти :-))))))))))
5 янв 07, 11:35    [3608681]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
UK0IAI
Первая - наверно такая, что обычная программа, может быть подвергнута процедуре parse (так как это делает субд с запросами) на предмет проверки возможности параллельных вычислений. И затем она должна делать свое execute.
Кстати, определенный уровень параллелизма уже обеспечивают современные процессоры, но то, что хотите Вы - это уже задачи из области ИИ.
Чтобы представить, во что превращается автоматизация распараллеливания программы написанной на алгоритмическом языке даже в простых случаях - прочитайте, например
http://www.books.ru/shop/books/30896
Дальше - вообще какие-то фантазии идут...
5 янв 07, 12:10    [3608769]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
UK0IAI
Member

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


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

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

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

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

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

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

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

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

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

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

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

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

Интересно однако....
5 янв 07, 14:06    [3609011]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
UK0IAI
Member

Откуда: питер
Сообщений: 13567
в развитие воображения...

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

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

Ну и что???
5 янв 07, 14:16    [3609039]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
Dried Gagarin
Member

Откуда: Kaluga, Russia
Сообщений: 527
UK0IAI
в развитие воображения...

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

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

Ну и что???


автор
ORACLE developor/DBA


Мосье, разрешите, пожалуйста, использовать цитаты из вашего текста, как доказательство, до чего может довести изучение оракла неподготовленным мозгом.
6 янв 07, 14:15    [3610691]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
UK0IAI
Member

Откуда: питер
Сообщений: 13567
Dried Gagarin
UK0IAI
в развитие воображения...

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

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

Ну и что???


автор
ORACLE developor/DBA


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


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

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

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

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

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

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

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

Я не знаю ...пока.
8 янв 07, 13:05    [3613122]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
miksoft
Member

Откуда:
Сообщений: 38919
UK0IAI
Поэтому, мне стало интересно (по триз) подумать - а зачем? А зачем иметь абсолютно точный результат. Путь компьютер выдает приближенный, но быстро!!! (мгновенно). И что тогда будет???
Это уже было! И, в значительной степени, прошло...
Почитайте про аналоговые ЭВМ. В частности, они давали приближенное решение многих диффуров значительно быстрее, чем дискретные ЭВМ 20-летней давности.
8 янв 07, 13:18    [3613149]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
UK0IAI
Member

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


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

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

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

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

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

Ну и так далее...
8 янв 07, 16:11    [3613434]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
UK0IAI
2. Задача на сортировку (в системе из n-процессоров, сортировка может быть произведена в n-1 раз быстрее).

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


Насколько я помню, да можно. Разрабатывались специальные алгоритмы для этого дела.
Сцылку разумеется не дам
8 янв 07, 16:43    [3613467]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
miksoft
Member

Откуда:
Сообщений: 38919
Gluk (Kazan)
UK0IAI
2. Задача на сортировку (в системе из n-процессоров, сортировка может быть произведена в n-1 раз быстрее).

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


Насколько я помню, да можно. Разрабатывались специальные алгоритмы для этого дела.
Сцылку разумеется не дам
А можно хотя бы немного подробностей насчет "можно" для пункта 3?
мне казалось, что передача переноса из младших разрядов старшие - последовательная операция...
8 янв 07, 17:20    [3613526]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
miksoft
мне казалось, что передача переноса из младших разрядов старшие - последовательная операция...


Только выполнять ее можно параллельно для всех переносов, пока все переносы в 0 не превратятся
8 янв 07, 17:30    [3613536]     Ответить | Цитировать Сообщить модератору
 Re: Раскритиковали в пух и в прах. Проблема функции SUM.  [new]
miksoft
Member

Откуда:
Сообщений: 38919
Gluk (Kazan)
miksoft
мне казалось, что передача переноса из младших разрядов старшие - последовательная операция...


Только выполнять ее можно параллельно для всех переносов, пока все переносы в 0 не превратятся
Именно "пока" и превращает перенос в последователную операцию...
Можно "на пальцах" на примере 999999+1 ?
8 янв 07, 17:35    [3613542]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить