мощные процессоры - это отвратительно

> Для сборки мира за шесть секунд при загрузке компа.

Такой скорости за приемлемые деньги в ближайшие лет 10-15 не будет даже близко, по любому. Как не будет распознавалок капчи и прочих "ах если бы". А раз не будет такого, то и нечего вообще дёргаться по этому поводу.

Как там с 1080p видео в h264? Не тормозит? Ну хотя бы 720p.

> Как там с 1080p видео в h264? Не тормозит? Ну хотя бы 720p.

Вы его ещё найдите такое. И вообще этим должна заниматься в значительной части видеокарта.

Я же сказал, чем ближе к оригиналу, тем лучше во всех перечисленных мной качествах. Но на асме весьма затруднительно заделать серьезный проект. А на С++ гораздо проще. Я своим высказыванием выражаю крайнюю антипатию к новым (относительно ессно) веяниям в софтостроении, как то .net, например. Да - удобно, да - быстро сделать, но качество от этого страдает в той же степени.

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

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

>Я своим высказыванием выражаю крайнюю антипатию к новым (относительно ессно) веяниям в софтостроении, как то .net, например.

Все гусары с мотором были вытеснены более совершенными формами производства. Современные средства разработки дают возможность вовлечь в производство людей средней и низкой квалификации при весьма приличном качестве продукта. Это как штамповка против ручной ковки.

1. Кажись, у мелкомягких в MSVS была специальная утилита, которая умела загружать процессор/память/диск с целью проведения исследований поведения программ в жёстких условиях.

2. Чем быстрее у программиста процессор, тем быстрее компиляция, а значит, быстрее отладка и исправление багов.

> Да - удобно, да - быстро сделать, но качество от этого страдает в той же степени.

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

Сейчас нам расскажут что-нибудь про кованную ограду Летнего Сада...

Вот именно. Вместо качественного продукта теперь принято выпускать продукцию "вполне приличного качества".

> Чем проще (на вид) среда создания программ, тем более некомпетентные люди берутся за программирование.

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

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

>Кажись, у мелкомягких в MSVS была специальная утилита, которая умела загружать процессор/память/диск с целью проведения исследований поведения программ в жёстких условиях.

Квоты пропиши, чудило.

>Оно делается чтобы некомпетентный человек мог при необходимости для себя что-нибудь запрограммить

Плюс стопицот. Однако после этого он начинает считать себя компетентным и берется писать ОС на дельфи.

> Однако после этого он начинает считать себя компетентным и берется писать ОС на дельфи.

Про ОС понятно что юмор, но в целом дельфи для больших проектов очень даже пригоден. Та же FL Studio полностью на дельфях написана.

Фишка в том, что "он начинает считать себя компетентным".

2 Sun-ch:

Я не против прогресса (двумя руками за я бы даже сказал). Я выражаю антипатию к КОНКРЕТНЫМ поделкам КОНКРЕТНЫХ людей.

2 anonymous (*) (17.01.2008 14:02:29)

Я видимо просто некорректно выразился, я опять-таки про частный случай. Был опыт ваяния системы документооборота на предприятии с использованием быдлоделфи + oracle. Результатом явился настолько сложный проект, что он даже в делфи через раз открывается (access violation постоянно, причем в самой IDE). Львиная доля вины в этом естественно в кривизне моих рук, но извините, что это за IDE которая не может АДЕКВАТНО реагировать на действия программиста, причем написана она на том же VCL, который для построения программ используется.

а мне нравитцо мой композитный DWM с кучей раскрывающихся менюшек, панелькой из висты и все это на розовом фоне моей либимой группы Аматори ...

> Вместо качественного продукта теперь принято выпускать продукцию "вполне приличного качества".

Точнее, вместо "продукта ручной работы" принято выпускать "массовый продукт приемлемого качества" :-)

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

двачую это!

кстати, чем мне можно отпрофилировать gtk/atk/pango/cairo/glib ? а то это самый тормознутый комплект в моей системе. отклик отрисовки - около 2-3 секунд (tested on LFS/Debian/Edubuntu), хотя вот Max Payne первый нормально летал на максимуме...

> Я же сказал, чем ближе к оригиналу, тем лучше во всех перечисленных мной качествах. Но на асме весьма затруднительно заделать серьезный проект. А на С++ гораздо проще. Я своим высказыванием выражаю крайнюю антипатию к новым (относительно ессно) веяниям в софтостроении, как то .net, например. Да - удобно, да - быстро сделать, но качество от этого страдает в той же степени.

Я как то писал программу для неких своих расчетов

Сперва нп ЦПП потом на СИ на СИ оказалось быстрее на порядок

> Шо, и их затормозите до Cel450? O_x

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

>что он даже в делфи через раз открывается (access violation постоянно

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

Проблема не в процах и не в софте, а в XML, лузиры. Читайте интервью с Грегом Кроах-Хартманом или Эндрю Мортоном, где они оттрейсили запуск Гнома и охерели от того, что считывание и парсинг XML занимали >85% времени.

Помнишь закон 80+20? Теперь вспомни вульгарный вариант теории оптимизации, что на что влияет в процессе написания софта и насколько сильно. А самый медленный компонент - это в любом случае HDD, поэтому и нет никакого толка от оптимизации.

уважаемый Гхарик, просьба не считать всех дебилами. Я говорю о тормозах которые после загрузки.

>gtk/atk/pango/cairo/glib

угу. мне тоже интересно.

нас слабых компах gtk отвратительно работает. 

топ тормознутых тулкитов:

1 gtk
2 qt 4 (все говорят что стал быстрее, а вижу что медленее)
3 qt 3 (самый быстрый)

> считывание и парсинг XML занимали >85% времени.

херасе О_О ждем ответа гика и других гномопоклонников.

http://ols.108.redhat.com/reprints/jones-reprint.pdf

> оттрейсили запуск Гнома и охерели от того, что считывание и парсинг XML занимали >85% времени.

надо было XML в Sexprы и в компилированный Лисп компилировать.

>а вот про размер бинарника это уже извините - по сравнению с асмом тут любой ЯП и компилятор будет просто в жопе.

Давным-давно видел компилятор "Странник" (Си-Модула-Паскаль) Там размер бинариков был от 4х кбайт. Конечно, хелловорд на асме будет раз в 100 меньше но для боьшинства приложений это некритично =) Сейчас используемый фреймворк гораздо сильнее влияет на размер (да и скорость) бинарика чем ЯП

>Как там с 1080p видео в h264? Не тормозит? Ну хотя бы 720p.

Пень Е2160 (частота 1,8 гГц) - не тормозит =)

> херасе О_О ждем ответа гика и других гномопоклонников.

А ты думаешь что под кедами лучше? Да там тот же самый XML и куда большая задница, вызванная общей кривизной кода и отсутствием кэширования в бакенде типа GConf. Поэтому Гном тормозит на загрузке, а кеды тормозят всегда! ;)

> Просто в наше время есть выбор, что важнее: скорость разработки или малое потребление оперативной памяти/процессора.

> И не надо все смешивать в одну кучу...

Ненадо вот этого мне тут. Быстрая разработка через задницу позволяет сделать быдлокод. Быстрая разработка "как надо" позволяет сделать _оптимизируемый_ код с возможностью поддержки третьими лицами.

Медленная разработка отличается от быстрой тем, что при медленной разработке проходит этап полного тестирования с оптимизацией.

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

> ГТК кирриллическое о с ударением большинством шрифтов криво рисует :)

Странно у меня ФФ, гном и всё видно нормально. Что я сделал неправильно?

Дорогой товарищЪ! Я в глаза видел далеко не только делфи. И писал для души исключительно на C/C++. И писал не хелоуворлды далеко. На асме бинарники меньше (в общем случае), но и в той же MSVC путем настройки компилятора и линковщика можно сделать бинарник с обычным MessageBox размером меньше 1кб (около 900 байт получалось), это вместо ~10-20кб при стандартных настройках.

Если срезюмировать, то все решает радиус кривизны рук кодера.

>> ГТК кирриллическое о с ударением большинством шрифтов криво рисует :)

> Странно у меня ФФ, гном и всё видно нормально. Что я сделал неправильно?

Какой шрифт? У меня нормально работают, если правильно помню, только Arial, Courier New и Times New Roman. Говорят, ещё Tahoma. Какие версии Cairo, Pango и GTK?

Хотя, судя по http://bugzilla.gnome.org/show_bug.cgi?id=360189, количество шрифтов нормально работающих с последними версиями Pango и GTK возросло.

> А ты думаешь что под кедами лучше? Да там тот же самый XML и куда большая задница, вызванная общей кривизной кода и отсутствием кэширования в бакенде типа GConf. Поэтому Гном тормозит на загрузке, а кеды тормозят всегда! ;)

4.2 Гуглить по слову kbuildsysoca

> Поэтому Гном тормозит на загрузке, а кеды тормозят всегда! ;)

4.2 :) у меня на ноуте гном чуток медленнее на глаз работает чем кеды.

Да чем вы там все занимаетесь? На древнючем пятилетнем атлоне 2000 512рамы тормоза наблюдаю.... блин, да вовсе не наблюдаю. Даже когда картинки рендерятся.

Процессоры - это отвратительно! Нужно законодательно запретить обрабатывать данные чем-то иным кроме своего моска.

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

Рассказывай, ага.... Запусти Azureus (Java) и какой-нибудь Deluge (Python). И поставь на раздачу ДВД-диск. И сравни время, за которое произведет проверку файла тот и другой....

> Плюс они спонсируют процессоры с тепловыделением в 100 ватт и монструозные системы охлаждения. Понятно что можно запас техпроцесса пустить в сторону "холодно и чуть помедленнее", а не в разгон до синего пламени но в готовом виде таких решений нет. Не найдёте вы нигде какой-нибудь кор-два-дуо с родной частотой в 1-1,5 ГГц.

4.2

ULV модификации с частотами 40..70% от максимальной в линейке выпускает и интель, и амд; энергопотребление у них, соответственно, раз в 4..10 ниже, чем у топовых.

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

>Рассказывай, ага.... Запусти Azureus (Java) и какой-нибудь Deluge (Python)

Рассказывай, ага, как тёплое с мягким сравнивать :)

http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=...

Чем сравнение Azureus с Deluge отличается от сравнений shootout.alioth.debian.org разжёвывать? :)

Знаешь, мне как хоум-юзеру совершенно плевать на то, как там "performance of Java 6 -server programs against some other language implementation". Меня интересует десктопный софт. И так как на жабе его немного (а юзал я и того меньше), то взял первую попавшуюся прогу --- Азуреус и сравнил с аналогом на Питоне. И решительно не понимаю, почему клиент на таком супер-пупер-перформанс-языке, который по тестам рвёт змеюку как тузик грелку, на банальной операции сливает по времени НА ПОРЯДОК....

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

В чём дело? Не те условия, не тот алгоритм, не та жава-машина, etc.... ? Буду признателен, если расскажешь, как научить Азуреус не тормозить. А потом, если останется время, расскажи, почему сравнение времени, за которое выполняется одна и та же операция по одному и тому же алгоритму --- это сравнение "тёплого с мягким".

не варик, а "Черный Ворон". Первая стратегия, в которую я в своей жизни играл :) "Черный Ворон-2" так и не вышел :( И не 7 МГц, а очень даже 3.5... И Черный Ворон работал и на 128Кб оперативки.

>И решительно не понимаю, почему клиент на таком супер-пупер-перформанс-языке, который по тестам рвёт змеюку как тузик грелку, на банальной операции сливает по времени НА ПОРЯДОК....

Я, вот, тоже не понимаю, почему у меня на машине, написанный на mono F-Spot на скроллинге больших альбомов рвёт написанный на C++ digiKam как тузик грелку. Наверное, потому что C++ на порядок тормознее, чем C#/Mono? :)

...

А ещё у меня Gajim имеет интерфейс намного более быстрый, чем kopete. Так что же, Python тоже рвёт C++? :)

Ок, даже если оставить в стороне тот факт, что я сравнивал не скорость интерфейса, а реализацию одного и того же _расчётного_ алгоритма.... Но по твоей логике получается, что тесты по твоей ссылке точно так же ни о чём не говорят, как и в случае сравнения "F-Spot vs digiKam" и "Gajim vs Kopete" %)

> Ок, даже если оставить в стороне тот факт, что я сравнивал не скорость интерфейса, а реализацию одного и того же _расчётного_ алгоритма....

А в питоне его точно нет в каком-нибудь стандартном модуле, написанного на C?

> ЗЫж Как бы мне стремно не было, но работа связана с написанием бизнес-приложений на связке Delphi+Oracle. Против второго абсолютно ничего не имею, но от делфи не в восторге совсем. Но деваться некуда - работа такая...

А какие конкретно претензии к дельфи? У вас бизнес приложение считает столько, что скорость кода на паскале становится проблемой?