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