Здравствуйте, kaa.python, Вы писали:
KP>Да, интересно. Если почитать ответы, то получается что скорость Swift не уступает скорости Си, что приколько, я считаю
Он же вроде не уступает, если там отключить рантайм проверки. Это.. гм.. как бы не safe, что декларируется, как фича. Кстати, тебя не смущает, что язык проприетарный, да еще и заточенный под одну платформу?
Здравствуйте, MxMsk, Вы писали:
MM>Кстати, тебя не смущает, что язык проприетарный, да еще и заточенный под одну платформу?
Я пока не смотрел по нему доки, но если это именно что "замена Objective-C", т.е. язык для работы с Cocoa которой ни на каких платформах кроме как от Apple не существует, то нет, не смущает. Если же говорить о проприетарности, то исходя из политики Apple по отношению к другим низкоуровневым разработкам (LLVM, Clang, Darwin) я думаю что его откроют вскоре после релиза.
P.S. но я с UI дела практически не имею, так что у меня к языку разве что чисто академический интерес может проснуться (пока мне на него пофигу).
Re[4]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, kaa.python, Вы писали:
KP>КОгда говоришь о Бета-версии какого-либо языка, стоит обсуждать предлагаемую им концепцию, но никак не производительность или стабильность сгенерированного кода. Это я не к тому, что Swift – это круто, я его еще даже не смотрел, а к тому, что другие составляющие куда как важнее
Судя по SO все еще хуже, чем по твоей ссылке — разница на порядок даже если сравнивать с питоном. Не понимаю как можно было прикрутить проверки тиа выход за границу массива и тд, что бы это работало хуже чем питоне
Здравствуйте, vdimas, Вы писали:
V>Да нет. Оказывается, что ad-hoc полиморфизм не поддерживается в полной мере генериками дотнета, только и всего. Иначе бы он сам подхватывал переопределённые операторы.
Дженерики — это параметрический полиморфизм. Никакой ad-hoc полиморфизм они поддерживать и не должны. И никакого "подхватывания операторов" не нужно. Нужно делать как в моем примере реализовано, только с автоподстановкой словарей и подправленным синтаксисом, чтоб ограничения квантификации нормально выглядели, можно было операторы использовать и т.д.
Ну и классы типов/имплементации должны в стандартной библиотеке быть.
V>Если в полноценной реализации, то нужен, ес-но. Но для привычного ООП он почти всегда "недо-", бо идет только по первому аргументу this.
Продемонстрированная мной техника это ограничение обходит.
V>Ну а что делать, если всё кривое? )))
Делать прямым там, где возможно. Обсуждаемое сделать прямым можно одними средствами компилятора, все что для этого нужно (более-менее нормальный полиморфизм, инлайн методов структур и т.д.) CLR уже поддерживает.
V>Ты продемонстрировал костыль в условиях "недо-".
Это менее костыльно чем всякие "подхватывания". Недоделанность дотнетных дженериков совсем не в этом, а в том, что от конструктора типа нельзя абстрагироваться, нету higher-kinded полиморфизма. Ну так с этим и в сабже проблемы.
V>Нет. Зависимость конкретных типов T->C должна быть неявной. Явное её указание — избыточность, делает решение недо-обобщенным.
Явное указание — это, конечно, избыточность, но "недообобщенным" оно решение не делает.
V>Можно так: V>
V>T Avg<T>(this IEnumerable<T> xs) where T : INumber<T>, new()
V>
V>Как и в Хаскель, собсно. (только с той разницей, что в дотнете INumber<T>, сцуко, описывает контракт только по одному аргументу this... но и этого могло бы хватить для арифметики)
Нет, ключевое отличие тут в том, что ":" задает отношение подтипирования, которого в хаскеле нет. В моем решении его (между T и C) также нет и не должно быть.
V>Я тебе уже показал абзацем выше аналог на C# того, как это есть в Хаскеле. Заканчивай уже спекулировать.
Нет, это не аналог того, что есть в хаскеле. Аналог того, что есть в хаскеле показал я.
V>Ес-но, реализация арифметических операторов для Complex должна быть где-то описана. Но не дважды же!
Ну так она и не описана дважды:
public struct ComplexReal : CReal<Complex>
{
public Complex Div(Complex a, Complex b) { return a/b; }
public Complex Add(Complex a, Complex b) { return a+b; }
public Complex FromInt(int a) { return new Complex(a,0); }
}
вызываются библиотечные реализации сложения и деления. Если бы мы сами определеяли Complex — могли бы не описывать операции только для Complex, а определить их прямо в имплементации класса. И тот и другой подход используются в хаскеле.
V>В Хасклеле бери любую либу с каким-нить MegaComplex, да пользуйся. А в твоём решении на C# надо еще раз по операторам пройтись да продублировать их. Что-то не так в консерватории, не правда ли? ))
Очевидно, что надо просто положить инстансы в библиотеку и все, как в хаскеле обычно и делается.
Но нередко бывает и так, когда библиотека нужных инстансов не содержит. Тогда пользователь сам описывает инстансы-"сироты". Что собственно я и зделал в своем примере на C#.
V>Ммм... ты действительно не понял пару постов выше намек на то, как это надо было сделать в C#? ))
Понял, но я не согласен с тем, что в C# надо так делать. Надо было делать именно как я показал.
V>Блин, ты же сам всё правильно говорил про Хаскель! Модель типов дотнета позволяет делать так же. Просто не сделано для встроенных типов.
Продемонстрированная мной техника позволяет определять инстансы для любых типов.
В хаскеле, кстати, для "встроенных" типов полиморфизм вообще не поддерживается.
V>Но даже при этом можно было бы арифметические операторы подхватывать автоматом и на этапе генерации бинарников подставлять в тела генериков нужный код. Даже можно обойтись существующим стандартом на метаинформацию и байт-код, достаточно компилятором генерить фиктивный IOperators<> в байт-коде, а во время JIT-а просто знать этот интерфейс "в лицо" и при его фиктивной реализации просто подставлять статически-переопределенные операторы, тогда тебе не надо было бы ручками описывать свой ComplexReal.
Нет уж, лучше написать инстанс руками и положить в библиотеку, а в компилятор универсальный солвер для подстановки любых инстансов, чем встраивать в реализацию компилятора и рантайма какие-то подхватывания избранных операторов.
Да даже и без автоподстановки инстансов — все равно лучше.
V>А зачем параметрический полиморфизм в сценариях, где уточненные типы выводятся еще на этапе компиляции? V>Эдак тебя несет. Мы обсуждали конкретный пример, где параметрический полиморфизм времени исполнения не нужен ни разу.
Параметрического полиморфизма времени исполнения не существует, он бывает только времени компиляции. Этим он от завтипов отличается, для которых полное стирание типов осуществить нельзя.
V>Насмешил. В Хаскеле не всегда параметрический полиморфизм нужен в рантайм. 99% сценариев разруливаются на этапе компиляции, т.е. обобщенное программирование в этих сценариях не далеко ушло от С++ — обычная "текстовая подстановка" в итоге. Собсно, даже формат библиотек Хаскеля — это упакованный и размеченный результат парсинга текста (считай тупо AST исходников либы), а не объектный код.
Нет, это код, с которым могут поставляются, а могут и не поставляться "развертки", т.е. результат парсинга части кода. Развертки могут использоваться для оптимизации, но все работает и без них — просто медленнее. Это техническая деталь реализации межмодульной оптимизации, реализация параметрического полиморфизма от этого не зависит.
Упомянутый 1% сценариев — это экзистенциальные типы, там словарь действительно не может быть подставлен в комайл-тайм и ссылка на него хранится в объекте, как в ООП.
V>>>1. Ты ничего не решил, готового к использованию изкаробки обобщенного решения так и не было. В дотнете автоматическое решение возможно только на рефлексии, увы.
K>>Потому, что дотнетные разработчики (а точнее, принимающие решения) не читатели и не моргнув глазом пустили в свободное плаванье дизайнерское решение, которое целый фрактал проблем порождает.
V>А конкретно в этой ветке мне постарались надавать по щщам именно из-за попытки сравнения со "священной коровой". Я лишь заметил, что многих проблем C# в Swift нет.
Я сильно сомневаюсь, что обсуждаемая проблема в сабже решена нормально, а не в стиле C++.
V>Я не спорю, что до "чистых" языков ему далеко. Это гибрид и как любой гибрид состоит из компромиссов. Но в C# есть даже такие компромиссы, увы, которые вовсе не требовались. И ты наглядно их показал в своей собственной реализации yet another IArithmetic<T>.
Похоже на то, что и в сабже таких "компромиссов", которые не требовались, хватает.
V>И всё-таки в джаве и дотнете не в языке гвоздь, а в миллионах строк библиотек со сложным, но достаточно надежно оттестированным функционалом.
Ну да, правильно.
V>Хотя для value-типов для тех же генереков JIT генерит код, который нигде по-факту методы интерфейсов не вызывает!
Ну, на этом техника и основывается. если бы не это — реализовывать арифметику таким способом не было бы смысла.
V>Т.е. сие ограничение интерфейсов только на экземплярные методы можно было бы обойти, добавив возможность задавать некий "интерфейс для статических методов", как раз арифметика туда попала бы, а связь T->C в твоём примере была однозначной и не требовала бы явного задания. (Это был бы, конечно не интерфейс в ООП-смысле, а чистый "контракт", бо интерфейс описывает лишь контракт на экземплярные методы).
Зачем какие-то загадочные "интерфейсы для стат.методов" придумывать, если можно просто красиво оформить передачу словаря, т.е. описанную мной технику?
V>Что касается по-делу. Параметрический полиформизм генериков C# показывает свою силу только в рекурсивных, относительно типов, сценариях
Да, совершенно верно, полиморфная рекурсия например. И да, чтоб это использовать нужны более развитые возможности тайплевел-программирования, которых в шарпе нет.
Но вообще параметрический полиморфизм, а не шаблоны в дотнете ради раздельной компиляции сделаны. Передача словаря вполне с раздельной компиляцией совместима.
K>>Собственно, всякие костыльные воркараунды — единственные способы писать обобщенный код в индус триальных языках V>Ну вот мне сходу показалось, что в Swift таких воркараундов должно быть поменьше.
Здравствуйте, vdimas, Вы писали:
V>Ну да... Ничего нет, кроме детерминированных требований к памяти и хорошей производительности бинарника.
"Детерминированные требования к памяти" — это красиво звучит, но на практике означает только, что менеджер памяти там выигрывает по латентности у нормального ГЦ ценой проигрывания throughput и чуть менее чем всех языковых фич. ничего интересного в этом аспекте сабж не предлагает.
Хорошей производительности бинарника в сабже, я думаю, не будет, никто не станет ее до уровня плюсов доводить, останется на уровне "языков, использующих LLVM".
Т.е. код а ля лапшефортран будет работать со скоростью не сильно больше той, которую аналогичный код в лапшефортранном стиле на хаскеле показывает, а в случае сколько-нибудь высокоуровневого кода он хаскелю вообще проиграет.
По поводу суперкомпиляций и настоящего ФП.
1) На производительность низкоуровневого кода "настоящего ФП" она никак не повлияет, а проблема производительности высокоуровневого кода нигде не решена.
2) Я не особо верю в перспективы суперкомпиляции для языков без проверки завершимости, хотя я особо не разбираюсь в суперкомпиляии, я интересуюсь больше более простыми и практичными техниками, которые под это определение не подпадают.
3) Проблемы с производительностью низкоуровневого кода в "настоящем ФП" худо-бедно решаются использованием готовых бэкендов, на которые тратятся значительные (по сравнению с теми, что на ФП тратятся) человекочасы вроде LLVM. Остаются проблемы, которые рантаймом обусловлены, вроде дороговизны изменяемых массивов ссылок и т.д., в случае которых компилятор ничем не поможет.
4) Производительность вообще не главная проблема "настоящего ФП", многие популярные языки никаких успехов по части производительности кода никогда не показывали и не покажут.
Да и от сабжа я их не жду.
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Ikemefula, Вы писали:
K>>Нет, вывести такое следствие не из чего. Вот если бы были языки с равными инфраструктурами и сильно различающиеся по фичам — тогда можно было бы какие-то выводы делать. I>Хорошая инфраструктура почему то появляется только для самых убогих языков с твоей точки зреня. Тебе самому не смешно ?
Ну конечно не самых убогих. Но не далеко от этого. Посмотрите на список ваших "наиболее востребованных". Много ли языков более убогих чем они? Вот то-то и оно.
I>А что ты имел ввиду под требованием к качеству реализации ? Эти требования определяются исключительно ценой ошибки, а не применяемым языком.
Под требованием к качеству реализации я имел в виду хороший оптимизирующий компилятор или, например, продвинутый рантайм с нормальным сборщиком мусора (точным, перемещающим, с поколениями, параллельным и т.д.), поддержкой SMP. У 90% языков какой-нибудь Боэм, или треш-угар с подсчетом ссылок, если язык "академиеский" — может еще быть Чейни на страницу кода, написанный студентом за вечер. Никакого SMP, конечно.
I>А что тут знать. Компилируешь и смотришь, во что это выливается в итоге. Отсюда ясно, что ни перформанса, ни внятного расхода памяти нет и быть не может, при том, что нужно дизайнить внутреннее АПИ специальным образом.
Для паттерн-матчинга?
I>ФЯ смотрятся хорошо только в высокоуровневых алгоритмах, если их тяжело перевести в императивный вид. В низковровневых вещах разница любого ФЯ с простецким Си минимум в несколько раз.
ну так а я о чем? "Ну вот, вы же сами написали, что все, кроме C и C++. Остальные это ведь не только пара-тройка ФЯ но и бразиллион языков никакого отношения к ФП в основном не имеющих. Как видите, страшный синтаксис им никак не помог. При этом сабж явно не окажется в категории С/C++, а наоборот — в категории "остальные", в которой ФЯ часто смотрятся в смысле производительности очень хорошо. "
K>>Вопрос был в том, зачем делать убогим, если можно не убогим? Что мешает-то?
I>Полноценный ПМ можно всунуть только в полноценный ФЯ, со всеми его проблемами — перформансом и потреблением памяти. Это очень дорогая фича.
Не согласен, в отличие от комбинирования комбинаторов, которое если попытаться сделать нормально — целый "полноценный ФЯ" за собой притянут, паттерн-матчинг — фича достаточно консервативная.
K>>Нет, я не про убогие возможности, а именно про навороченность синтаксиса. I>В мейнстриме в код лазят самые разные люди, с разными скилами. Сишный синтаксис это своего рода костыль для таких вот людей, снижает уровень вхождения.
Вообще-то речь про всякие ужасы, которые читаются "по спирали" и т.д. Это уровень вхождения снижает? Серьезно?
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
I>>А что тут знать. Компилируешь и смотришь, во что это выливается в итоге. Отсюда ясно, что ни перформанса, ни внятного расхода памяти нет и быть не может, при том, что нужно дизайнить внутреннее АПИ специальным образом.
K>Для паттерн-матчинга?
Именно.
I>>Полноценный ПМ можно всунуть только в полноценный ФЯ, со всеми его проблемами — перформансом и потреблением памяти. Это очень дорогая фича.
K>Не согласен, в отличие от комбинирования комбинаторов, которое если попытаться сделать нормально — целый "полноценный ФЯ" за собой притянут, паттерн-матчинг — фича достаточно консервативная.
Тем не менее фича очень дорогая в использовании. Скажем в менеджед языках после декомпиляции получается какой то тихий ужас. В том же F# небольшая программа на страницу текста даёт восемь страниц генеренного кода.
I>>В мейнстриме в код лазят самые разные люди, с разными скилами. Сишный синтаксис это своего рода костыль для таких вот людей, снижает уровень вхождения.
K>Вообще-то речь про всякие ужасы, которые читаются "по спирали" и т.д. Это уровень вхождения снижает? Серьезно?
Здравствуйте, Ikemefula, Вы писали:
I>Тем не менее фича очень дорогая в использовании. Скажем в менеджед языках после декомпиляции получается какой то тихий ужас. В том же F# небольшая программа на страницу текста даёт восемь страниц генеренного кода.
Да, я видел, что F# плохо компилирует ПМ, но это проблема конкретной реализации, ПМ можно и хорошо компилировать. Там проблема не в объемах кода — написание разбора вручную тоже даст существенно больше кода, там проблема в том, что проверки, которые уже сделаны делаются снова и снова.
I>Что значит 'читаются "по спирали"' ?
Вторая картинка в гугле по запросу "clockwise spiral rule"
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Не согласен, в отличие от комбинирования комбинаторов, которое если попытаться сделать нормально — целый "полноценный ФЯ" за собой притянут
Ради интереса: можно в двух словах, зачем нужно комбинирование комбинаторов и что это вообще такое?
Нечто типа порождения функций из неких примитивов? Если да, то в чем преимущество перед простым вызовом одной функции из другой?
Re[3]: А вот и сравнения скорости Swift с Objective-C подоспели
Ого, при соответствующей опции компилятора получаем быстродействие как у C++? Похоже я был прав в предположение об отличном дизайне (в стиле D) языка.
Ну а тем, кому нужны все эти сомнительные проверки, видимо придётся ждать более стабильной версии компилятора, в которой их попытаются оптимизировать...
P.S. И откуда ты постоянно такие полезные достаёшь? )))
Re[4]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, Klapaucius, Вы писали:
K>Да, я видел, что F# плохо компилирует ПМ, но это проблема конкретной реализации, ПМ можно и хорошо компилировать. Там проблема не в объемах кода — написание разбора вручную тоже даст существенно больше кода, там проблема в том, что проверки, которые уже сделаны делаются снова и снова.
I>>Что значит 'читаются "по спирали"' ?
K>Вторая картинка в гугле по запросу "clockwise spiral rule" K>http://cskill.files.wordpress.com/2010/06/ex21.png
Я бы не сказал, что это типичный код для Си
Re[4]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, alex_public, Вы писали:
_>Ого, при соответствующей опции компилятора получаем быстродействие как у C++? Похоже я был прав в предположение об отличном дизайне (в стиле D) языка.
И внагрузку получаем отсутствие заявленых фич.
Re[5]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, Ikemefula, Вы писали:
I>И внагрузку получаем отсутствие заявленых фич.
Ну конкретно фича с проверками меня вообще не впечатлила. Не понял зачем её вообще ввели в язык такого уровня (в котором есть доступ к голым указателям и т.п.)...
Re[6]: А вот и сравнения скорости Swift с Objective-C подоспели
Здравствуйте, alex_public, Вы писали:
I>>И внагрузку получаем отсутствие заявленых фич.
_>Ну конкретно фича с проверками меня вообще не впечатлила. Не понял зачем её вообще ввели в язык такого уровня (в котором есть доступ к голым указателям и т.п.)...
Указатели это специальный случай, например для хитрого маршалинга.
Здравствуйте, Ikemefula, Вы писали:
I>Ничего не путаю, ты показал код который использует очередь для синхронизации.
Я показал много чего там, уточняй ссылками.
В одном случае я показал как в дотнете использовать два разных механизма асинхронности, на одном из которых гонки есть, а на другом — нет, хотя в обоих случаях вызывается один и тот же асинхронный код.
Еще я показал упрощенную реализацию мануальной кооперативной многозадачности, чтобы продемонстрировать, как легко и непринужденно в случае кооперативной многозадачности можно избежать гонок. Всё что я увидел, это что ты не понимаешь определения "кооперативной многозадачности". Поэтому дальнейшие споры с тобой были бесполезны. Мне нечего добавить к уже сказанному там. Возражений по-существу так и не последовало.
I>Про кооперативную многозадачность — ты снова настаиваешь на той же ошибке. Скажем, все буквари по многозадачности утверждают, что гонки это особенность любой многозадачности
Ну значит ты так и не понял, даже спустя годы, различия в моделях организации многозадачности. И сам же в этом опять расписался. Я помню твою жесть про "прерывания". Ы-Ы-Ы, как грится...
Никакие мьютексы/критические_секции в случае кооперативной многозадачности не нужны, бо в коде и без них легко можно выделить/организовать защищенные от гонок области без дополнительных ср-в, бо передача управления в другой поток/продолжения всегда ЯВНЫЕ. В твоём асинхронном коде на дотнете ты всегда явно пинаешь механизм диспетчеризации асинхронных зачад. Кароч, оба асинхронных диспетчера в дотнете являются ПАССИВНЫМИ. Просто один из них однопоточный (тот, который на GUI-loop и на оповещениях Completion Routines, на которые умеет просыпаться WaitMessageEx и SleepEx), а второй — на пуле потоков. Так вот, во втором случае происходят гонки ни в коем случае не из-за диспетчера (ведь он по-прежнему ППАССИВНЫЙ), а из-за АКТИВНОГО диспетчера низлежащей ОС. Отсюда, кстате, напрашивается любопытное наблюдение, что если некоторые задачи в этом пуле потоков попадают на обслуживание к одному и тому же потоку ОС, то м/у собой у этих задач тоже НЕ МОЖЕТ БЫТЬ ГОНОК. Пока ты эти вещи не вкуришь, даже не пытайся спорить на эти темы.
V>>Ты не в состоянии отличить обобщенное решение от частного. I>Ты всего лишь нашел способ увильнуть от ответа, вместо обсуждения контейнеров перескочил на другие вопросы
Если ты не в состоянии дать обобщенное решение для собственной задачи, то разговаривать сразу не о чем.
Здравствуйте, alex_public, Вы писали:
_>Т.е. ты предполагаешь, что при работе с IDE компилятор Swift'a работает в особом режиме, а из консоли его примеры компилировались бы?
До MSVC от 2005-й студии я мог накатать пример на шаблонах, которые валили компилятор.
Просто исправляешь кусок кода и компилируешь дальше. В любом случае эти конструкции не поддерживались тем компилятором. При том, что свой компилятор С++ они разрабатывали аж с начала 90-х.
V>>Более того, при полноценной поддержке зависимых типов в этой задаче исчезает надобность рекурсивного определения типов, за "глубину" будет отвечать целочисленное значение, определяющее точный тип. Так шта, XCode падать не будет. )) _>Да, да, у меня именно так и вышло. )
Только вместо динамического vector<int> data в случае зависимых типов будет точный int data[N].
Правильное замечание здесь: http://rsdn.ru/forum/philosophy/5525758.1
