LINUX.ORG.RU
ФорумTalks

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


0

0

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

смешно сказать - одно ядро core 2 duo быстрее селерона 450 в ~15-20 раз, и это при том, что на этом селероне можно вполне сносно жить (всё кроме игр старше 2003его и h.264 видео на 1280). на core2 GUI unresposiveness говняного софта почти незаметен, на нем не определить какой софт писали лентяи/дебилы.

нужно законодательно :) запретить программистам гуи приложений пользоваться чем-то, что мощнее 500 селерона.


Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

m1rag3 ★★
()
Ответ на: комментарий от m1rag3

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

anonymous
()
Ответ на: комментарий от m1rag3

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

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

Sun-ch
()

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

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

anonymfus ★★★★
()
Ответ на: комментарий от m1rag3

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

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

anonymous
()
Ответ на: комментарий от Sun-ch

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

svu ★★★★★
()
Ответ на: комментарий от Sun-ch

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

Xellos ★★★★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()

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

AiFiLTr0 ★★★★★
()
Ответ на: комментарий от anonymfus

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от Sun-ch

2 Sun-ch:

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

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

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

m1rag3 ★★
()

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

phasma ★☆
()
Ответ на: комментарий от Xellos

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

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

no-dashi ★★★★★
()

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

stave ★★★★★
()

двачую это!

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

generatorglukoff ★★
()
Ответ на: комментарий от m1rag3

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

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

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

cvs-255 ★★★★★
()
Ответ на: комментарий от tailgunner

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

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

Legioner ★★★★★
()
Ответ на: комментарий от m1rag3

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

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

vit122
()

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

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

Gharik
()
Ответ на: комментарий от Gharik

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

zort
() автор топика
Ответ на: комментарий от generatorglukoff

>gtk/atk/pango/cairo/glib

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

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

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

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

zort
() автор топика
Ответ на: комментарий от Gharik

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

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

isden ★★★★★
()
Ответ на: комментарий от Gharik

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от anonymous

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

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

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от isden

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

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

Gharik
()
Ответ на: комментарий от mono

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

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

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

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

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

anonymous
()
Ответ на: комментарий от acheron

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

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

anonymous
()
Ответ на: комментарий от vit122

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

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

m1rag3 ★★
()
Ответ на: комментарий от anonymous

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

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

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

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

acheron ★★★★
()
Ответ на: комментарий от Gharik

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

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

gaa ★★
()
Ответ на: комментарий от Gharik

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

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

isden ★★★★★
()
Ответ на: комментарий от isden

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

anonymous
()

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

bugmaker ★★★★☆
()
Ответ на: комментарий от zort

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

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

MYMUR ★★★★
()
Ответ на: комментарий от anonymous

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

4.2

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

anonymous
()
Ответ на: комментарий от MYMUR

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

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

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

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

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

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

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

MYMUR ★★★★
()
Ответ на: комментарий от redgremlin

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

Binary ★★★★★
()
Ответ на: комментарий от MYMUR

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

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

...

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

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

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

MYMUR ★★★★
()
Ответ на: комментарий от MYMUR

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

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

gods-little-toy ★★★
()
Ответ на: комментарий от m1rag3

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

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

gods-little-toy ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.