Когдато Херрес высказал что то вроде того что для платформы главное уровень паралельности, а не скорость или удобство....
помоему 8.1 олицетворяет его мысли....

"размер" тоже имеет значение
http://www.buhsmi.ru/rubricator/auto/1c/91062/

представляю скорость 1С 80 на суперкомпе со 128 процессорами в конторе с 23 пользователями....

(0) Что такое "уровень параллельности"?

параллельность -> скорость + удобство

(4) глупость...
параллельное программирование более сложное и менее удобное....
например надо учитывать блокировки :( клинчи по подобные гадости...
+ новый класс ошибок к уже существующим...

(3) колличество ситуаций, когда требуется последовательное исполнение кода

(5) а разве скорость и удобство должно быть для программиста? Я надеялся, что для пользователя...

(7) с чего? параллельность - это неудобство и для пользователя и для программиста... но это масштабируемость!

(8) в конечном итоге это пользователь на себе ощущает

(9) не пользователь а сотни пользователей.... для компаний с 10-20 подключений это минус

(10) Если нет параллельности ;-)

да, говорил что-то такое
А с другой стороны говорил, что тормознутость интерпретатора не даёт развиваться типовым конфам.
И т.к. алгоритмы проведения в УПП на столько абстрактные, столько разных там условий и ветвлений, что документ проводится не позволительно долго, и приходится исхищряться со всякими отложенными допроведениями по разным разделам учёта...
Ведь скорости не хватает провести всё сразу за разумное время !

Надежда была на тактовые частоты, но они что-то предательски не хотят расти, вместо них в процессорах добавляются ядра. А толку-то нам от них ?

так что, я поддерживаю то одну, то другую точку зрения, была бы возможность поспорить :))

(12) "так что, я поддерживаю то одну, то другую точку зрения, была бы возможность поспорить :))" :)))))))))))))))))))))))))))))))))))))))))
Это называется не ПРОРОК, а ПОЛИТИК :)))))))))))))))))))))))).

(12) Мдя... конфорМист

(14) не, наоборот :)
смысл в том чтобы взять спорную точку зрения и попытаться её защитить.
Глядишь и что-то интересное обнаружится :))

(15) Тоже вариант. Нужно опробовать идею на прочность различными критиками

(12) Похоже, разрабатывая 8-ку, в 1С тоже надеялись на увеличение тактовой частоты... а развитие процев встало ввиду безперспективности тупого наращивания и отставания всей периферии

(12)По моему,"тормознутость интерпретатора" тут не при чем. Тем более, по отношению к конфам. К типовым или еще там каким либо, не имеет значения.

(18) именно тормознутость интерпретатора по факту делает невозможным перепроведение документов за сколько-нибудь значительный период... Да и проблема блокировок столь остра именно потому что на крупной базе по всем разделам учёта в УПП документ может запроста проводиться ну скажем... 10 секунд (!)

> УПП документ может запроста проводиться ну скажем... 10 секунд (!)
а кто вам обещал что универсальное решение (коим является УПП) должно работать быстро? заточите под себя конкретно...

(18)В перепроведении документов скорость интерпритатора или неинтерпритатора мало чем отличается. Там львинную долю занимает взаимодействие с БД или кривые руки ваятелей платформы или конфы.

(22) на платформу не надо матюкаться...
ограничимся конфами... пусть даже платформа будет в 2 раза быстрее... не поможет... :(

полная. Параллельность имеет смысл при многопроцессорности, накрайняк многоядерности. Причем если можно распределить параллельные участки. В свок время писал для свежескизженных для оборонки транспьютерных матриц. Мозги закипали. Приложенный ОККАМ никуя не распараллеливал автоматом, даже при прямом задании конфигурации. Приходилось ручками. С В8 трабла похлеще. 1С явно ориентировалась на тупой рост тактовых и шинных частот. Резко увеличивающийся нагрев и рост потерь на излучение монтажом поставили на этом пути крест. Гипертрейдинг оказался засадой, так как приложение впадало в ступор при "исчезновении" только что свободного вычислителя (он все-таки реально один), "распараллеливать" таким образом удавалось исключительно разнородные задачи, потому и прог с гипертрейдингом всего ничего. Многоядерность содержит засаду в степени унифицированности кэша (многопроцессорные вычислители на х86 страдают особо длительным переключением между задачами, это связано с переключением контекста = перезагрузка кэша). На THG.RU сравнили в этом смысле АМД и ИНТЕЛ. Результат оказался весьма примечательным: в одноядерном варианте Интел Коре уделывал АМД по самые помидоры, в двухъядерном расхождений практически не заметили. А ведь Интел рекламирует ОБЩИЙ кэш на оба ядра, в отличие от АМД. Т. е. процесс перекачки кэша (или его сегментов) сохранился. В итоге появляется куча приблуд, позволяющих вручную распределять процессы по ядрам. На ноуие КореДуо со встроенной графикой попробовал распределить по ядрам: всю графику на одно ядро, остальное на второе. Как итог в играх скачок производительности минимум на 20%. Затем переназначил одно ядро на дисковые операции, остальное на второе. Как итог: скорость перепроведения в 1С77 возросла более чем вдвое. Однако испытанный геморрой довел до полного озверения. Хорошо хоть само распределение сохраняется в виде сэйвов (...несовместимых между программами). С трудом представляю себе прогов 1С, пишущих движки под 1, 2, 4 ядра. Это требует отсутствующей у них квалификации. Вдобавок VS явно процессы реально не параллелит. В8 на принудительное распараллеливание не проверял.
.
ИТОГ ИМХО 2/4 ядра реально при наличии окуенного количества процессов в системе. Куда более эффективно принудительное распределение процессов по ядрам  сторонними утилитами. Что и подтверждается: год назад таких тулз не было вообще, сейчас только фришных 4 штуки.
.
ПС Для затравки самая первая мною обнаруженная программа, простейщая
http://www.ice-graphics.com/ICEAffinity/IndexR.html

Исправления
.
Вдобавок VS без явного указания процессы реально не параллелит
.
2/4 при наличии окуенного количества процессов в системе при распараллеливании автоматом реально нифига не дадут (все сожрет переключение контекста, причем чем лучше оптимизировали винду, тем большие тормоза от переключения контекста)

(24)  >>На THG.RU сравнили в этом смысле АМД и ИНТЕЛ...

Ссылочку не подкинешь...

(21) говорят, навижн работает многократно быстрее
при этом он, несомненно, более универсален

1С позволяет работать в кластере серверов. Т.е. контроллер кластера распределяет выполняемый код на разные сервера, которые могут выполняться как на разных ядрах, так и вообще на разных компьютерах.

(27)? да навижн универсальней (более низкоуровневый вариант работы с базами), но... читай здесь - совершенно свежая ветка
Сижу юзаю навижн http://www.kuban.ru/cgi-bin/forum/forum9.cgi?view=0&page=3&ask=281594

а еще более универсален Delphi....
а Navision менее универсален...
а 1с еще меньше...

delphi быстрее чем Navision а 1с еще медленнее....
только скорость в 1,5-2 раза не так принципиальна как параллельность...
на Navision проблем с блокировками как и на дельфе если не переделывать намного больше...

(29) спасибо, обалденная ветка

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

(29) Не помню! Просмотри раздел Процессоры. И на 3Dnews/Хобот слазь. Это материал полугодовой давности. Я чего завелся: тесты одинаковые, а выводы разные. Ну и начал сам пробовать. В итоге ИМХО без тулзеней принудительного распараллеливания на 2/4 ядрах фиг что получишь. Кластеры оно конечно хорошо, но много ли потребителей?

(32) будет много...