В лучшем случае Swift в 7.9x раз медленнее чем Objective-C. Результат, конечно, не ахти, но то что язык находится на стадии бета-тестирования, оставляет надежды а оптимизацию по скорости.
Здравствуйте, Klapaucius, Вы писали:
K>Откровенно говоря, не вижу особого смысла сравнивать Swift с "современными языками". Всякие Go-Swiftы — это подзадержавшиеся Явы-Шарпы, с ними и имеет смысл сравнивать. Языки вроде окамлов-хаскелей-идрисов — это другие поколения и эпохи, сравнивая с ними можно получить только один ответ: в госвифтах все плохо, ничего нет.
Ну да... Ничего нет, кроме детерминированных требований к памяти и хорошей производительности бинарника.
Зачем опять и снова игнорить реальность? Ну не может на сегодня взлететь "настоящее ФП", типа Хаскеля, без самой настоящей суперкомпиляции. Дай этим технологиям еще лет 20 (и это еще оптимистично).
Да и не самый лучший этот Хаскель даже для ФП. Одни лишь name conventions, вшитые в язык, с разбегу делают его не более, чем исследовательским. Конечно, когда мощщи компов и соответствующие компиляторы созреют, то сразу появятся более вменяемые ФП-языки и займут своё вполне заслуженное место.
Re[2]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, kaa.python, Вы писали:
KP>В лучшем случае Swift в 7.9x раз медленнее чем Objective-C. Результат, конечно, не ахти, но то что язык находится на стадии бета-тестирования, оставляет надежды а оптимизацию по скорости.
KP>http://www.splasmata.com/?p=2798
KP>P.S. тесты ну ооочень синтетические.
Очень любопытно) Похоже, что этот их Sequence интерфейс почему-то абсолютно не инлайнится...
Здравствуйте, vdimas, Вы писали:
K>>Откровенно говоря, не вижу особого смысла сравнивать Swift с "современными языками". Всякие Go-Swiftы — это подзадержавшиеся Явы-Шарпы, с ними и имеет смысл сравнивать. Языки вроде окамлов-хаскелей-идрисов — это другие поколения и эпохи, сравнивая с ними можно получить только один ответ: в госвифтах все плохо, ничего нет.
V>Ну да... Ничего нет, кроме детерминированных требований к памяти и хорошей производительности бинарника.
А где эта хорошая производительность бинарника ? По тестам на одном уровне с динамическими, до джавы как до небес, не говоря про c#
Здравствуйте, Ikemefula, Вы писали:
V>>Ну да... Ничего нет, кроме детерминированных требований к памяти и хорошей производительности бинарника. I>А где эта хорошая производительность бинарника ? По тестам на одном уровне с динамическими, до джавы как до небес, не говоря про c#
Здравствуйте, Klapaucius, Вы писали:
I>>В том то и дело, что речь шла про контейнеры, т.е. IEnumerable и тд. Товарищ просто не знал, как это сделано в Swift и решил перепрыгнуть на проблемы рантайма и другие, которые только ухитрился углядеть.
K>Да я сразу понял, что он контратаковал на другом направлении. Какая разница, если все равно можно решение дать?
Ниче я не контратаковал. Сам же Ikemefula по-невнимательности "допилил" исходное условие до, фактически, тупикового в версии C#.
Поймать я хотел именно его, он же сам напросился. )))
Но, видать, зря старался, судя по: http://www.rsdn.ru/forum/philosophy/5637841.1
===========
И да. Сравнивать языки можно, действительно, по разным прикладным сценариям, а не только по тем, которые тщательно выбирает лишь одна сторона. Но они уже пытаются и это оспорить. Давно я в этом дурдоме не участвовал. )))
Здравствуйте, Ikemefula, Вы писали:
V>>Чего-чего? Там были все демонстрации. I>Не было. Последняя твоя отписка была вот такой: "нициализируешь локальную переменную и вперед далее вниз по правилам процедурной/функциональной декомпозиции"
Ты меня с кем-то путаешь. Я тебе даже код давал, демонстрирующий работу двух разных диспетчеров и показывающих, что кооперативная многозадачность не имеет проблем с конкурентным доступом к ресурсам. И что модель асинхронщины меньше всего зависит от твоего кода и больше всего от диспетчера, который дергает за нитки автоматы-продолжения.
I>Здесь, судя по всему, такая же история
Здесь ты случайно изменил условие задачи так, что оно резко стало не в пользу C#. Медвежью услугу оказал своей священной корове, кароч. ))
Ну и всерьез воспринимать сие обсуждение после такого: http://www.rsdn.ru/forum/philosophy/5637841.1
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
V>>>Чего-чего? Там были все демонстрации. I>>Не было. Последняя твоя отписка была вот такой: "нициализируешь локальную переменную и вперед далее вниз по правилам процедурной/функциональной декомпозиции"
V>Ты меня с кем-то путаешь. Я тебе даже код давал, демонстрирующий работу двух разных диспетчеров и показывающих, что кооперативная многозадачность не имеет проблем с конкурентным доступом к ресурсам. И что модель асинхронщины меньше всего зависит от твоего кода и больше всего от диспетчера, который дергает за нитки автоматы-продолжения.
Ничего не путаю, ты показал код который использует очередь для синхронизации.
Про кооперативную многозадачность — ты снова настаиваешь на той же ошибке. Скажем, все буквари по многозадачности утверждают, что гонки это особенность любой многозадачности
I>>Здесь, судя по всему, такая же история
V>Ты не в состоянии отличить обобщенное решение от частного.
Ты всего лишь нашел способ увильнуть от ответа, вместо обсуждения контейнеров перескочил на другие вопросы
Если подробно — нужно написать две функции (или что-то в таком роде): scalarProduct и, скажем, main. Функция scalarProduct должна принимать две последовательности (это могут быть массивы, связные списки, или ещё что-то — не важно) целых чисел и вычислять их скалярное произведение. При этом она должна падать, если длины этих последовательностей различны. Важное (критически) уточнение: это должно происходить НА СТАДИИ КОМПИЛЯЦИИ!!!
Сию задачу разбирали здесь минимум дважды. Она про тот самый параметрический полиморфизм времени исполнения, который ни разу не нужен в ваших примерах.
Так в чем твои-то трудности?
Ну и вообще парень там нагнал пурги:
Дальше ещё веселее. Вы запускаете XCode заново, он восстанавливает тот же файл, снова прогоняет его через компилятор, тот снова сегфолтится, и XCode снова вылетает.
Я не смог запилить такой код, который проверял бы мой тест и при этом не сегфолтился.
А в блокноте не судьба была? ))
Скорее всего компилятор в режиме максимально-глубокого вывода типов для интелисенса пытается рекурсивно выводить типы, но конца этому процессу для конкретно этой задачи НЕТ. ))
Поэтому там падает только интелиссенс среды разработки, насколько я понял из ссылки.
А ты льешь воду на мельницу клинических идиотов, помогая им гнать пургу. Ну бета еще среды разработки, фиг с ней. Ты разве не видел, как регулярно падали не только беты, но и сами MSVS до 2003-й включительно? И даже с сервис паками?
У меня и 10-я студия нет, нет, да упадёт иногда как раз во время парсинга изменений файла при пошаговой отладке.
А по-существу той задачи, там же по ссылке правильно заметили (и здесь когда-то говорили аналогичное):
чтобы поддерживать одинаковость типов, тебе приходится везде обрабатывать вектора вместе. А в этом случае разница между парой векторов и вектором пар исчезает.
Т.е. исходную задачу можно отрефакторить в эквивалентную, не требующую параметрического полиморфизма времени исполнения. В любом случае, в том же Хаскеле, компилятор способен пропустить через тайп-чек эту задачу только тогда, когда он формирует эти вектора ОДНОВРЕМЕННО. Если же попытаться сформировать их раздельно, то тайпчек навернется даже в Хаскеле, бо нет возможности сформировать эти вектора раздельно и проверить одинаковость их типов.
Кароч, по-настоящему эту задачу способны решить только языки с полной поддержкой зависимых типов, а к ним ни C#, ни Swift, ни Хаскель не относятся.
Но что характерно, что текущая система шаблонов С++ ПОЗВОЛЯЕТ в будущем добавить поддержку зависимых типов без какой-либо переделки синтаксиса (правда, с текущим ограничением на целочисленный аргумент зависимого значения). Т.е. система типов Swift тоже в будущем сможет быть развита до аналогичного. А вот в C# — никогда и ни при каких обстоятельствах. Принципиально невозможно. Вот так по-дебильному (C) дизайн генериков сделан. Так шта, накося выкуси. )))
========
Более того, при полноценной поддержке зависимых типов в этой задаче исчезает надобность рекурсивного определения типов, за "глубину" будет отвечать целочисленное значение, определяющее точный тип. Так шта, XCode падать не будет. ))
Здравствуйте, vdimas, Вы писали:
K>>Да я сразу понял, что он контратаковал на другом направлении. Какая разница, если все равно можно решение дать?
V>Ниче я не контратаковал. Сам же Ikemefula по-невнимательности "допилил" исходное условие до, фактически, тупикового в версии C#. V>Поймать я хотел именно его, он же сам напросился. ))) V>Но, видать, зря старался, судя по: http://www.rsdn.ru/forum/philosophy/5637841.1
Ты, вероятно, не понял, но тебя просили показать аналог IEnumerable. Смотри внимательно — автор вопроса дважды явно тебе сообщил и дал решение ВМЕСТО тебя
Вместо того, чтобы хотя бы намекнуть на протоколы, ты понес какую то галиматью про функции, подкрепив это кодом на сиплюсе
Здравствуйте, alex_public, Вы писали:
_>Эммм, очень странно добиваться от vdimas этого кода после того, как D. Mon кинул ту ссылку на определение интерфейса (к которoму кстати умеет цепляться foreach) для последовательностей в Swift'e. Имея подобное, эту вашу задачку решит любой начинающий. ))) Просто это дело находится (видимо) в стандартной библиотеке языка, а описания к ней в текущей документации на язык нет, так что не обладая установленной средой (и не полазив по исходникам) vdimas'у довольно проблематично было дать красивый ответ. Но теперь то, что вы продолжаете цепляться? Или всё ждёте этот пример школьного кода? )
Красиво ответить можно было и без этих базовых интерфейсов на основе того решения, которое я уже описал словесно раз пять — через подачу делегата в стиле IoC...
Всё намного проще. Я пока тупо тянул время, бо в эти выходные ни с какой виртуалкой макоси возиться не собирался.
ЮБК, море, солнце, местное вино... и пускай злопыхатели подождут.
Здравствуйте, vdimas, Вы писали:
V>>>Ну да... Ничего нет, кроме детерминированных требований к памяти и хорошей производительности бинарника. I>>А где эта хорошая производительность бинарника ? По тестам на одном уровне с динамическими, до джавы как до небес, не говоря про c#
V>Ты тестировал?
Если ты не заметил, то результаты тестирования уже выложили прямо в этом треде. Про них и речь, а именно, про отставание от 7 до 49 раз относительно сиплюса
Здравствуйте, vdimas, Вы писали:
_>>Эммм, очень странно добиваться от vdimas этого кода после того, как D. Mon кинул ту ссылку на определение интерфейса (к которoму кстати умеет цепляться foreach) для последовательностей в Swift'e. Имея подобное, эту вашу задачку решит любой начинающий. ))) Просто это дело находится (видимо) в стандартной библиотеке языка, а описания к ней в текущей документации на язык нет, так что не обладая установленной средой (и не полазив по исходникам) vdimas'у довольно проблематично было дать красивый ответ. Но теперь то, что вы продолжаете цепляться? Или всё ждёте этот пример школьного кода? )
V>Красиво ответить можно было и без этих базовых интерфейсов на основе того решения, которое я уже описал словесно раз пять — через подачу делегата в стиле IoC...
V>Всё намного проще. Я пока тупо тянул время, бо в эти выходные ни с какой виртуалкой макоси возиться не собирался.
Все почти верно, кроме одной детали — тянуть время ты можешь годами, или выдать "пфф любой студент за два часа, мы не в детсаде"
Вспомнишь сам или ссылкой дать ?
Re[2]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, kaa.python, Вы писали:
KP>В лучшем случае Swift в 7.9x раз медленнее чем Objective-C. Результат, конечно, не ахти, но то что язык находится на стадии бета-тестирования, оставляет надежды а оптимизацию по скорости.
KP>P.S. тесты ну ооочень синтетические.
Даже по этим синтетическим тестам видно, что язык пока что конкурирует с динамическими языками. С учетом того, что objective c отстаёт от модных компилеров С++, то разница между свифтом и objective от 7 до 49 раз это мягко говоря отстой. Шота выглядит как "с места и в лужу"
Здравствуйте, vdimas, Вы писали:
V>Скорее всего компилятор в режиме максимально-глубокого вывода типов для интелисенса пытается рекурсивно выводить типы, но конца этому процессу для конкретно этой задачи НЕТ. ))
Т.е. ты предполагаешь, что при работе с IDE компилятор Swift'a работает в особом режиме, а из консоли его примеры компилировались бы?
V>Кароч, по-настоящему эту задачу способны решить только языки с полной поддержкой зависимых типов, а к ним ни C#, ни Swift, ни Хаскель не относятся.
V>Но что характерно, что текущая система шаблонов С++ ПОЗВОЛЯЕТ в будущем добавить поддержку зависимых типов без какой-либо переделки синтаксиса (правда, с текущим ограничением на целочисленный аргумент зависимого значения). Т.е. система типов Swift тоже в будущем сможет быть развита до аналогичного. А вот в C# — никогда и ни при каких обстоятельствах. Принципиально невозможно. Вот так по-дебильному (C) дизайн генериков сделан. Так шта, накося выкуси. )))
.
V>Более того, при полноценной поддержке зависимых типов в этой задаче исчезает надобность рекурсивного определения типов, за "глубину" будет отвечать целочисленное значение, определяющее точный тип. Так шта, XCode падать не будет. ))
При чем тут сама задача? Ты совсем не умеешь отвлекаться от деталей и видеть смысл?
Смысл простой: компилятор очень падучий, и XCode вместе с ним. Потому тестировать сложно. Про задачу забудь, не о ней речь.
Даже проще примеры были: при попытке описать рекурсивный алгебраик компилятор сегфолтится.
Re[3]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, Ikemefula, Вы писали:
I>Даже по этим синтетическим тестам видно, что язык пока что конкурирует с динамическими языками. С учетом того, что objective c отстаёт от модных компилеров С++, то разница между свифтом и objective от 7 до 49 раз это мягко говоря отстой. Шота выглядит как "с места и в лужу"
КОгда говоришь о Бета-версии какого-либо языка, стоит обсуждать предлагаемую им концепцию, но никак не производительность или стабильность сгенерированного кода. Это я не к тому, что Swift – это круто, я его еще даже не смотрел, а к тому, что другие составляющие куда как важнее
Re[2]: А вот и сравнения скорости Swift с Objective-C подоспели
