Страшная правда
Бм ругался на картинку
Бм ругался на картинку
А чего тут спорить?
Это утверждение - ложь, а меч видать внучек дедушки Ляо молотком, напильником и соплевидным клеем сварганил из ржавой арматурины.
:)
Или он говорит то, что считает правдой его двуногий Придаток (он всё-таки Меч Правды, а не Меч Истины).
Что будет быстрее работать, O(n^2) на C или O(n) на JS?
С таким же успехом можно было бы спросить, например, "Кто быстрее преодолеет марафонскую дистанцию, профессиональный бегун ногами или новичок-бегун, но на мотоцикле?"
Да. Поэтому если тебе важна скорость - надо брать мотоцикл, а не задрачивать скорость бега. Именно это и есть то "делаешь все правильно", о чем говорится в исходном посте.
Поэтому если тебе важна скорость - надо брать мотоцикл
Так-то оно так, но если говорить об абстрактной скорости языка, для получения объективного результата условия тестирования должны быть идентичными, а не квадратичный против линейного.
А зачем говорить об абстрактной скорости языка? Реальность такова, что для подавляющего большинства задач важно соблюсти приемлемую алгоритмическую сложность и решение будет достаточно "быстрым". И если что-то работает медленно - с вероятностью 99% это из-за говнокода алгоритмически неэффективных решений, а не из-за скорости языка.
О чем и говорится в посте.
ИЛ-2 Штурмовик - довольно крутая для своего времени игра, большая часть написана на Java. Сейчас многие игры под Unity пишутся на C#, который тот же Java.
А что касается самих графических движков - это и есть те самые 1% задач.
Вроде бы там используется шарп, только очень урезанный, всё лишнее выкинуто, чтобы скорости добавить.
Ну и да в юнити всё ресурсоёмкое написано не на шарпе.
И сколько процентов этого ресурсоемкого от общего числа кода, написанного в геймдеве под юнити?
Может быть, просветите меня, в чем между ними столь принципиальная разница?
По скорости, кстати, еще вопрос, что быстрее: https://dev.by/news/java-protiv-c-kakoy-yazyk-proizvoditelne...
А зачем говорить об абстрактной скорости языка?Затем, что в посте говорится о быстрых языках, а не о быстрых решениях.
В посте говорится о том, что все языки достаточно быстрые чтобы твоя задача работала настолько быстро, насколько требуется, если ты все делаешь правильно. И что аргумент "мой код работает медленно потому что это все питон/джава/джаваскрипт, а не плюсы" в большинстве случаев не канает.
Забавно, что столько людей с этим спорят. Интересно, многие из них реально работают программистами? Сейчас и правда так все плохо, или это просто ошибка выборки?
Потому что все не так просто, есть ещё проблемы выделения памяти, проверки границ массивов, проблемы роста массива/маппа работа сборщика мусора.
Доберётесь до Клоди, поймёте что всё ещё сложнее.
Простой С позволяет выкинуть всё подчистую, тупо ячейки памяти и указатели, цена - любой неверный шаг - выстрел в ногу.
Простой С позволяет выкинуть всё подчистуюВ теории это хорошо звучит. На практике, если задача более-менее сложная, одно из двух - или тебе придется самому реализовывать все необходимое, или решать более простыми, возможно, менее эффективными средствами... Либо юзать либы.
Конечно, можно сделать вместо массива лист, над которым хеш-мапу для быстрой индексации... Но это же надо кодить! А лень. Да и не каждый кодер, с пеной у рта доказывающий, что надо писать на си, шоб быстро было, сможет это сделать. В то время как, к приемеру, на питоне это уже было бы сделано за нас.
Вот и получается, что решая задачу на более "быстром" языке, можно в итоге получить более медленное решение.
Если же использовать либы - ты точно так же, как и в случае языков более высокого уровня, теряешь часть контроля над происходящим. И точно так же теряешь в производительности из-за того, что либы универсальны, а не заточены конкретно под твою задачу.
Ну все давно пришли к варианту - сначало делаем на самом высоком уровне - скриптовой язык типо питона/руби/жс, ну и на кложуре для упоротых.
Потом меняем и заменяем проблемные места на уровень ниже, потом ещё ниже, вплоть до си.
Да ладно, миллиона. Сотни, максимум тысячи хватит, чтобы более эффективный алгоритм выиграл. Поспорим?
Интересно, те, кто меня активно минусят, правда не понимают, что в реальных задачах ты не делаешь, скажем, миллион операций с плавающей точкой, а все-таки реализуешь алгоритмы? И что быстродействие в первую очередь зависит от сложности алгоритма, а вовсе не от языка?
в реальных задачах ты не делаешь, скажем, миллион операций с плавающей точкой, а все-таки реализуешь алгоритмы?
Что мешает реализовать алгоритм, который выполнит миллион операций с плавающей точкой?
И что быстродействие в первую очередь зависит от сложности алгоритмаВот даже как. O(n) на счётах будет быстрее, чем О(n^2) на Xeon?
Что мешает реализовать алгоритм, который выполнит миллион операций с плавающей точкой?
Даже не знаю как ответить... Отсутствие необходимости в решении таких задач?)
Вот даже как. O(n) на счётах будет быстрее, чем О(n^2) на Xeon?Вы не поверите. Допустим, на счетах я выполняю операцию за минуту. На Xeon - за 10^-9 секунды. При n = 100 млрд счеты выиграют.
Отсутствие необходимости в решении таких задач?)Just for fun.
Алгоритм - это набор инструкций, описывающих необходимые действия. Стало быть, можно написать такой набор, который выполнит миллион операций с плавающей точкой.
При n = 100 млрд счеты выиграютА при n = 100 счёты проиграют. Значит, не только сложность как таковая имеет значение.
В общем, я понял. Надо пилить пост. В комментах спорить - только рейтинг зря терять)
Вообще забавно. Однажды мне встретился заказчик с идеей "перепишите вот это на си, шоб летало". Это при том, что в его программе 99% времени уходило на файловые операции, которых в принципе можно было избежать. Думал, это он такой уникум, ан нет - оказывается, непонимание базовых принципов оптимизации - распространенная проблема...
IT-юмор
5.6K поста52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору