Комментарии 113
>> Когда-нибудь они могут пригодиться для обеспечения обратной совместимости.
программе 20 лет. Жесткий у вас юмор, однако :)
Уже представил Software — археологов, которые спустя лет 50 ищут дискетки с исходниками и изучают их в попытках познать «истины древних»
программе 20 лет. Жесткий у вас юмор, однако :)
Уже представил Software — археологов, которые спустя лет 50 ищут дискетки с исходниками и изучают их в попытках познать «истины древних»
А фантасты уже придумали профессию «археопрограммист» ;)
В принципе, возможно, так и будет.
В принципе, возможно, так и будет.
палеопрограммист
Вернор Виндж, если я не ошибаюсь? ;)
я уже в воображении представляю себе археопрограммиста в потёртой шляпе и с кнутом, который декомпилирует части случайно найденного, мало до селе известного прототипа windows 3.1415 (для бродячих групп), чтобы в них отыскать пасхалку и прочитать, куда были зарыты 808 золотых двухкилограммовых слитков с отчеканенным логотипом Микрософта.
Ага, и дисертации будут защищать по раскопкам в логах и комментариях к коду…
Для меня это замечательнешая новость, ибо есть старые игрушки, где часть картинок нарисованы на QuickDraw. Иcходники — как раз то, что нужно, ибо позволят добиться пиксельной точности.
Ой :) Я думал это Макаревич на фотке :)
а по теме: раньше и правда умели «вписываться» в отведённые размеры памяти: оптимизировали, ускоряли. А сейчас почти что никто не хочет этим заниматься — «облака», да и просто мощные системы всё вытягивают. Хотя, имхо, это тупик.
а по теме: раньше и правда умели «вписываться» в отведённые размеры памяти: оптимизировали, ускоряли. А сейчас почти что никто не хочет этим заниматься — «облака», да и просто мощные системы всё вытягивают. Хотя, имхо, это тупик.
Раньше это было целесообразно, сейчас нет. Цена на ресурсы другая=)
Всё таки моё глубокое 'имхо' — что и сейчас это весьма целесообразно.
Вот, Денис, как Вы считаете, что лучше: программа, которая отжирает 20% CPU и гиг оперативки или программа, которая скромно съедает 5% CPU и 500 метров оперативы? Я уверен, что Вы проголосуете за вторую. Это разумно и очевидно, потому что Вы можете себе позволить в этом случае выполнять ещё какие-то задачи на том же оборудовании. Я согласен, что не нужно доходить до идиотизма, но оптимизация должна быть. Кстати, оптимизация сегодня — одна из целей в Гугле. Они хотят получать не просто правильный ответ на запрос, а ещё и быстрый. И достигается это не только наращиванием мощностей.
Вобщем, я согласен с тем, что сейчас это менее актуально в большинстве задач, но всё же имеет смысл.
Вот, Денис, как Вы считаете, что лучше: программа, которая отжирает 20% CPU и гиг оперативки или программа, которая скромно съедает 5% CPU и 500 метров оперативы? Я уверен, что Вы проголосуете за вторую. Это разумно и очевидно, потому что Вы можете себе позволить в этом случае выполнять ещё какие-то задачи на том же оборудовании. Я согласен, что не нужно доходить до идиотизма, но оптимизация должна быть. Кстати, оптимизация сегодня — одна из целей в Гугле. Они хотят получать не просто правильный ответ на запрос, а ещё и быстрый. И достигается это не только наращиванием мощностей.
Вобщем, я согласен с тем, что сейчас это менее актуально в большинстве задач, но всё же имеет смысл.
время программиста дороже полугига памяти в большинстве случаев.
Если программа пишется программистом для себя и будет использоваться в единственном экземпляре.
То бишь не для распространения. Как только программа пошла в свет — она нуждается в оптимизации.
нет, в оптимизации она нуждается только тогда, когда с этим проблемы.
если программа в нормальном режиме запускается раз в день на пять минут, то 500 мб вполне терпимо.
если программа в нормальном режиме запускается раз в день на пять минут, то 500 мб вполне терпимо.
А где граница «терпимо» и «слишком прожорлива»?
заказчик границу проведет
Грань действительно проводит заказчик и маркетолог. Спольски писал о том, как Excel выиграл гонку у Lotus:
www.joelonsoftware.com/articles/fog0000000245.html
Краткое содержание. В 1991 году у лотуса было 99% рынка. Через несколько лет все пересели на Эксель. Причина: новая версия лотуса была слишком прожорлива, и программеры стали её оптимизировать, на что ушли долгие месяцы. В это время команда дяди Билли наращивала функционал (да, это было время реального функционала, а не нынешних bells & whistles). При этом эксель, конечно, разбухал — и стал в результате куда жручее лотуса.
К моменту выхода обеих программ процессор 386 с соответствующим комплектом памяти уже превратился в распространённое явление, и требования экселя перестали казаться существенными. Результат нам известен.
www.joelonsoftware.com/articles/fog0000000245.html
Краткое содержание. В 1991 году у лотуса было 99% рынка. Через несколько лет все пересели на Эксель. Причина: новая версия лотуса была слишком прожорлива, и программеры стали её оптимизировать, на что ушли долгие месяцы. В это время команда дяди Билли наращивала функционал (да, это было время реального функционала, а не нынешних bells & whistles). При этом эксель, конечно, разбухал — и стал в результате куда жручее лотуса.
К моменту выхода обеих программ процессор 386 с соответствующим комплектом памяти уже превратился в распространённое явление, и требования экселя перестали казаться существенными. Результат нам известен.
Помнится со старым биллином пытались вкачать данные о звонках со всех АТС. Вся фишка в том, что время на вкачиваение одного дня занимала более суток времени :-D Там был целый ворох просчётов: устаревший язык (Аляска вроде, если не ошибаюсь, вендовый Clipper), кривой алгоритм внесения данных в базу, совершенно идиотская структура баз (например, числовые данные хранились в текстовых полях).
Из утверждения следует, что время программистов дорожает. (?)
Во-во! Именно поэтому я часто использую старый софт. Он часто ещё и лучше нового (третий ACDSee, WinAmp 2.99). Сейчас программисты не умеют делать хорошие программы, как и мало промдизайнеров, делающих хороший дизайн.
чушь!
ACDSee — попробуйте XnView
Winamp — попробуйте fioobar2000
А вообще я почти перебрался в пользователи Linux/FreeBSD. Судя по тенденции роста объёмов Windows и практически отсутствием какого-то ни было развития функционала уж лучше уйти на другую платформу, чем оставаться на Windows XP, которую скоро перестанут поддерживать. Windows использую только на работе, да и то в Virtualbox. Ну и дома иногда запускаю в ней foobar2000, чтобы музыку на мобильник перегнать (лениво с sox разбираться).
Winamp — попробуйте fioobar2000
А вообще я почти перебрался в пользователи Linux/FreeBSD. Судя по тенденции роста объёмов Windows и практически отсутствием какого-то ни было развития функционала уж лучше уйти на другую платформу, чем оставаться на Windows XP, которую скоро перестанут поддерживать. Windows использую только на работе, да и то в Virtualbox. Ну и дома иногда запускаю в ней foobar2000, чтобы музыку на мобильник перегнать (лениво с sox разбираться).
А про семерку что нибудь слышали?) уже год прошел.
Слышал и даже была у меня на ноутбуке в момент покупки. Пытался запустить игрушки, в которые тогда играл. Не получилось. Просто снёс этим же вечером и поставил Windows XP на котором всё забегало. А сейчас, как и писал выше, стоит Linux.
Когда я запускаю XP, которая у меня осталась второй операционкой, у меня ощущение, что я сделал апгрейд компа :)
Есть еще замечательный faststone. На мой взгляд, он куда гуманнее к пользователю и такой же халявный.
»ACDSee — попробуйте XnView
Первый быстрее и удобнее. А самое главное лаконичнее.
foobar2000 юзаю, но лишь как проигрыватель флака и прочего лослеса. В остальном по скорости и опять же лаконичности старый Винамп рулит ^3^
Первый быстрее и удобнее. А самое главное лаконичнее.
foobar2000 юзаю, но лишь как проигрыватель флака и прочего лослеса. В остальном по скорости и опять же лаконичности старый Винамп рулит ^3^
Я сам в своё время вроде ACDSee 2.4 использовал. Дальше обновляться не хотел.
Про Winamp не понял. Где там измерять скорость? Лакончинсть тоже с трудом понять могу. Куда удобнее управлять foobar2000 горячими клавишами и использовать несколько списков воспроизведения в виде вкладок, которые видны на полный экран (видны именно в те моменты, когда тебя интересует только музыка). Winamp тоже можно заставить то же самое сделать, но там представление информации ни к чёрту. Медиабиблиотеку в винампе в своё время так и не научился использовать, тем более я сам прекрасно знаю что и в какой папке у меня лежит.
Про Winamp не понял. Где там измерять скорость? Лакончинсть тоже с трудом понять могу. Куда удобнее управлять foobar2000 горячими клавишами и использовать несколько списков воспроизведения в виде вкладок, которые видны на полный экран (видны именно в те моменты, когда тебя интересует только музыка). Winamp тоже можно заставить то же самое сделать, но там представление информации ни к чёрту. Медиабиблиотеку в винампе в своё время так и не научился использовать, тем более я сам прекрасно знаю что и в какой папке у меня лежит.
AIMP Player попробуйте, не пожалеете
»Про Winamp не понял. Где там измерять скорость?
Имеется ввиду скорость работы. Может сейчас это и кажется смешным, но да, для меня даже скорость работы таких маленьких программ важна. Или даже наоборот — именно маленькие программы и должны работать наиболее быстро. Даже если выигрыш в 1%, это уже выигрыш. А таких ведь програмок целая куча. Вот так и получается, что мой оптимизированный старичок Атлон работает чуть ли не с такой же скоростью и стабильностью, как (sic!) современные многоядерные монстры.
А до этого у меня был Пень 200, и благодаря оптимизации, что я сам проводил, он тоже работал с той же скоростью, что Пень 2 233 друга.
»Куда удобнее управлять foobar2000 горячими клавишами
А вот тут уже дело привычки. Я привык к горячим клавишам винампа. Как бы зачем плодить сущности, если есть давно проверенный и много лет стабильно работающий софт? :) Тем более что с единственной задачей, с которой ему нужно справляться — играть мп3, он справляется отлично. Вот если бы у меня был новый Винамп, тогда да, тогда я бы согласился, что лучше за Фубаром сидеть, чем за многокомбайновым монстром, в который превратили и Винамп, и Эсидиси, и Неро. Скоро блин останеться компаниям-производителям этих софтвин выпустить по собственной ОСи. Ну так, чтоб уж никто не смог упрекнуть в том, что в их програмках чего-то нет, или что эти програмки не могут положить на лопатки современные двухпроцессорные четырехядерные компьютеры с террабайтами памяти, лол :D
Короче правильно выше человек сказал. Во всём надо знать меру, а не осваивать новые гигагерцы процессоров аки наши чиновники — бюджеты.
: )
Имеется ввиду скорость работы. Может сейчас это и кажется смешным, но да, для меня даже скорость работы таких маленьких программ важна. Или даже наоборот — именно маленькие программы и должны работать наиболее быстро. Даже если выигрыш в 1%, это уже выигрыш. А таких ведь програмок целая куча. Вот так и получается, что мой оптимизированный старичок Атлон работает чуть ли не с такой же скоростью и стабильностью, как (sic!) современные многоядерные монстры.
А до этого у меня был Пень 200, и благодаря оптимизации, что я сам проводил, он тоже работал с той же скоростью, что Пень 2 233 друга.
»Куда удобнее управлять foobar2000 горячими клавишами
А вот тут уже дело привычки. Я привык к горячим клавишам винампа. Как бы зачем плодить сущности, если есть давно проверенный и много лет стабильно работающий софт? :) Тем более что с единственной задачей, с которой ему нужно справляться — играть мп3, он справляется отлично. Вот если бы у меня был новый Винамп, тогда да, тогда я бы согласился, что лучше за Фубаром сидеть, чем за многокомбайновым монстром, в который превратили и Винамп, и Эсидиси, и Неро. Скоро блин останеться компаниям-производителям этих софтвин выпустить по собственной ОСи. Ну так, чтоб уж никто не смог упрекнуть в том, что в их програмках чего-то нет, или что эти програмки не могут положить на лопатки современные двухпроцессорные четырехядерные компьютеры с террабайтами памяти, лол :D
Короче правильно выше человек сказал. Во всём надо знать меру, а не осваивать новые гигагерцы процессоров аки наши чиновники — бюджеты.
: )
между тем я пользуюсь последней версией ACDSee и очень доволен возможностью быстро и просто отредактировать фотку без всяких фотошопов, да и катологизация если разобраться рулит.
Тоже до сих пор использую ACDSEE Classic версии 2.43, летает и самое главное — предварительно кеширует во время просмотра следующее изображение.
Для обработки же использую FastStone.
Для обработки же использую FastStone.
Раньше программы «вписывали» в 128 Кб памяти, которые использовались в современных компьютерах прошлого. Теперь программы «укладываются» в 1-2-4 Гб, которые есть на современных компьютерах-ноутбуках пользователей. Ничего не изменилось.
код (на паскале) кстати не очень, у меня бы ревизию не прошел
аргументируйте
там все пришито намертво к конкретному экрану, полно вот такого:
SetRect(fatBits.bounds,80+208-26,120+120-15,80+208+26,120+120+15);
или такого:
IF borderFlag THEN CASE lineSize OF
1: v := lineTop + 15;
2: v := lineTop + 26;
4: v := lineTop + 38;
8: v := lineTop + 52;
END;
плюс я не терплю goto
еще есть:
lineLeft = 15; { line attributes rectangle }
lineRight = 68;
…
lineMid = 40; { (lineLeft + lineRight) DIV 2 }
правда это скорее компилятор не умеет
стиль конечно чувствуется и код читать легко, но смесь чисел и констант в коде все портит.
SetRect(fatBits.bounds,80+208-26,120+120-15,80+208+26,120+120+15);
или такого:
IF borderFlag THEN CASE lineSize OF
1: v := lineTop + 15;
2: v := lineTop + 26;
4: v := lineTop + 38;
8: v := lineTop + 52;
END;
плюс я не терплю goto
еще есть:
lineLeft = 15; { line attributes rectangle }
lineRight = 68;
…
lineMid = 40; { (lineLeft + lineRight) DIV 2 }
правда это скорее компилятор не умеет
стиль конечно чувствуется и код читать легко, но смесь чисел и констант в коде все портит.
У меня ноут — 700 MHz, 256 MB. 2007 — KDE просто летал в Gentoo. 2010 — думал посмотреть Ubuntu и офигел от тормозов даже в GNOME!
Вот он, настоящий Программер.
А сейчас поделки С#-ков на заказ могут кушать по 4 гига RES. И фраза «а вы ничего не говорили про требования к потреблению ресурсов» — нормальное явление…
А сейчас поделки С#-ков на заказ могут кушать по 4 гига RES. И фраза «а вы ничего не говорили про требования к потреблению ресурсов» — нормальное явление…
ИМХО сроки разработки сейчас «немного» другие. и «вот он — настоящий программер» вам скажут скорее, если софт вы сдадите точно в срок или быстрее оного.
А сейчас поделки С#-ковТрололо
1) Сравните сложность программ тогда и сейчас
2) А причем тут собственно говоря конкретный язык?
3) Оптимизация снижает читабельность кода и увеличивает сроки и стоимость
4) Ну а если правда не написали требования, откуда людям было знать?
Я не поощряю утечки памяти или калькуляторы на 4Гб, но в корпоративных системах если небыло оговорено какие ресурсы может потреблять программа — почему нет?
Может для начала вы сравните системные характеристики машин тогда и сейчас? ;) И заодно инструментарий разработчика тех времен, чтоб вам перестало казаться что тогда было легче это написать
Я ни разу не говорил что тогда было легче писать, просто сложность систем сейчас выше, а раз выше сложность — требуется больше ресурсов.
А по поводу характеристик что не так? Сейчас они выше и естественно программы потребляют больше ресурсов, вроде логично.
А по поводу характеристик что не так? Сейчас они выше и естественно программы потребляют больше ресурсов, вроде логично.
Ой, вот не надо про сложность систем, ладно? Сейчас на паре гигагерц умудряется тормозить то, что влёт выполняло те же задачи на нескольких мегагерцах.
Вот это — тупиковый путь.
Как бывший асм программист, я часто вообще не понимаю что там в программах может тормозить, в программах, которые ничего высокоинтеллектуального не делают.
Вот это — тупиковый путь.
Как бывший асм программист, я часто вообще не понимаю что там в программах может тормозить, в программах, которые ничего высокоинтеллектуального не делают.
Понимаете, ограниченность ресурсов — вынуждает писать совершенный код. И наоборот: наличие 4 гб под процесс — расслабляет. И постоянно можно наблюдать картину, когда программист не заботится об оптимизации. В самом деле, а зачем? Ведь железо дает простор под любую глупую архитектуру и все равно это будет работать! Я согласен, что скорость и экономия ресурсов не основной показатель для определенных задач. Однако, когда железо требует от вас каждый день решать задачи типа «как разместить 10 мб в 64 кб памяти» — это требует от вас идеального кода.
Мне приходилось заниматься с начинающими программистами. И я не мог им объяснить в чем смысл типизации данных: они предпочитают использовать длинное целое даже там, где хватило бы и байта под переменную. Почему? Да потому что даже на миллионе объектов, всего лишь потеря нескольких мегабайт, стоит ли заморачиваться? В какой-то ситуации может и не стоит, но сама тенденция «я имею практически неограниченные ресурсы ОЗУ» — приводит к тормознутым монстрам, которые можно было бы писать эффективнее.
Мне приходилось заниматься с начинающими программистами. И я не мог им объяснить в чем смысл типизации данных: они предпочитают использовать длинное целое даже там, где хватило бы и байта под переменную. Почему? Да потому что даже на миллионе объектов, всего лишь потеря нескольких мегабайт, стоит ли заморачиваться? В какой-то ситуации может и не стоит, но сама тенденция «я имею практически неограниченные ресурсы ОЗУ» — приводит к тормознутым монстрам, которые можно было бы писать эффективнее.
ограниченность ресурсов — вынуждает писать совершенный код.Я с этим в корне не согласен. Оптимизация только колечит код, иногда она вынужденная, но она даёт один плюс — производительность и кучу проблем: стоимость, сроки, поддержка, баги.
По поводу второго абзаца: а вот я видел системы где было захардкодено по байту и из за этого во первых небыло профита (привет, выравнивание) во вторых — в один прекрасный момент этого байта не хватило, а из за кривой работы с указателями код практически невозможно было переписать.
Конечно понятно что можно было сделать аккуратнее и тогда достаточно было бы просто поменять тип в одном месте, но не напасёшься же на все оптимизации такого.
Поэтому я считаю что такую оптимизацию не надо делать. Или пример у Вас крайне неудачный с этими байтами…
К слову, уж ОЗУ — достаточно дешевый ресурс, сейчас порядка 30-40$ за гигабайт (или около 100$ за пак из 2*2Гб).
Это достаточно небольшая стоимость по сравнению с софтом, который может тормозить из за нехватки ОЗУ.
Это достаточно небольшая стоимость по сравнению с софтом, который может тормозить из за нехватки ОЗУ.
Я с этим в корне не согласен. Оптимизация только колечит код
В смысле калечит? Ну это смотря что вы называете оптимизацией. Я говорю об оптимизация кода. То есть когда куча кода еле ворочается, а одна строчка — решает теже задачи и быстрее в два раза. Конечно, ты бывает редко. Но обратное, когда вместо изящного кода клепается «индуский» — таких примеров много. И неограниченность в ресурсах, одна из причин порождения очередного индуса.
Да, я заметил ошибку, думал проще её проигнорировать.
По сути: я писал алгоритм рассчета освещения, изначальная реализация с классами и по всем правилам легко модифицировалась, практически не нуждалась в отладке и отлично работала, за исключением скорости… Чтобы добиться максимальной скорости — пришлось переписать это чуть ли не в один метод на C, который было невозможно отлаживать и модифицировать, зато я смог запустить рендер на ноутбуке и он выполнялся за допустимое время.
Мораль:
1) Если бы я начал писать сразу оптимизированный код и потом его отлаживать — ушло бы в разы больше времени, поэтому понятная версия кода всё же нужна и изначально нужно писать именно её.
2) Узкие места оказались не совсем в тех местах, где их можно было ожидать, написав сначала код по всем правилам и профилируя его я избежал оптимизации того, что не нужно оптимизировать.
3) Если бы мне нужно было модифицировать код — я бы взял версию с классами и модифицировал её, т.к. это в разы быстрее.
Это было к тому, что оптимизация не порождает «идеальный код».
P.S.
По сути: я писал алгоритм рассчета освещения, изначальная реализация с классами и по всем правилам легко модифицировалась, практически не нуждалась в отладке и отлично работала, за исключением скорости… Чтобы добиться максимальной скорости — пришлось переписать это чуть ли не в один метод на C, который было невозможно отлаживать и модифицировать, зато я смог запустить рендер на ноутбуке и он выполнялся за допустимое время.
Мораль:
1) Если бы я начал писать сразу оптимизированный код и потом его отлаживать — ушло бы в разы больше времени, поэтому понятная версия кода всё же нужна и изначально нужно писать именно её.
2) Узкие места оказались не совсем в тех местах, где их можно было ожидать, написав сначала код по всем правилам и профилируя его я избежал оптимизации того, что не нужно оптимизировать.
3) Если бы мне нужно было модифицировать код — я бы взял версию с классами и модифицировал её, т.к. это в разы быстрее.
Это было к тому, что оптимизация не порождает «идеальный код».
P.S.
Конечно, ты бывает редко.
Конечно, ты бывает редко
Имелось ввиду конечно «так бывает редко».
Спор зашел куда-то не туда. Я говорил о том, что фактически так устроен прогресс: он несколько обедняет специалиста. И возможно это хорошо. Как скажем, раньше, до появления фотографии — художник был нужен всем. Потом, в какой-то нише его заменили фотографы, которым для запечатления картины — не тебовалось ни таланта, ни обучения. И поэтому, говорить будто фотограф круче художника, потому что должен рубить в такой куче познаний фотографического искусства — это, как минимум, не для большинства случаев.
Имелось ввиду конечно «так бывает редко».Имелось ввиду что опечатки не заслуживают того, чтобы о них дополнительно писать в каментах.
Прогресс не обедняет специалиста, просто позволяет абстрагироваться от более низкоуровневых задач с определёнными допущениями (на производительность в данном случае).
Изначально речь шла о том, что ограниченность ресурсов создаёт «совершенный код», я же говорю что этот код только быстрый, но в совершенстве он наоборот — теряет.
Безусловно, где-то нужен быстрый код и везде нужно соблюдать какой-то баланс. Но не считаю что нужно везде оптимизировать, я лучше буду видеть в софте больше фич и куплю доп. планку памяти.
В конце концов, железо меняется просто с огромной скоростью, ещё 10 лет назад мы не могли и мечтать о 8и ядерных Xeon'ах, в то время как некоторый код живёт в том или ином виде уже десятилетия, и ещё столько же будет жить.
Прогресс не обедняет специалиста, просто позволяет абстрагироваться от более низкоуровневых задач с определёнными допущениями
Тем не менее, посмотрите например на искусство. Давным давно не стало Бахов и Моцартов, зато полно всяких Тимати. То же самое и в изобразительном искусстве, и в программировании тоже. Не в том смысле что великих не осталось, а в том, что плохих очень много. Я конечно же приветствую прогресс и согласен с неизбежностью таких проявлений, но это не значит что нельзя оценить былые достижения или считать их хуже нынешних. И предлагаю на этом закончить. Спор в цели не входил
Почему-то я первые пол часа не мог видеть этот комментарий в топике, хотя на почту уведомление пришло.
Не спорю что тогдашние достижения тоже были достижениями, но ведь были другие условия игры.
А плохих много из за низкого порога вхождения, это неизбежно. Повышать порог вхождения — это зачастую искуственно усложнять (хотя не всегда), да и не нужно это никому.
С другой стороны низкий порог вхождения позволяет появиться большему количеству «мастеров» (и в тысячи раз большему количеству быдлокодеров) тут вопрос в том, что лучше: 10 программистов и среди них 1 мастер или 1000 программистов из которых 10 мастеров и 950 быдлокодеров (условно).
Не спорю что тогдашние достижения тоже были достижениями, но ведь были другие условия игры.
А плохих много из за низкого порога вхождения, это неизбежно. Повышать порог вхождения — это зачастую искуственно усложнять (хотя не всегда), да и не нужно это никому.
С другой стороны низкий порог вхождения позволяет появиться большему количеству «мастеров» (и в тысячи раз большему количеству быдлокодеров) тут вопрос в том, что лучше: 10 программистов и среди них 1 мастер или 1000 программистов из которых 10 мастеров и 950 быдлокодеров (условно).
> 1)
Сравните в чём писали тогда и в чём пишут сейчас.
> 2)
Потому что именно mono почему то течет в неумелых руках. Просто привёл пример.
> 3)
Угу, окей. Давайте вообще ничего не оптимизировать в коробочных программах. Пусть фотошопу надо будет 32 гига памяти для старта (она же дешевая), а винда сама для себе будет резервировать 5 виртуальных ядер процессора core i7.
Я не говорю, что нужно ужимать до килобайтов, но хоть какие то разумные рамки соблюдать нужно.
> 4)
Опять же — вопрос разумности. Оптимизировать потребление памяти можно, это не так уж сложно в простых приложениях. И даже PyGTK на самом деле не грешит утечками на уровне тулкита, просто кому то в лом писать на Python'e. Народ пишет на Сях с синтаксисом питона. Отсюда и утечки памяти.
Приведу простой пример из жизни. Меня пару лет назад пригласили аутсорсить небольшую контору. За копейки, 1 раз в месяц ходить. Всё клёво. Придя туда впервые я задал вопрос — нафига такое мощное железо? Оно круто, конечно же, но одной из задач мне поставили оптимизировать энергопотребление (подмосковье, свет стабильно вырубается 2-3 раза в сутки на 10-30 минут, надо жить на бесперебойниках). Денег на это выделили минимально, потому что «и так на программистов потратились». В закоулках я нашёл странный стоечный сервер с 2xXeon и 16 GB RAM.
А знаете для чего он использовался? Для того, что бы на нём крутилась программка, в которой вёлся учет «рабочих» (там их очень много, ибо стройка). Запускалось 2-3 копии программы, по ssh -x, 3 копии кушали 12 GB памяти.
Решено было переписать программу в бонус работодателю (платили прилично, работы по факту мало.).
Не зная абсолютно никаких ЯП я банально написал ч/б интерфейс на PHP (его до сих пор не знаю) с базой на мускуле. 4 таблицы, 20-30 кнопочек, 6 форм. Всё. Вся программа. База, правда, действительно огромная, но Sphinx спасает их до сих пор (база на SSD, сама система стоит на флешке USBшной).
Стоечный сервер — на продажу, все локальное железо — заменяется на нетбуки с подключенным монитором, «сервер» заменяется на крутой нетбук (атом, 1 GB RAM) с крутой батареей… В общем железо, купленное за ~300к (5 компов+сервер) было заменено железом на ~90к. Автономность «офиса» увеличилась с 10 минут до 5 часов («сервер» же вообще сутки мог работать от предназначенных ему ИБП и родной батареи).
Ну и да — так называемым «программерам» на написание этой утилиты + конвертацию БД из Access дали полгода.
Про корпоративные… Там рулит SAP. Он действительно рулит. Он рулит даже в корпорациях уровня Mercedes. И у них нет кластеров, обслуживающих серверную часть SAP. Да, серверы мощные. Но их мало.
Если сравнивать с нашими поделиями, вроде 1с — конечно, можно жить отговорками «программа сложная, оптимизировать сложно».
Сравните в чём писали тогда и в чём пишут сейчас.
> 2)
Потому что именно mono почему то течет в неумелых руках. Просто привёл пример.
> 3)
Угу, окей. Давайте вообще ничего не оптимизировать в коробочных программах. Пусть фотошопу надо будет 32 гига памяти для старта (она же дешевая), а винда сама для себе будет резервировать 5 виртуальных ядер процессора core i7.
Я не говорю, что нужно ужимать до килобайтов, но хоть какие то разумные рамки соблюдать нужно.
> 4)
Опять же — вопрос разумности. Оптимизировать потребление памяти можно, это не так уж сложно в простых приложениях. И даже PyGTK на самом деле не грешит утечками на уровне тулкита, просто кому то в лом писать на Python'e. Народ пишет на Сях с синтаксисом питона. Отсюда и утечки памяти.
Приведу простой пример из жизни. Меня пару лет назад пригласили аутсорсить небольшую контору. За копейки, 1 раз в месяц ходить. Всё клёво. Придя туда впервые я задал вопрос — нафига такое мощное железо? Оно круто, конечно же, но одной из задач мне поставили оптимизировать энергопотребление (подмосковье, свет стабильно вырубается 2-3 раза в сутки на 10-30 минут, надо жить на бесперебойниках). Денег на это выделили минимально, потому что «и так на программистов потратились». В закоулках я нашёл странный стоечный сервер с 2xXeon и 16 GB RAM.
А знаете для чего он использовался? Для того, что бы на нём крутилась программка, в которой вёлся учет «рабочих» (там их очень много, ибо стройка). Запускалось 2-3 копии программы, по ssh -x, 3 копии кушали 12 GB памяти.
Решено было переписать программу в бонус работодателю (платили прилично, работы по факту мало.).
Не зная абсолютно никаких ЯП я банально написал ч/б интерфейс на PHP (его до сих пор не знаю) с базой на мускуле. 4 таблицы, 20-30 кнопочек, 6 форм. Всё. Вся программа. База, правда, действительно огромная, но Sphinx спасает их до сих пор (база на SSD, сама система стоит на флешке USBшной).
Стоечный сервер — на продажу, все локальное железо — заменяется на нетбуки с подключенным монитором, «сервер» заменяется на крутой нетбук (атом, 1 GB RAM) с крутой батареей… В общем железо, купленное за ~300к (5 компов+сервер) было заменено железом на ~90к. Автономность «офиса» увеличилась с 10 минут до 5 часов («сервер» же вообще сутки мог работать от предназначенных ему ИБП и родной батареи).
Ну и да — так называемым «программерам» на написание этой утилиты + конвертацию БД из Access дали полгода.
Про корпоративные… Там рулит SAP. Он действительно рулит. Он рулит даже в корпорациях уровня Mercedes. И у них нет кластеров, обслуживающих серверную часть SAP. Да, серверы мощные. Но их мало.
Если сравнивать с нашими поделиями, вроде 1с — конечно, можно жить отговорками «программа сложная, оптимизировать сложно».
Если течет память в языках с gc — то тут уж программисты виноваты, в языках без gc их программы бы вообще не работали дольше 5 минут, поэтому упоминать конкретные языки некорректно.
По поводу винды и фотошопа — я же написал про корпоративные системы, поясню разницу:
Стоимость железа на котором крутится фотошоп — огромна, это куча юзеров и компаний, и они просто откажутся от продукта если он будет есть 12Гб памяти, тоже самое с остальным подобным софтом.
В корпоративных приложениях на заказ зачастую стоимость разработки минимум измеряется десятками тысяч долларов, при этом каждый день просрочки внедрения системы компания теряет деньги из за отсутствия автоматизации. В этом случае железо В РАЗЫ дешевле чем разработка софта (а ведь его ещё надо поддерживать, если там жесткая оптимизация то и на поддержке разориться можно).
Тут главное отличать «о, можно писать говнокод, ребята купят к нашей софтине суперкомпьютер» и «нет смысла оптимизировать, т.к. это в перспективе окажется менее рациональным в финансовом плане, лучше сейчас купить более мощное железо».
По поводу винды и фотошопа — я же написал про корпоративные системы, поясню разницу:
Стоимость железа на котором крутится фотошоп — огромна, это куча юзеров и компаний, и они просто откажутся от продукта если он будет есть 12Гб памяти, тоже самое с остальным подобным софтом.
В корпоративных приложениях на заказ зачастую стоимость разработки минимум измеряется десятками тысяч долларов, при этом каждый день просрочки внедрения системы компания теряет деньги из за отсутствия автоматизации. В этом случае железо В РАЗЫ дешевле чем разработка софта (а ведь его ещё надо поддерживать, если там жесткая оптимизация то и на поддержке разориться можно).
Тут главное отличать «о, можно писать говнокод, ребята купят к нашей софтине суперкомпьютер» и «нет смысла оптимизировать, т.к. это в перспективе окажется менее рациональным в финансовом плане, лучше сейчас купить более мощное железо».
> По поводу винды и фотошопа — я же написал про корпоративные системы, поясню разницу:
ну да, не совсем удачный пример.
> В корпоративных приложениях на заказ зачастую стоимость
Всё же основная масса проблем с производительность не у приложений за даже тысячи долларов, а именно у небольших приложений, которым грех кушать более 256мб на запущенную копию.
Если ПО заказывают за десятки тысяч долларов — все участники процесса просто обязаны понимать, что такое ПО будет активно работать с огромным количеством данных. И там уже проблема даже не в оптимизации, а в том, что данных действительно много. И быдлокод с утечками памяти там встречается крайне редко.
> В этом случае железо В РАЗЫ дешевле
Я встречал ещё одну забавную проблему. Благо, решать её не мне надо было. Большая компания, ПО за кучу денег. Подумали так же — железо дешевле. Купили сервер. Компания разрослась. Купили сервер мощнее. Компания разрослась. В конечном счете — ни один из серверов, который можно купить в России не мог выдержать нагрузку, генерируемую серверной частью программы в одиночку. Пошли к другим аутсорсерам, те переписали заново ПО с возможностью работы на нескольких серверах. Опять же — Mysql+sphinx+репликация+обертка на сях, если мне память не изменяет. Ну и конечные клиенты на си и gtk. И ничего… работает на 2х серверах, нагрузка на них — около 30%…
Так что тут тоже нужно думать…
Ну и всё же я ничего не говорил о жесткой оптимизации. Да, ужимать сложную программу в 128 мб памяти действительно нет смысла, но я видел немало «калькуляторов на 4 GB RES» в своей жизни… честно. И отголоски этих калькуляторов встречаются на десктопном ПО. Я уже устал объяснять всем, что PyGTK не течет — руки кривые у разработчиков. Тулкит простой, вот его новички и пользуют.
ну да, не совсем удачный пример.
> В корпоративных приложениях на заказ зачастую стоимость
Всё же основная масса проблем с производительность не у приложений за даже тысячи долларов, а именно у небольших приложений, которым грех кушать более 256мб на запущенную копию.
Если ПО заказывают за десятки тысяч долларов — все участники процесса просто обязаны понимать, что такое ПО будет активно работать с огромным количеством данных. И там уже проблема даже не в оптимизации, а в том, что данных действительно много. И быдлокод с утечками памяти там встречается крайне редко.
> В этом случае железо В РАЗЫ дешевле
Я встречал ещё одну забавную проблему. Благо, решать её не мне надо было. Большая компания, ПО за кучу денег. Подумали так же — железо дешевле. Купили сервер. Компания разрослась. Купили сервер мощнее. Компания разрослась. В конечном счете — ни один из серверов, который можно купить в России не мог выдержать нагрузку, генерируемую серверной частью программы в одиночку. Пошли к другим аутсорсерам, те переписали заново ПО с возможностью работы на нескольких серверах. Опять же — Mysql+sphinx+репликация+обертка на сях, если мне память не изменяет. Ну и конечные клиенты на си и gtk. И ничего… работает на 2х серверах, нагрузка на них — около 30%…
Так что тут тоже нужно думать…
Ну и всё же я ничего не говорил о жесткой оптимизации. Да, ужимать сложную программу в 128 мб памяти действительно нет смысла, но я видел немало «калькуляторов на 4 GB RES» в своей жизни… честно. И отголоски этих калькуляторов встречаются на десктопном ПО. Я уже устал объяснять всем, что PyGTK не течет — руки кривые у разработчиков. Тулкит простой, вот его новички и пользуют.
Из этой серии, мне очень нравится пример из первой главы «Жемчужин программирования»: про так как был оптимизирован массив телефонных номеров на бинарный
Когда-нибудь они могут пригодиться для обеспечения обратной совместимости.Или например в образовательных целях.
Мне было бы интересно учить программирование на примере кодов StarCraft или косынки например.
/me люто хочет исходники старых игр
НЛО прилетело и опубликовало эту надпись здесь
Джобс на этой фотке тааааааааакой шалун xD
НЛО прилетело и опубликовало эту надпись здесь
Слово «обязать» — плохой предпосыл…
НЛО прилетело и опубликовало эту надпись здесь
А у Стива глаза хитрющие. По-любому, уже придумал айфон.
Ну каждый программер писал свой графический редактор, это примерно как калькулятор. Я правда делал векторный под DOS, и уложился в основном модуле в 1298 строк. Посмотрел исходники — нифига не понял, очень много каких-то констант, да и странный паскаль какой-то, непривычный
Интереснее увидеть скрин (хотя бы) с окном «About», но а в идеале — исходники.
Исходники rghost.ru/2206534, Но это 99 год, только начинал программировать, поэтому код страшен конечно.
Вы покажите для начала свое творение, прежде чем намекать на то что паскаль отстой ;) Не в языке дело, это любой взрослый кодер понимает
Что вы, я ни разу не говорю что паскаль отстой, сам на нем и программирую до сих пор. Все зависит от умения, тоесть и на си можно нагородить такой говнокод что за день не разберешь, ровно как и на паскале. Все от рук зависит, например когда я писал первый графический движок было 10% паскаля а остальное ассемблерная вставка. Потом правда вообще под ассемблер переписал все. Главное чтобы нравился инструмент, я это хотел сказать.
А какая шикарная штука была Art Studio для ZX Spectrum
Сейчас оптимизация очень актуальна для Actionscript программистов. Для того чтобы сделать нечто визуально хорошее и ресурсоёмкое (а ля 3d), но не заставляющее кричать — флэш говно — приходиться потрудиться. Хотя 99% флэшеров на это забивают и пользователь всё равно кричит — флэш говно!
Лично постоянно вылавливаю фэпээсы на уменьшении количества граней, отсечения невидимых (неиспользуемых) элементов, проверки на isInvalidated, кэширование всего и вся итд итп. Результаты отличаются от решения «в лоб» в разы.
Кроме того постоянно оптимизируется протокол общения с сервером. Даже серверники (с/с++) удивлялись когда я им предлагал оптимизированные алгоритмы расчёта путей, и свои варианты бинарных протоколов — для них это не представлялось сильной экономией, тоже уже отвыкли экономить, оказалось существенно помогает.
А ещё есть оптимизация размеров ресурсов, хотя на это я уже тоже начинаю потихоньку забивать)))
Лично постоянно вылавливаю фэпээсы на уменьшении количества граней, отсечения невидимых (неиспользуемых) элементов, проверки на isInvalidated, кэширование всего и вся итд итп. Результаты отличаются от решения «в лоб» в разы.
Кроме того постоянно оптимизируется протокол общения с сервером. Даже серверники (с/с++) удивлялись когда я им предлагал оптимизированные алгоритмы расчёта путей, и свои варианты бинарных протоколов — для них это не представлялось сильной экономией, тоже уже отвыкли экономить, оказалось существенно помогает.
А ещё есть оптимизация размеров ресурсов, хотя на это я уже тоже начинаю потихоньку забивать)))
Меня радует Аткинсон на этой фотографии. Вот он, человек, по-настоящему любящий то, чем он занимается.
АААА, QuickDraw — «образец великолепного дизайна программной части». Мы рыдаем всей командой. Нет, ну на то время, может быть, но сейчас, в 2010 году, я не могу равнодушно читать код на QuickDraw.
А вообще полезность сомнительная, не представляю себе кто будет копаться в ассемблере для 68к, даже для обеспечения обратной совместимости.
А вообще полезность сомнительная, не представляю себе кто будет копаться в ассемблере для 68к, даже для обеспечения обратной совместимости.
Я в школе такой на бейсике для БК-0010-01 писал (16кб озу, 3 мгц проц). Правда пришлось мышку самому делать: agafonov.pp.ru/blog/2009/04/16/машина-времени/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Исходники MacPaint и QuickDraw отправлены в музей