Ответ на »сообщение 6162« (Илья Ермаков)
___________________________


Меня терзают смутные сомнения - уж не "подточен" ли компилятор под конкретный набор тестов... Была же такая история с Sun-Java.

Гнилые отмазки ;) Впрочем я не против, если info21, как ярый противник оптимизирующих компиляторов, предоставит исходники "реальной задачи" на которой он сравнивал BB и VC6 и делал далеко идущие выводы :)

Ответ на »сообщение 6161« (AVC)
___________________________


Интересно, как Вы объясняете такой фактор?


Интеловский компилятор оптимизирует плавающую точку. Но когда я это говорил, то меня упорно не хотели слушать :) Может конкретным циферкам поверите :)


Очень любопытно было бы посмотреть на ассемблерный файл (как результат работы интеловского компилятора).

На работе осталось. Если интересно самим покрутить, что можно пойти на intel.com и скачать компилятор (как это сделал я).

>>>Ничего кроме работы над своими задачами. Инструмент должен работать, а не обслуживаться с ритуальными
>>>плясками и томиками Страустрапов в качестве настольных книжек :-)

Об этой проблеме блестяще сказано у Вирта в его работе "Долой жирные программы".
"Ни для кого не секрет, например, что основные фирмы-производители программного обеспечения осуществили - и с успехом! - массированные инвестиции в сервисное обслуживание, наняв сотни консультантов, призванных круглосуточно отвечать на звонки пользователей... Конечно, клиент, который платит - вперед! - за договорный сервис, являет собой более стабильный источник дохода, чем клиент, который полностью самостоятельно освоил продукт... следовательно, можно сформулировать еще один "закон": зависимость клиента более доходна, чем его обучение." - конец цитаты.

Лучше не скажешь.

Ответ на »сообщение 6146« (pepper)
___________________________

Ответ на »сообщение 6103« (AVC)
___________________________

Я ж говорю - ну не оптимизирует нормально VC плавающую точку. Возьмите интеловский компилятор. На моей машине:
BB - 974.9 MIPS (лучший результат из нескольких)
VC 2005 - 1379.3 MIPS
Intel 10.1.011 - 8000 MIPS

8000? (да ещё так точно, по сравнению с предыдущими...)

Помоему это бред. Такой результат никакая оптимизация не даст (ежели она на этот тест не заточена). Какие параметры у вашей машины?

И я согласен с AVC - очень хотелось бы посмотреть на сгенерированный код...

Ответ на »сообщение 6161« (AVC)
___________________________

Ответ на »сообщение 6146« (pepper)
___________________________
Интересно, как Вы объясняете такой фактор?
Очень любопытно было бы посмотреть на ассемблерный файл (как результат работы интеловского компилятора).
Меня терзают смутные сомнения - уж не "подточен" ли компилятор под конкретный набор тестов... Была же такая история с Sun-Java.

Ответ на »сообщение 6146« (pepper)
___________________________

Я ж говорю - ну не оптимизирует нормально VC плавающую точку. Возьмите интеловский компилятор. На моей машине:
BB - 974.9 MIPS (лучший результат из нескольких)
VC 2005 - 1379.3 MIPS
Intel 10.1.011 - 8000 MIPS

Вот теперь и посчитайте фактор...
Интересно, как Вы объясняете такой фактор?
Очень любопытно было бы посмотреть на ассемблерный файл (как результат работы интеловского компилятора).

Ответ на »сообщение 4283« (ASU)
___________________________

Ответ на »сообщение 4259« (AVC)
___________________________
Они занимались системным программированием (как оно обычно понимается, т.е. созданием программной архитектуры), а Вы -- созданием прикладной программной системы.
Хм?.. Я уже пообещал создать отдельную тему и там рассмотрю... не прикладной пример, если не будет возражений, разумеется.
Александр Сергеевич, Ваши сомнения относительно нужности отдельной темы ещё не развеялись? Вроде бы и возражений не было.
IMHO, построение систем становится всё актуальнее. Думаю, многим было бы интересно и полезно это обсудить.

Ответ на »сообщение 6157« (Geniepro)
___________________________


...Если заказчик увидит всего лишь один блок, он спросит -- а за что я плачу стока денег? А вот увидит кучу блоков и глупых вопросов у него не возникнет..." :о)

*заинтересовавшись вопросом, заглянул в системный блок своего компа.
Ба, да эта коробка почти пустая! :)

Ответ на »сообщение 6153« (Илья Ермаков)
___________________________

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

Да, конечно, но! Вспомните статью Джоэла Спольского, в которой он описывал, как журналист оценивал простой компактный текстовый процессор. Заключение этого журналиста было примерно таким:

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

Вот так же и большинство знакомящихся с Оберонами и Блекбоксом рассуждают: "Того нет, этого нет, а вручную их делать -- когда я ещё их сделаю... Эх, вернусь-ка я в дельфу, где всё это давно уже есть..." :о)


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

Вот абсолютно несогласен! Вы совершенно в корне неправы!
Как-то мы делали тренажёры для нашего МинОбороны, так там была куча почти пустых блоков, которые все можно было бы уместить в один такой же корпус. А на вопросы к начальству был один ответ: "Нифига, пусть будет как есть. Если заказчик увидит всего лишь один блок, он спросит -- а за что я плачу стока денег? А вот увидит кучу блоков и глупых вопросов у него не возникнет..." :о)