как в анекдоте: 4 ядра и все тупят из-за кривого софта!
или в другом: каждый раз, когда ты пишешь int i вместо short i, сотни пользователей вынуждены докупать планку памяти
мощность вычислителя нивелируется кривизной рук и самих систем разработки
Когда программист не знает, что стоит сделать сдвиг целочисленного числа право на 2 бита, то оное уменьшится ровно в 4 раза, и подключает ВСЮ математическую библиотеку - это жесть!
когда Hello word занимает 12 МБ, когда преподаватель ВУЗа не знает ничего выше записей в своей же студенческой тетрадке с описание i51 40-летней давности, когда преподаватель "электроники" уровня Аспирант(!) не знает основ... то о чем можно говорить?
Когда программист не знает, что стоит сделать сдвиг целочисленного числа право на 2 бита, то оное уменьшится ровно в 4 раза, и подключает ВСЮ математическую библиотеку - это жесть!
Из книги "Совершенный код" следовало что все современные компиляторы подобные штуки сами правят. Код сейчас очень сильно вырос в размере и по сложности больее высокого уровня чем ебля со сдвигом вправо. Поэтому ГОРАЗДО важнее читабельность кода чем подобные заморочки. И сдивги куда то там это не читабельно.
Гораздо выгоднее, с точки щрения затрат денег на программистов, сначала написать рабочую программу с читабельным кодом, а потом оптимизировать все узкие места. Если на средних компах не лагает - и так сойдёт. И это НОРМАЛЬНО.
"Premature optimization is the root of all evil."© Кнут
Астральный код можно комментировать. Просто "следующие 5 строк производят сдвиг...". Читаемость кода, эта мантра совроменного копробизнеса, выкатывающего по три обновления в месяц уже подзадолбала. Время программистов нужно экономить отказом от постоянных правок и обновлений (в пекло аджайл) а не поощрением написания говнокода.
Не спорю, в серьезном энтерпрайзе это важно. Но постоянные обновления и аджайл достали уже, именно из-за них современный софт стал таким говном.
Когда программист не знает, что стоит сделать сдвиг целочисленного числа право на 2 бита, то оное уменьшится ровно в 4 раза, и подключает ВСЮ математическую библиотеку - это жесть!
ну это же подход ассемблера =) сейчас такая фигня это обычно экономия на спичках, потому что чтобы увидеть разницу в производительности этими операциями деления должен быть постоянно занят весь процессор. к тому же, в большинстве языков есть абсолютно стандартное "деление без остатка", не требующее подключения библиотек. а некоторые умеют инт так делить и обычным (/) делением.
Надо профайлером bottleneck'и искать, а не тупо оптимизировать все и вся, как говорил Кнут: "Premature optimization is the root of all evil in programming." Если нет проблемы или она решается апгрейдом железа то не стоит и заморачиваться, Железо нынче дешевое, а время программиста все так же дорогое. Современные компиляторы лучше оптимизируют, чем средний программист вручную.
С точки зрения производства и бизнеса да. Это рядового пользователя жаба душит топовую конфигурацию собрать, а для бизнеса не проблема выложить несколько миллионов для обновления парка техники. Главное убедить что новая заебатая софтина новее и заёбистей заебатей.
Это обсуждалось в подскасте радио т. Что есть 2 варианта решения проблеммы производительности. Нанимаем программера и он оптимизирует или тупо закидывает деньгами на железо. И подход с железом оказывается дешевле.
что-то в последнее время я видел мало оптимизированных игр. Обычно это делается ужатием текстурок и все. Да и геймдев это капля в мире разработки серверного ПО.
Оптимизация может идти многими путями, не на уровне переменных, но на уровне упрощения алгоритмов и более рационального вызова методов, кэширования каких-либо данных. Там где у косорукого инди возможно memory leak или тупо создаются объекты под данные которые уже болтаются в памяти, у хорошего разработчика как раз оптимизация.
Проблема в том что это как облегчать космический спутник удалением лишних или дублирующих узлов, оно конечно можно , но поиск и аккуратное удаление стоит огромного времени и денег.
но я не программист, а "электронщик"-разработчик, работаю с микроконтроллерами на самом нижнем уровне...
там сразу такие ляпы видны.
Так на микроконтроллере ты сразу ограничен в ресурсах, и не можешь использовать высокоуровневые языки.
Ловите попаданца!
P.S.: Уже давно можно. По крайней мере, на AVR и STM32 точно можно, с другими я покамест не работал. Си - достаточно высокоуровневый?
P.P.S.: Хотя да, ограничение памяти в 2 кб лично для меня вначале стало сурпрЫзом, потому что за годы на ПК как-то отвыкаешь экономить память НАСТОЛЬКО.
Если у тебя 2КБ то С становится низкоуровневым, библиотеки досвиданья, ассемблерные вставки - здравствуйте. Я сбёг от микроконтроллеров на С в счастливый мир Питона.
Одноглазого?))) извини, не мог не пошутить. Это ж пикабу…
В смысле становится низкоуровневым? Как это понимать?
Что имеется ввиду под библиотеками? Я не профессионал просто, так, балуюсь. Предварительно скомпилированный чужой код я не использую, не умею.
Просто инклуды с посторонними методами работают, сам код выглядит вполне обычно, то есть уровень абстракции довольно высок, просто для понимания – я пишу AlarmOn(); IgnitionStart(30); вместо PORTB |= 1<<PinID; (что в принципе тоже где-то в глубинах инклудов есть). Да и потом – на том же STM32 оперативки уже от 32 до дофига кб, и при желании там, наверное, можно впендюрить библиотеку.
Даже на 2кб-камне у меня получилось поднять т.н. систему событий, примерно как используется в платформе 1С8, когда нужно вызвать функцию с временной задержкой, возможно вызывать циклично, и при этом не блокировать работу камня, т.к. кроме отложеной функции на нём ещё управление другими системами. Получился эдакий динамический список заданий, который каждый проход основного цикла проверялся на наличие заданий, готовых к запуску. Единственное, чем пришлось пожертвовать из-за оперативки – это строковые человекопонятные названия заданий, но замена из на однобайтные константы с понятными именами сэкономила много места в памяти и много тактов процессора при сравнении.
Так что не знаю, мне казалось что запись вида PlanEvent(ACTION_ENGINE_START, 30000, RPM_STARTED, MAX_IGNITION_TIME, EVENT_NO_REPEAT); // пуск через 30 секунд
, подразумевающая неблокирующее планирование действий, это уже не низкий уровень. Сравнительно, конечно.
SUB ECX, Hehe
CMP ECX, EDX
JNE Kuku
JMP Pipi
Вот с этим, в смысле.
Подключая библиотеку ты добавляешь её код к программе (т.к. это динамическая библиотека всё немножко по другому, но кто знает тот поймёт) и инклюднув например библиотечку ввода-вывода и математики у тебя теряется куча памяти, поэтому либо вырываем функции из библиотек либо если совсем всё плохо пишем эти функции на ассемблере.
Низкий уровень ведь не подразумевает что ты что-то там не можешь, просто всё становится сложнее для написания.
Я с микроконтроллерами только год общался год назад, так что не могу сказать подробней.
Для меня С низкоуровневый потому что я могу обратится напрямую к любому участку памяти. Плюсы уже повыше будут.
А, кажется, начинаю потихоньку понимать. Ну да, так на МК делать, конечно же, не стоит. Хотя чисто теоретически, думаю, возможно. Кстати, болие-лимение дорогие МК (вроде старших линеек ARM Cortex) по идее должны сожрать те же библиотеки без проблем, т.к. на них код наверняка уже хранится не в собственной памяти, а где-то снаружи.
Для меня С низкоуровневый потому что...
По поводу этого я засомневался и погуглил, первый абзац Вики говорит всё-таки об абстракции смысла от машинного кода, что С в принципе и делает :)
https://ru.wikipedia.org/wiki/Высокоуровневый_язык_программи...
А как оно там на самом деле - конечно, фиг его знает. По идее, в грамотно организованных высокоуровневых языках тоже должен быть какой-то произвольный доступ к памяти, другое дело что там он наверное обычно и не нужен, (по крайней мере, лично мне трудно представить себе задачу, которая в контексте большого проекта с точки зрения удобства кодера не решалась бы лучше элегантными обёртками над прямой работой с памятью).
Я тоже работаю в VS 2017, например. А ещё в Sublime Text и VS Code иногда.
И я видел код индусов. Вот прям настоящих индусов из Индии. Это ужас.
Написать код, делающий примерно одно и то же в разных местах 5 разными, не совместимыми друг с другом способами? Да не вопрос! Сделать это одному индусу в одном коммите? Изи!
Тесты, которые проходят потому что ничего не тестируют? Других в том проекте не было.
Это нечто!
нет! они не тупые! им просто этого не рассказывали.
рассказываю одному, основы рассказываю...
А он каждые 20 минут выбегает покурить со словами "...мать! не может быть!"
Периоды в универе не всегда знают больше твоего.
На форумах и сообществах ЧСВ-шники пол часа объясняют какой ты мудак, а потом говорят что не собираются бесплатно учить джуна уму-разуму.
А потом ты приходишь на работу и на реальном примере узнаешь "ух ты, можно было не прописывать исключения, а вписать IS NOT NULL, ибо просто NOT NULL блокирует вывод"
Все это рассказывать о тысячи раз, но это по прежнему происходит.
Наверное, ничто, кроме практики и искреннего интереса, не может дать уверенных знаний в таких областях. Просто выучить не удастся, мозг будет сопротивляться, это я знаю по себе. Не любил химию, поэтому в школе ни хера не получалось с ней. Зато в универе прекрасно разбирался и с криптографией, и с ЯП. Потому что с 9 или 10 лет уже сам этим интересовался, и когда пришел в универ, знал уже все вплоть до 4-го или 5-го курса.
Наверное, ничто, кроме практики и искреннего интереса, не может дать уверенных знаний в таких областях.
в любых областях, потому что развитие рабочего процесса идёт чуть медленнее прогресса в своей сфере, а вот учебный процесс эволюционирует гораздо медленнее.
Он максимум может оптимизировать переменную у которой область видимости в пределах 1 функции. Остальные же переменные оптимизировать нельзя, т.к. данные могут прийти откуда угодно, а в случаие высокоуровневых языков то там вся библиотека (dll, или java package) может быть переиспользован в другом коде. В результате компилятор не может заменить тип, т.к. не известно где и как используется переменная.
Ну да:) Я как-то писал
Mega Man 1994:
2048K RAM, 64K VRAM
Castle In The Darkness 2015:
2097152K RAM, 1048576K VRAM
Но тут еще дело в скорости разработки:) Если Мегамэна толпа народа делала кучу времени, то CITH - яркий пример индюшатинки:) Да, куча различных фрэймворков и библиотек непомерно раздувает системные требования, но, с другой стороны облегчает (снижает порог вхождения) и ускоряет разработку:)
Ассемблер, около 670 байт :) в том МК было всего 1 КБ ПЗУ...
Дело в том, что каждый язык программирования создан решать определенные задачи. Так и с ассемблером. Вы же не будете брать микроскоп, чтобы забить гвоздь?
но тут речь не о конкретном продукте, а самой идеологии: зачем продумывать Хороший алгоритм, если железо "и так тянет!".
История из жизни, лет 17-20 назад было.
Приятель пишет бухгалтерский софт. Использует FoxPro (и старую версию Dbase IV). Программы летают!
Появляется Visual FoxPro: красивые окошечки, менюшечки! Это вам не DOS! А тут как раз контора заказывает софт для учета чего-то там. Он решает перейти на новое и красивое.
Делает. Приходит к заказчику, а у оного древние ПК стоят, уровня 486. Занавес! Да, его ПО работает, но скорость черепашья! Вздыхает, переписывает под DOS - всё летает.
Получается, что ради "чтобы красиво было" надо 4 ядра по 1ГГц?
Если Мегамэна толпа народа делала кучу времени
Первый мегамен делало 6 человек. По времени хз
Второй мегамен делала та же команда в течение 3-4месяцев, одновременно работая над другим проектом.
При этом они изобретали новые жанровые особенности, попутно впихивая свою игру под системные возможности NES
Я не просто так написал год:) Mega Man: The Wily Wars для Megadrive, японка была выпущена в октябре 1994, европейка в апреле 1995. На Genesis она не распространялась на носителях, только через Sega Channel с конца 1994 (вообще с конца - с 31 декабря). Это - ремейк трех первых игр серии Mega Man на Famicom/NES. Вот титры игры https://youtu.be/A9ZeKTcNyuY?t=135
Слухи о Мегамэне для Sega начали распространяться в начале 1994, значит разрабатывалась игра не меньше 9-10 месяцев, ну, 6 если утечка была на очень ранней стадии.
Помню, как удивлялся и негодовал, что программа-пустое окно на делфи весит 600 килобайт и демонстрировал такое же окно, написанное на ассемблере, весом в 1.5 кб.
А сейчас на асме так же быстро как на делфях накидай туда кучку контролов, повяжи между собой и базой.
Что, не получилось? "А ты как думал - 40 тонн" (с)
Не придумывайте, я прекрасно осознаю сложность ассемблера. Я 2.5 года на нем писал. В том числе (исключительно ради развлечения) и виндовые оконные приложения.
Я понимаю, почему он здесь не применим.
Хотя, ради справедливости, тупо накидать контролов и подключиться к БД - не слишком сложно. Когда занимался - что-то простое за день точно справился бы, а может - и меньше. Но делать это нужно только для обучения или развлечения. В продакшне - нет.
Я ведь только хочу натолкнуть вас на мысль у каждого инструмента свое применение. И передергивать факты для вау-эффекта не стоит.
АСМ хоть и легок, но писать на нем сложные вещи очень долго и соотвественно дорого. Делают это только если цель оправдывает.
Да, при простом приложении с пустым окном 600Кб это много, но в этих 600Кб скрыт потенциал который понадобится и раскроется когда задача будет соотвествующая.
Правда? А я и не знал. наверное, стоит прекратить клавиатурой землю копать, как вы думаете?
Мысль совершенно капитанская.
Кстати, это было году, если я не ошибаюсь, в 98-м, тогда у меня жесткий диск был на 1 гб. И тогда эти 600Кб казались совершенно не оправданными. Кстати, законченные приложения тоже были очень даже не маленькими.
Мало кто умеет видеть перспективу более чем на пару дней вперед.
А вот в Борланде (и Майкрософте кстати тоже) умели. Они еще тогда знали что размер приложения не особо важен, а в перпективе станет вообще не важным критерием выбора инструмента. А вот что действительно важно - это эффективность разработки которая экономит время - невосполнимый и дорогой ресурс.
Как видим они были правы.
Мало кто умеет видеть перспективу более, чем на пару дней вперед.
Но вы умеете видеть то, что умели видеть другие. Как живется с третьим глазом? Что сейчас я думаю о вас?
Делфи, кстати, не слишком эффективен. У меня регулярно было так, что дома работает, принес в универ - нет. Вылетел за пределы массива и похерил чужую память. Дома повезло, память была не нужная, в универе - нет.
Кроме этого, делфи прививал ужасный стиль программирования: программирование в button1.onClick().
А накидывание кнопок на форму не слишком сильно экономит время.
В общем, ушел он на свалку истории - туда ему и дорога. Для своего времени делфи был прорывом, но это время прошло.
Делфи "ушел на свалку истории" из-за проигрыша microsoft в конкурентной борьбе, а не из-за концепции. И никуда его время не ушло. C# сейчас очень даже развит, а принцип RAD в его основе как и у делфи. Разница только в финансовом потенциале microsoft.
Программирование button1.onClick() используется повсеместно студентами которые обчно не заморачиваются тонкостями архитектуры, а так как делфи из-за своей доступности и низкого порога вхождения полюбился студентам, то легенды об этом разошлись в широкие массы. Такой же код можно писать (студенты и дальше так пишут) и в C# и в Java и в любом другом RAD. Но это проблема не делфи как RAD инструмента и не object pascal, который лежит в его основе. Это проблема "радиуса кривизны" рук тех кто пишет. Любой инструмент можно использовать неверно, от этого сам инструмент не становится хуже.
Делфи - конкурент С#? Данунафиг. Они настолько разные, что... А что именно по-вашему между ними общего? Почему вы считаете их конкурентами? Только без пространных философских рассуждений, а конкретно, с примерами.
Данунафиг2. Про С# говорить не буду, а вот в Java, чтобы создать button1.onClick() надо так заморочиться, что никто так не делает.
Это именно косяк в архитектуре потому, что при двойном щелчке на buttin1 создается именно процедура, в которой можно писать (и пишут). А не "слоты\сокеты", эвент листенеры и прочее, что именно вызывает вашу функцию.
А нам в универе в 2013 году преподавали Office 2003, ибо преподу лень методичку менять было...
Современный код уже не должен быть столь оптимизирован, а большой объем вызван необходимостью поддержки различных платформ, других условий.
Но, если ты напишешь лишний if твой код не замедлится.
большой объем вызван необходимостью поддержки различных платформ
мне кажется это дешёвой отмазкой. Где можно такое встретить? ну к примеру чтобы и в винде работало, и в андроиде.
или что значит "поддержка различных платформ"?
любое приложение работает на уровне абстракций. То что вы описали это уровень драйверов и всяких фреймов. Это их проблемы поддерживать всё подряд и иметь описание всего на свете. Это проблемы уровня ядра, куда простого пользователя и его приложения не пускают. К примеру, вам нужно обратиться к мышке. Вы так и пишете в программе "опросить мышку" и вам абсолютно пофиг какая она, что может и через что подключена. За это отвечает какой-нибудь директ-х или что-то подобное. А если всё так, то почему с каждым годом простой "хело ворлд" раздувается и раздувается, и требует всё больше и больше ресурсов?
Смотри:
- Программист тогда: хороший математик -> знает основы математики и низкоуровневого программирования
- Программист сейчас: чтобы стать "быдло-кодером" надо выучить язык программирования; если учат в ВУЗе, математику да, ее дают, но низкоуровневое программирование мало кто знает.
Хороший программист сейчас знает математику не меньше, если не больше.
Хороший программист сейчас умеет проектировать приложения, которые ни в одном сне не снились ни одному программисту тогда.
Хороший программист читает объемы кода несуществующие тогда ежедневно.
Хороший программист сейчас пишет код понятный человеку.
Хороший программист сейчас следит за новыми технологиями, развитием инструментов, новыми веяниями в разработке и объем такой работы больше чем раньше.
Хороший программист сейчас должен правильно выбирать и применять инструменты, будь то фреймворк, хранилище, алгоритм и среда разработки.
Хороший программист сейчас все еще должен знать низкоуровневую часть, пусть и не так детально как раньше.
И так далее.
Остается лишь позавидовать "программисту тогда", которому достаточно было школьного курса математики + уметь мало-мало переводить системы счисления + выучить набор команд своего процессора и десяток-другой правил оптимизации под него. Тогда что бы стать хорошим программистом достаточно было иметь мат. склад ума и полгода времени на изучение мат-части.