Далеко не всем. Писать статьи о неудачах как то не принято. У меня аналогичная ситуация: мышка год спустя начала дико глючить, написал в тех поддержку, посоветовали проделать некоторые манипуляции (типа перекинуть в другой слот, выключить её на время, сильно понажимать на кнопки чтобы статическая энергия пропала и т.д.). Помогло на месяц. Снова им написал — тупо игнорят, ничего не отвечают. В результате в приступе ярости стукнул мышку кулаком, после чего она вообще отказалась работать (хотя внешне цела).
Вот теперь у меня дилемма: привык к трекболу, достойных аналогов лоджитековскому нету, а платить еще раз 80 дол. чтобы год попользоваться не хочу.
Даже тесты автомобильных роботизированных пилотов не могут по скорости обойти профессиональных гонщиков у которых очень сильно развита мышечная память. Ну и к тому же человек более рискован, чем робот.
На 1000 мл. подсолнечного масла в маленьких бутылках уходит 2 заготовки, а для больших 1. Аргумент по коробках тоже мимо, по крайней мере пока не известны габариты коробки и бутылок.
Не совсем понимаю, вы критикуете механизмы или примеры? Некоторые примеры действительно подобраны неудачно, но с большинством механизмов я согласен.
Кстати с последним пунктом я сам сталкивался в жизни (правда я бы его «изюминкой» не назвал): красиво и гармонично установленный рекламный стенд в торговом центре привлекал значительно меньше внимание, чем когда его установили небрежно. Если человек не идёт с целью осмотреть всё вокруг, то обращает он внимание как раз на такие «нетипичные» вещи.
А что собственно говоря не корректно? Сравнение чтение и записи ассоциативных массивов на разных языках это чуть более чем полностью не корректно? Вы меня конечно извините, но я же не сравниваю операцию умножения с отрисовкой окна.
То что код говно я знаю, потому и написал, что уверен, что его можно оптимизировать до разумных пределов. К сожалению других ассоциативных масивов на плюсах я не знаю, а то, что map не использует хеш-таблицы я честно не знал и для меня на самом деле не понятно такое решение.
Ну да ладно, предоставьте решение лучше. Вот человек заявляет, что С++ даёт ощутимые преимущества в скорости выполнения кода абсолютно во всех операциях в которых слабым звеном является сам код, но почему то рабочего примера не предоставил, а занимается только пустозвонством и оскорблениями выставляя это неопровержимыми фактами.
Да любой код на плюсах с шаблонами _всегда_ быстрее по сравнению с кодом на дельфи с виртуальными методами/указателями на функцию. Как частный случай — это лямбды.
В Делфи тоже есть подобие шаблонов, называется оно только по другому — дженерики. Провел эксперимент: написал 2 похожие по функционалу операции работы с шаблонными объектами, а именно запись в ассоциативный массив и чтение из ассоциативного массива. Одна программа на Делфи ( pastebin.com/Y9CGvmJ7 ), вторая на С++ ( pastebin.com/AeQmL3ux ). Обе программы скомпилированы со стандартными настройками Release конфигурации проекта. Использовались Delphi 2010 и VS 2012.
Запускаем тест.
Делфи:
Reading file speed: 63 ms.
Adding to the dictionary: 156 ms.
Dictionary reading: 109 ms.
C++:
Reading file speed: 516 ms.
Adding to the dictionary: 797 ms.
Dictionary reading: 500 ms.
И _ВНЕЗАПНО_ «всегда быстрее С++» проиграл с умопомрачительным разрывом, что доказывает, что программист в большей мере влияет на скорость работы программы чем компилятор, потому что в данном случая я просто перевел код с одного языка на другой.
Я не спорю, что можно оптимизировать С++ код и значительно его ускорить, но я очень сильно сомневаюсь, что вам удастся добиться значительно лучших результатов чем в исходном (под значительно лучшими я имею ввиду прирост в скорости хотя бы на 25%).
смотря как это язык выбирать.
Так как мы обсуждение ведем в ветке о Делфи, то давайте отталкиваться именно от Делфи. Назовите любой, который побьёт в любых тестах по скорости работы делфи код и при этом будет сопоставим с удобством разработки.
Я вроде с этим и не спорил. Я со вторым утверждением спорил. Что скорость программы при прочих равных не зависит от ЯП. Зависит. И очень сильно зависит.
А я и не говорил, что не зависит, более того она по любому зависит, по другому и быть не может.
Угу, только проблема в том, что таких идеальных программистов нету в реальной жизни. А если вспомнить, что обычно чем быстрее алгоритм, тем он сложнее…
Я никогда не видел больных раком, но это не значит, что их нету.
Вроде простая мысль же. Если на выходе компилятора быстрый код, значит вероятность что тебе придется этот код оптимизировать меньше.
Два слова: «единичные случаи». Можете привести больше примеров доминирование одного языка программирования по скорости над другим, хотя бы десяток? А если я приведу диаметрально противоположные примеры для тех же языков, то что это значит?
К решению проблемы нужно подходить с умом. Пример: машина однозначно быстрее за велосипед, но в то же время велосипед легко обойдёт автомобиль в плотном трафике, потому есть смысл использовать как один, так и другой вид транспорта в зависимости от ситуации.
Вы думаете, что я не понимаю простых вещей, но это вы не понимаете меня и то, что я пытаюсь вам сказать. Если выкидывать слова из контекста, то конечно же я не прав, но что именно в моём первом сообщении не правда? Вы хотите сказать, что:
1. Смена языка однозначно значительно ускорит программу? Вы на 100% уверены?
2. Скорость работы программы не зависит от программиста? Да это даже смешно обсуждать.
А оптимизация — это очень часто скатывание в говнокод, повышенная вероятность ошибок и тд.
А это уже однозначно зависит от программиста и больше не от чего другого. У одних и с первого раза нормальный код не получается, а другие внеся десятки изменений умудряются получить чистый и читаемый код.
Вас не в ту степь несёт. Вы мне пытаетесь доказать, что язык имеет значение в скорости работы программы. Спасибо, я это знаю, я этого не отрицал и говорил совсем о другом. Я говорил о том, что для программиста, который винит медленную скорость работы программы язык программирования, смена этого языка не очень то и поможет, потому что в первую очередь нужно оптимизировать алгоритмы. Плохо оптимизированный алгоритм будет на столько же плохо оптимизирован и на другом языке программирования. И не обязательно переписывать всю программу, можно переписать только узкие места. И ваши единичные примеры это доказывают. Вот сколько вы примеров доминирования в скорости работы одного языка над другим можете привести? Хотя бы десяток осилите?
Если пишут ПО люди равной квалификации, то как раз наоборот, единственное от чего зависит скорость результирующего продукта — это язык/компилятор.
Это да, но если код изначально плохо оптимизирован, то смена языка программирования не даст значительного прироста в скорости. Потому я и написал «ожидать значительного ускорения работы программ не стоит». А причина так плохо о программистах думать у меня та, что они решили полностью переписать все программы (если это действительно правда), а не только узкие места. Знаю я таких горе программистов, у них все виноваты: тугие компьютеры, криворукие пользователи, тормозная Делфи, но только не они.
Я согласен, в Делфи есть свои узкие места, я их обычно обхожу написанием библиотеки на C/C++ с нужным мне функционалом, но в целом язык не на столько медленный, чтобы вот так взять и переписывать гигантские проекты на другой.
Я сам бывал в подобной ситуации: есть в программе функционал, смотрю на него и понимаю, что быстрее уже не сделаешь, а тут мне один из пользователей говорит, что у конкурентов такой же функционал работает в 2 раза быстрее (программа на C#). Смотрю — действительно так. Начинаю оптимизировать свой код и знаете что? — всегда мне удавалось оптимизировать его до аналогичной либо большей скорости выполнения. А вот такого, что из-за Делфи все очень медленно работает и ничего с этим не поделать на моей практике еще не было.
Во-первых, я написал «в большей мере от программиста», а не «только от программиста и не от чего либо другого», а во-вторых сравнивать компилируемый язык программирования с интерпретируемым в быстродействии — это как минимум глупо. Вот если бы делфи был интерпретируемым языком программирования и написали, что от него отказываются из-за не большой скорости выполнения, тогда и вопроса не возникло.
Вот теперь у меня дилемма: привык к трекболу, достойных аналогов лоджитековскому нету, а платить еще раз 80 дол. чтобы год попользоваться не хочу.
Даже тесты автомобильных роботизированных пилотов не могут по скорости обойти профессиональных гонщиков у которых очень сильно развита мышечная память. Ну и к тому же человек более рискован, чем робот.
Кстати с последним пунктом я сам сталкивался в жизни (правда я бы его «изюминкой» не назвал): красиво и гармонично установленный рекламный стенд в торговом центре привлекал значительно меньше внимание, чем когда его установили небрежно. Если человек не идёт с целью осмотреть всё вокруг, то обращает он внимание как раз на такие «нетипичные» вещи.
То что код говно я знаю, потому и написал, что уверен, что его можно оптимизировать до разумных пределов. К сожалению других ассоциативных масивов на плюсах я не знаю, а то, что map не использует хеш-таблицы я честно не знал и для меня на самом деле не понятно такое решение.
Ну да ладно, предоставьте решение лучше. Вот человек заявляет, что С++ даёт ощутимые преимущества в скорости выполнения кода абсолютно во всех операциях в которых слабым звеном является сам код, но почему то рабочего примера не предоставил, а занимается только пустозвонством и оскорблениями выставляя это неопровержимыми фактами.
В Делфи тоже есть подобие шаблонов, называется оно только по другому — дженерики. Провел эксперимент: написал 2 похожие по функционалу операции работы с шаблонными объектами, а именно запись в ассоциативный массив и чтение из ассоциативного массива. Одна программа на Делфи ( pastebin.com/Y9CGvmJ7 ), вторая на С++ ( pastebin.com/AeQmL3ux ). Обе программы скомпилированы со стандартными настройками Release конфигурации проекта. Использовались Delphi 2010 и VS 2012.
Запускаем тест.
Делфи:
Reading file speed: 63 ms.
Adding to the dictionary: 156 ms.
Dictionary reading: 109 ms.
C++:
Reading file speed: 516 ms.
Adding to the dictionary: 797 ms.
Dictionary reading: 500 ms.
И _ВНЕЗАПНО_ «всегда быстрее С++» проиграл с умопомрачительным разрывом, что доказывает, что программист в большей мере влияет на скорость работы программы чем компилятор, потому что в данном случая я просто перевел код с одного языка на другой.
Я не спорю, что можно оптимизировать С++ код и значительно его ускорить, но я очень сильно сомневаюсь, что вам удастся добиться значительно лучших результатов чем в исходном (под значительно лучшими я имею ввиду прирост в скорости хотя бы на 25%).
Так как мы обсуждение ведем в ветке о Делфи, то давайте отталкиваться именно от Делфи. Назовите любой, который побьёт в любых тестах по скорости работы делфи код и при этом будет сопоставим с удобством разработки.
А я и не говорил, что не зависит, более того она по любому зависит, по другому и быть не может.
Я никогда не видел больных раком, но это не значит, что их нету.
Два слова: «единичные случаи». Можете привести больше примеров доминирование одного языка программирования по скорости над другим, хотя бы десяток? А если я приведу диаметрально противоположные примеры для тех же языков, то что это значит?
К решению проблемы нужно подходить с умом. Пример: машина однозначно быстрее за велосипед, но в то же время велосипед легко обойдёт автомобиль в плотном трафике, потому есть смысл использовать как один, так и другой вид транспорта в зависимости от ситуации.
Вы думаете, что я не понимаю простых вещей, но это вы не понимаете меня и то, что я пытаюсь вам сказать. Если выкидывать слова из контекста, то конечно же я не прав, но что именно в моём первом сообщении не правда? Вы хотите сказать, что:
1. Смена языка однозначно значительно ускорит программу? Вы на 100% уверены?
2. Скорость работы программы не зависит от программиста? Да это даже смешно обсуждать.
А это уже однозначно зависит от программиста и больше не от чего другого. У одних и с первого раза нормальный код не получается, а другие внеся десятки изменений умудряются получить чистый и читаемый код.
Это да, но если код изначально плохо оптимизирован, то смена языка программирования не даст значительного прироста в скорости. Потому я и написал «ожидать значительного ускорения работы программ не стоит». А причина так плохо о программистах думать у меня та, что они решили полностью переписать все программы (если это действительно правда), а не только узкие места. Знаю я таких горе программистов, у них все виноваты: тугие компьютеры, криворукие пользователи, тормозная Делфи, но только не они.
Я согласен, в Делфи есть свои узкие места, я их обычно обхожу написанием библиотеки на C/C++ с нужным мне функционалом, но в целом язык не на столько медленный, чтобы вот так взять и переписывать гигантские проекты на другой.
Я сам бывал в подобной ситуации: есть в программе функционал, смотрю на него и понимаю, что быстрее уже не сделаешь, а тут мне один из пользователей говорит, что у конкурентов такой же функционал работает в 2 раза быстрее (программа на C#). Смотрю — действительно так. Начинаю оптимизировать свой код и знаете что? — всегда мне удавалось оптимизировать его до аналогичной либо большей скорости выполнения. А вот такого, что из-за Делфи все очень медленно работает и ничего с этим не поделать на моей практике еще не было.