Да уж, вам правительство не приплачивает случаем?:) Приравнять потребление на электричество к налогу на роскошь, это ж надо додуматься до такого. Вы подумали, по каким принципам вообще нормы рассчитываются? Если взять бабушку с одним холодильником, тв и котом в придачу за основу, то тогда все окажутся потребителями "роскоши")) Я уже не говорю о жителях сельской местности или тех регионов, у которых светлая часть суток гораздо меньше, и которые вынуждены потреблять больше - им тогда сразу можно дефолт объявлять.
А монополия это всегда плохо, и неважно государственная она или частная...

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

Себестоимость 30р? Это откуда данные то? Что-то я сомневаюсь, что такой высокотехнологический продукт, как память может стоить 1$/4GB . XD Не говоря уже о прочих расходах.

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

Да я как-бы не программист, чтоб этим заниматься постоянно. Сейчас почти ничего не пытаюсь писать, потому что не умею получать доступ к железу в WinXP и позже, да ещё с приемлемой скоростью... А раньше вот несколько примеров, может и несеръезных:
1. Когда-то, когда ещё вместо монитора использвал телевизор "Электрон", столкнулся с тем, что S3 видеокарта включала текстовый режим в чёрнобелом виде. И я не знал что делать. Хорошо что нашёл EXE файл который переключал режим из чёрнобелого в цветной и наоборот. Она занимала несколько килобайтов. Долго разбирался что она делает, в конце-концов нашёл - она всего-лишь инвертировала один бит в ДОСовских переменных - написал свою программу в несколько десятков байтов...
2. Когда-то давно мне стало интересно как работает программ mars.exe (5 килобайтов). Дизассемблировал её и заменил повторяющиеся конструкции циклом. Программа уменьшилась вдвое! (правда я так и не разобрался, что делать, чтоб не компилировались пустые сегменты, поэтому после компиляции приходилось обрезать лишние 100+ кб вручную).
3. Как-то на заводе программиста заставили извращаться со спящими режимами монитора из QNX чтоб монитор всё время не горел, а у него не получалось. Хорошо что к той встроенной видеокарте был PDF файл - нашёл регистры усыпления, и написал функцию из нескольких строк. Такой вариант заработал, но потом зачем-то вместо этого сделали тумблер для подсветки
4. По эффективности использования памяти я претендовать на что-либо не могу, зато мои программки занимают совсем немного места на диске. _например_

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

jek1975 проблема в том, что почему-то считается, что когда ручное изделие стоит 1кк, а точно такое же фабричного производства - и хуже (потому что стандартизовано) и дешевле намного - это норм, а если прога жрет не 640к - то все, приехали. Дело в том, что если 30 лет назад, или даже 20, программка - это консольное приложение, реже - игрушка в псевдографике, где исходники занимали чуть меньше, чем в скомпилированном виде, то сейчас всем подавай "шоб в тридэ и с кудой". У меня папка с проектом весит 700мб: исходные тексты + необходимые dll. Возрастают требования - происходит переход от ремесленничества к мануфактурам, а далее - к фабричному производству, где не учитываются индивидуальные предпочтения заказчика (то есть программы довольно прожорливы), но зато обеспечивается скорость разработки приемлемая. Возьмем тот же андройд 2.3.6 - это 2кк строчек на Java. Каждая строчка на Java примерно 5-10 строк на C, каждая строка на С - еще столько же ассемблеровских команд. То есть получаем в 25 раз больше строк. Не беря во внимание какие-нибудь доп. трудозатраты вроде танцев с бубном с аппаратной совместимостью ассемблера и крайней ограниченностью использовать мнемонические обозначения переменных, получаем трудозатраты в 25-30 раз больше. То есть если андройд ударными темпами сделали за 1-2 года, то на асме это заняло бы лет 50. И кому бы он через 50 лет был нужен? Если я вам скажу "окей, будет идеально вылизанная винда, давайте деньги, лет через 100 получите", вы мне что скажете?

Лучше криво, но сейчас, чем хорошо, но не в этой жизни.

Есть хорошая цитата на тему срача "пишите все на ассемблере, он шопипец оптимизированный":

Ты пишешь явный бред. Что по обьему кода, что по скорости разработки. Писать тот же Андроид на сишке было бы далеко не медленней.



Вот только тут 3 мкс, там 3 мкс, а в итоге по капелькам выходят такие тормоза, с которыми топовые процессоры не справляются.

// У меня временами такое ощущение, что такую вещь, как профайлер, большая часть погромистов в глаза не видели.

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


еще раз: время разработки решает. Как и сопровождаемость. Это - ключевые параметры. А скорость - сколько угодно, пока она не влияет на эти два. Говорить, что разработка на сишке не сложнее.. Ну, я даж не знаю. С интересный и лаконичный язык, но в нем нету очень многого. Языки же развиваются не для того, чтобы "нагибать топовый процессоры". А профайлером, опять же, оптимизируется 5% кода, что вполне допустимо, когда решение уже собрано, а не в процессе разработки.

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

По мне так социальные нормы это вполне правильно. Тем более рассчитываются они вполне по божески. Например у меня 3 взрослых человека + ребенок потребляют в среднем 200-250 КВт (и это с электрической плитой). Если верить обещаниям, что для тех кто укладывается в нормы цена будет ниже, то я только выиграю. И я, например, очень ценю то, что мой компьютер в простое потребляет всего 60-70 Вт в час ("в простое" он трудится в среднем 21 час в сутки).

Тоже ничего страшного не вижу. У нас в одной комнате свет горит в среднем 10 часов в сутки. Обычные лампочки, суммарно 300 Вт. За месяц получается 90 КВт - что тут ужасного? А ведь можно энергосберегалки поставить, тем самым снизив потребления в 4-5 раз.

Вы не поверите. Но если бы вы программировали демки под Spectrum, то знали бы, что простенькая программка на пару килобайт специально размазывалась под всю доступную память для того, чтобы оптимизировать вывод на экран. Например, полное обновление изображения на экране за 70000 тактов (1/50 секунды, так как проц был 3.5 Мгц) только так и делалось (самая простая инструкция с 8-битным регистром "кушала" 4 такта). В моде были разные извращения вроде записи в память данных с помощью PUSH (сохранение в стек), так как оно требовало "всего" 10 тактов, и так далее. В программе mars было то же самое, если что. И на машинах того времени с циклом она бы просто еле ползала.

CDG.Axel, с такой оптимизацией, как в спектруме, конечно ПК тягаться тяжело. Я вкурсе, каких там извращений стоили красота и скорость. Тоже пытался писать быстрые программы (отдельное спасибо тоненькой книжке Николая Радионова о ксорках, дисковых защитах и т.п. - вот бы о ПК кто-нибудь такое написал, хотя нет пишут, например где-то читал о многопоточном шифровании ГОСТ, где автор в несколько раз увеличил скорость - но обычному человеку такое применять некуда - современные языки плохо приспособлены под ассемблерные вставки. Вот даже у меня лежит кусок 100 кб ASM кода из гугло-планеты, который что-то шифрует, и сейчас такого уже не наковыряешь из новых версий - оно на 100500 кусков порезано в новых версиях, но я не понимаю как ЭТО вставить в код Delphi, и помочь никто даже не захочет), хоть и короткие (и даже помню что там разная скорость выполнения в разном адрессном пространстве, а быстрее всего из SRAM, которое можно воткнуть вместо ПЗУ принтера). Там реально каждый такт оптимизировать приходилось! (Например была мечта подключить настоящую AT клавиатуру, но я не знал как она работает. Пришлось допаять свой порт, и оцифровывать с него "осцилограммы" нажатий. Оказалось там формат данных обычного RS-232, только синхронный. И потом я даже схему преобразователя (без процессора) придумал, но делать не стал - так как понимал, что она с недостатками...).
Но мне вопрос задавали не по поводу спектрума, а по поводу того "а ты сам хоть что-то оптимизировал, что винду ругаешь?". Да оптимизировал, и даже несколько раз из готовых программ пытался выкинуть встроенные как матрёшка друг в друга инсталяторы, "лишние" языки и картинки в стиле *.BMP, которые какие-то уроды вшивали туда (типичная такая программа "драйвер к звуковушке кривотива Xi-Fi") - экономия колоссальная, на коде так сэкономить не получится никогда в жизни .

На демки для С64 посмотри, особенно из последних. Там год долбаться будешь - дополнительных тактов не выжмешь.
Ну и Titan - Overdrive с Evoke 2013 для Sega MD.

devl547, посмотрел юу-туб прикольно, ну под ПК тоже что-то пытаются делать см. тут: demoscene.ru, особенно раздел "64кб" (что-то не могу найти его сейчас - видимо переименовали), (кстати где-то в 2003 году специально мощную видеокарту купил чтоб демок оттуда посмотреть) но это только посмотреть прикольно. А полезных программ с такой же плотностью полезного кода и эффективности ещё поискать нужно. Из того что я пользуюсь только 7z пожалуй. Остальное представляет из себя мегабайты мусора. Я вот даже сомневаюсь, что апгрейдить комп целесообразно - новые винды не впечатляют, а Линукса всё ещё боюсь (в том смысле, чтоб не случилось как с ДОС, когда кучу всякого о нём узнал, пожалуй кроме выделения памяти под драйвера и программы, а он раз и сдох - все знания оказались бесполезными)

Компилятор С давно уже генерирует более эффективный код, чем любой программист на асме

В последней версии дельфи, с которой я когда-то общался (это вроде была Delphi 7) ассемблерные вставки делались легко и просто. К тому же в них можно было обращаться к переменным (всем разыменования делал компилятор). Было реально удобно, и я этим часто пользовался, особенно видел, если стандартный компилятор клепает неоптимальный код. Разумеется, только для критичных по времени выполнения моментов (последний раз это была "длинная" арифметика, с числами по 1000+ знаков).

Еще есть uTorrent... И, пожалуй, всё)

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

CDG.Axel К примеру вы можете написать обычный цикл на ассемблере, он скомпилируется как есть: метка → логика → условие → прыжок и вот этот самый прыжок, довольно дорогая операция. На С вы можете написать такой же цикл, но с некоторыми настройками оптимизации, компилятор развернет этот цикл так, что все значения для условия просчитаются на этапе компиляции и перехода как такового просто не будет. Для процессора быстрее идти и выполнять инструкции линейно, а не прыгать по памяти.

Разница в производительности между ассемблером и скомпилированным си в настоящее время никогда не бывает узким местом для 99% процентов задач (даже реального времени). Остальной 1% — это хитровывернутая архитектура процессора и/или узкоспециальные алгоритмы, оптимизация которых до сих пор неизвестна компилятору.

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

Мантра «ассеблер быстрее си, си быстрее перла, перл быстрее пейтона» — очень вредна, на самом деле, как любая другая глупость. Ассемблер уже далеко не всегда быстрее си, а пейтон почти никогда не медленнее перла.

Psilon никто не спорит с тем, что компиляторы сегодня умные. И вы правы насчет 99%. Но всё-таки бывают моменты, когда компиляторы косячат или не понимают, что от них хотят. Но самый большой плюс компиляторов даже не в возможностях оптимизации, а в том что они умеют задействовать технологии процессоров, которые программист может поленится реализовывать (или просто не знать). Например, когда я писал длинные числа (нужно было ОЧЕНЬ быструю работу с ними), я жестко пробил в коде использование SSE2 (компилятор ну никак не хотел его юзать, хотя я даже переменные объявлял с расчетом под это). В результате мой код просто не работал, если процессор не поддерживал SSE2 (сейчас неактуально, а тогда было полно атлонов на SocketA). Сейчас, когда появлись AVX2 мой код еще можно было бы ускорить. И в случае с кодом на С досточно перекомпилировать его с рекомендацией использовать инструкции. Правда я до сих пор не уверен, что компилятор до этого дорос, и сумеет задействовать AVX2 правильным образом (SSE2 в своё время, например не сумел, как я ни старался).

Про развороты циклов и очистку конвеера при ошибке предсказания можно мне не рассказывать. В своё время я достаточно занимался демомейкерством под Spectrum, а потом чуть под PC (тогда правда даже P4 не было). И очень хорошо знал архитектуру процессора и особенности его работы. Сейчас я, конечно, отошел от этого (переориентировался из разработчиков), и настолько глубоко архитектуру новых процов не знаю. Но людей, которые пишут серьезные вещи в мире предостаточно, не смотря на то, что большинство программистов в наше время даже винду себе установить не могут (у нас на работе половина таких).

На работе не пускает на files.mail.ru, а дома, скорее всего, не доберусь. Но по Delphi 7 полно профильных форумов, где наверняка смогут помочь. Правда я рекомендую забить на D7 (это же древнющий артефакт), перейдя на VS C++ или С#. В крайнем случае на Delphi XE4. Заодно сможете относительно легко портировать свои приложения на iPad ).

На старых сборниках софта, кроме шуток. Сейчас качество принесли в жертву скорости разработки.



pouet.net же.



У разработчиков сейчас мантра "Копипасть-копипасть, на оптимизацию нам класть"

devl547 оптимизация к копипасте имеет скорее прямое отношение, чем обратное. Дешевле же заинлайнить функцию в 100500 местах (причем не директивой inline, а руками), чем прыгать по вызовам функций Code monkey это диагноз.

Psilon насколько я помню, в тех же VS C++ короткие по коду функции уже давно инлайнятся автоматически. Потому что пихать в стек параметры, делать вызов, доставать значения из стека, что-то с ними делать, и всё разматывать назад по тактам значительно более накладно. А на размер программы сейчас уже никто не обращает внимания.

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

CDG.Axel я в курсе.Я и говорю, миллион раз уже встречал код, где вместо выноса в функцию просто делают копипаст, потому что не нужно в 100500 местах уже кривого кода отлаживать и делать нормально. Что поделать...