Слишком жирная гифка, а конвертер не поддерживает пропуск кадров.
Нашел другой кусок на 360 кадров, удалось сжать в 10 раз при сравнимом качестве и 10fps. И это на реале в программе более чем 10-летней давности:) Так что это прекрасно, что технологии не стоят на месте.
В профдеформации ничего особого нет — она у многих есть, независимо от профессии. Напрягает другое — пользы от неё больше, чем вреда. Что какбэ намекаэ об ебанутости окружающей действительности.
Здесь же эта деформация к месту, ибо совпадает с предметом разговора.
NIH синдром я уже почти пережил, но код и архитектура должны решать возложенные на них задачи. Не справляются — переделать, возможно обкладывая хуями код и его авторов, внятно не умеющих объяснить причины того или иного решения.
А ты являешься программистом, когда твой код работает под эмулятором? А когда в виртуальной машине?
Пока ты будешь супероптимально писать код под частоту ядра, это уже нахрен никому не нужно будет.
Программист в первую очередь должен решить задачу максимально эффективным способом. В критерий эффективности в том числе входит и затраченное время, причем с очень большим весом.
А оптимальность асма напрямую связана с уровнем КОДЕРА :) просто когда пишешь для мелкой системы — ты сжат её рамками, и это постоянно чувствуешь. История одного байта, думаю ты читал.
Читал, конечно. А еще не раз сталкивался с тем, что тысячи человекочасов квалифицированных программистов убиваются на последствиях экономии копеек на железе.
А еще ты не учитываешь, что мелкая система не сколько сжимает ТВОИ рамки, сколько сжимает рамки того что тебе НАДО знать. Отсюда и иллюзия прежней власти над системой после смены оной на более сложную.
А когда пишешь на ЯВУ, контроль использования ресурсов имеет далеко не такое решающее значение, важнее — скорость разработки, ну и, возможно, постоянная поддержка.
Да! Поддержка! На нее обычно кладут такой длинный и толстый, что аж страшно становится.
охренеть вопрос. СОВРЕМЕННЫЙ. я брюзга?
Тебе кто-то мешает поставить старый софт с гораздо меньшими аппетитами?
Но нет, мы хотим получать новый софт, максимально функциональный, как можно быстрее, и чтоб баги правились моментально. Но платить за это (требованиями к железу)- пф-ф-ф-ф, вы о чем?!
Я не говорю, что на контроль за расходом ресурсов надо забить. Совсем нет. Но это как рынок — каждая вещь стоит столько, за сколько ее готовы купить. Наглые требования и фуфловая функциональность при наличии альтернатив — в топку. Очень наглые требования, но альтернативы не подходят или еще наглее- придется раскошелиться.
Высокопарно? А противопоставление «кодера» и «программиста» с сознательным принижением последнего — это как?
Максимальное использование ресурсов? Вылизанная числодробилка на ассемблере под одноядерный x86 против многопоточного варианта под x86_64 — кто оптимальнее?
В таком случае, ассемблера под ARM или x86 тоже нет, только машинный код. Но ты его (ассемблер) почему-то используешь, причем с макросами, повышающими сопровождаемость кода, иногда в ущерб размеру памяти или скорости работы. Я вижу тут банальное лукавство и самообман.
Код на асме, к сожалению, далеко не всегда оптимален. Хотя бы по причине человеческого фактора — слишком много деталей чтобы они уместились в голове у программиста. А в «голове» у компилятора- запросто. Не говоря уже о том, что ассемблерный код моментально протухает сразу после написания, теряя возможность работать на другой платформе. А мог бы совершенно бесплатно получить ускорение за счет более новых технологий.
В данный момент — да. Программирование в основном на С++ по работе и C++/Java для души (объем использования остальных языков незначителен на фоне этих двух).
На заре рабочей карьеры занимался программированием железа. Бесценный опыт в плане понимания, что ассемблеру не место в промышленной разработке, только в специализированных библиотеках/SDK и в минимально возможных дозах. Похожий опыт был пару лет назад, когда пришлось писать драйвер для гипервизора.
Боже упаси от такого. Предлагаешь мне со своим софтом ещё и компилятор прилагать? Нее сишарпы не для меня, только если по работе потребуют.
Почему же. Код виртуальной машины преобразуется в нативный. После этого распространяется обычный бинарник, который уже не будет компилироваться у клиента.
И универсальный язык программирования выдавал мне в окошке аккуратную надпись «CRC memrory region error, correct?». Эврика!!! Отвечаешь ДА, и новые данные, которые я подставил автоматически вписывались под ксор!
OMG Ты действительно не чуешь разницу между языком программирования, средой выполнения и конкретной программой, написанной на этом самом языке?
Поэтому, да, я не хочу писать свой код, под вот такие вот виртуальные машины. Я уж лучше по старинке, на асме, под эмулятором Z80 быстрее будет исполняться, чем на таком вот «нативном» языке.
Настало время для объяснения факту
Увы, он работает только под 32-бита, у этого есть ряд причин, но почему это так, — не сейчас.
Нашел другой кусок на 360 кадров, удалось сжать в 10 раз при сравнимом качестве и 10fps. И это на реале в программе более чем 10-летней давности:) Так что это прекрасно, что технологии не стоят на месте.
Здесь же эта деформация к месту, ибо совпадает с предметом разговора.
NIH синдром я уже почти пережил, но код и архитектура должны решать возложенные на них задачи. Не справляются — переделать, возможно обкладывая хуями код и его авторов, внятно не умеющих объяснить причины того или иного решения.
Достаточно, чтобы можно было себе позволить выбирать между интересной и очень высокооплачиваемой работой в пользу первой.
И кто из нас после этого программист, а кто ремесленник?
Пока ты будешь супероптимально писать код под частоту ядра, это уже нахрен никому не нужно будет.
Программист в первую очередь должен решить задачу максимально эффективным способом. В критерий эффективности в том числе входит и затраченное время, причем с очень большим весом.
А еще ты не учитываешь, что мелкая система не сколько сжимает ТВОИ рамки, сколько сжимает рамки того что тебе НАДО знать. Отсюда и иллюзия прежней власти над системой после смены оной на более сложную.
Да! Поддержка! На нее обычно кладут такой длинный и толстый, что аж страшно становится.
Тебе кто-то мешает поставить старый софт с гораздо меньшими аппетитами?
Но нет, мы хотим получать новый софт, максимально функциональный, как можно быстрее, и чтоб баги правились моментально. Но платить за это (требованиями к железу)- пф-ф-ф-ф, вы о чем?!
Я не говорю, что на контроль за расходом ресурсов надо забить. Совсем нет. Но это как рынок — каждая вещь стоит столько, за сколько ее готовы купить. Наглые требования и фуфловая функциональность при наличии альтернатив — в топку. Очень наглые требования, но альтернативы не подходят или еще наглее- придется раскошелиться.
Максимальное использование ресурсов? Вылизанная числодробилка на ассемблере под одноядерный x86 против многопоточного варианта под x86_64 — кто оптимальнее?
В таком случае, ассемблера под ARM или x86 тоже нет, только машинный код. Но ты его (ассемблер) почему-то используешь, причем с макросами, повышающими сопровождаемость кода, иногда в ущерб размеру памяти или скорости работы. Я вижу тут банальное лукавство и самообман.
Код на асме, к сожалению, далеко не всегда оптимален. Хотя бы по причине человеческого фактора — слишком много деталей чтобы они уместились в голове у программиста. А в «голове» у компилятора- запросто. Не говоря уже о том, что ассемблерный код моментально протухает сразу после написания, теряя возможность работать на другой платформе. А мог бы совершенно бесплатно получить ускорение за счет более новых технологий.
На заре рабочей карьеры занимался программированием железа. Бесценный опыт в плане понимания, что ассемблеру не место в промышленной разработке, только в специализированных библиотеках/SDK и в минимально возможных дозах. Похожий опыт был пару лет назад, когда пришлось писать драйвер для гипервизора.
OMG Ты действительно не чуешь разницу между языком программирования, средой выполнения и конкретной программой, написанной на этом самом языке?
Настало время для объяснения факту
? :-D