Как Swift может быть намного быстрее, чем Objective-C в этих сравнениях?

Apple запустила свой новый язык программирования Swift на WWDC14 . В презентации они провели некоторые сравнения производительности между Objective-C и Python. Ниже приведена картина одного из их слайдов, сравнения трех языков, выполняющих сложный вид объекта:

введите описание изображения здесь>> </p>

<p> Был еще более невероятный график сравнения производительности с использованием алгоритма шифрования <a href= RC4 .

Очевидно, это маркетинговый разговор, и они не вдавались в подробности о том, как это было реализовано в каждом. Я оставляю задуматься:

  1. Как новый язык программирования может быть намного быстрее?
  2. Являются ли результатом Objective-C результатом плохого компилятора или есть что-то менее эффективное в Objective-C, чем Swift?
  3. Как вы объясните увеличение производительности на 40%? Я понимаю, что сбор мусора /автоматический контрольный контроль может привести к дополнительным накладным расходам, но это много?
114 голосов | спросил Yellow 3 J0000006Europe/Moscow 2014, 01:55:00

5 ответов


60

Во-первых, (IMO) по сравнению с Python почти бессмысленна. Только сравнение с Objective-C имеет смысл.

  • Как новый язык программирования может быть быстрее?

Objective-C - медленный язык. (Только часть C работает быстро, но это потому, что это C). Это никогда не было очень быстрым. Это было достаточно быстро для их цели (Apple) и быстрее, чем их старые версии. И это было медленно, потому что ...

  • Получает ли Objective-C плохой компилятор или есть что-то менее эффективное в Objective-C, чем Swift?

Objective-C гарантирует, что каждый метод будет динамически отправлен. Никакой статической отправки вообще. Это сделало невозможным дальнейшее оптимизацию программы Objective-C. Ну, может быть, технология JIT может помочь, но AFAIK, Apple действительно ненавидят непредсказуемые характеристики производительности и срок службы объекта. Я не думаю, что они приняли какие-то вещи JIT. У Swift нет такой динамической гарантии отправки, если вы не добавили специальный атрибут для совместимости с Objective-C.

  • Как вы объясните увеличение производительности на 40%? Я понимаю, что сбор мусора /автоматический контрольный контроль может привести к дополнительным накладным расходам, но это много?

GC или RC здесь не имеет значения. Swift также использует RC в первую очередь. Никакой GC нет, и также не будет, если не будет огромного архитектурного скачка по технологии GC. (ИМО, это навсегда). Я считаю, что у Swift намного больше возможностей для статической оптимизации. Особенно алгоритмы шифрования низкого уровня, поскольку они обычно полагаются на огромные числовые вычисления, и это огромная победа для статических языков рассылки.

На самом деле я был удивлен, потому что 40% кажется слишком маленьким. Я ожидал гораздо большего. Во всяком случае, это начальный выпуск, и я думаю, что оптимизация не была главной проблемой. Swift даже не работает! Они сделают это лучше.

Update

Некоторые продолжают подталкивать меня к утверждению, что технология GC превосходит. Хотя материал ниже может быть спорным, и только мое очень предвзятое мнение, но я думаю, что должен сказать, чтобы избежать этого ненужного аргумента.

Я знаю, какие консервативные /трассирующие /генераторные /инкрементные /параллельные /реальные GC и как они отличаются. Я думаю, что большинство читателей уже это знают. Я также согласен с тем, что GC очень хорош в некоторых областях, а также показывает высокую пропускную способность в некоторых случаях.

В любом случае, я подозреваю, что требование пропускной способности GC всегда лучше, чем RC. Большая часть накладных расходов RC исходит от операции подсчета и блокировки, чтобы защитить переменную числа ref-count. И реализация RC обычно обеспечивает способ избежать операций подсчета. В Objective-C есть __unsafe_unretained и в Swift (хотя это все еще несколько неясно для меня) unowned. Если стоимость операции пересчета не приемлема, вы можете попытаться выборочно отключить их, используя механику. Теоретически, мы можем моделировать сценарий почти уникальной собственности, используя ненавязчивые ссылки очень агрессивно, чтобы избежать накладных расходов RC. Также я ожидаю, что компилятор автоматически устранит некоторые очевидные ненужные операции RC.

В отличие от системы RC, AFAIK, частичное исключение ссылочных типов не является вариантом в системе GC.

Я знаю, что есть много выпущенных графических и игр, которые используют систему на основе GC, а также знают, что большинство из них страдает от отсутствия детерминизма. Не только для характеристики производительности, но и для управления жизненным циклом объекта. Единство в основном написано на C ++, но крошечная часть C # вызывает все странные проблемы с производительностью. HTML-гибридные приложения и все еще страдают от непредсказуемых всплесков в любой системе. Используемый широко не означает, что это лучше. Это просто означает, что это легко и доступно людям, у которых не так много вариантов.

Обновление 2

Снова, чтобы избежать ненужного аргумента или обсуждения, я добавляю несколько подробностей.

@Asik предоставил интересное мнение о всплесках GC. Мы можем рассматривать подход value-type-everywhere как способ отказаться от материала GC. Этодовольно привлекательный и даже выполнимый на некоторых системах (например, чисто функциональный подход). Я согласен, что это хорошо в теории. Но на практике у него есть несколько вопросов. Самая большая проблема заключается в частичном применении этого трюка, который не обеспечивает истинных характеристик без спайков.

Потому что проблема с задержкой - это всегда проблема все или ничего . Если у вас есть один всплеск кадра в течение 10 секунд (= 600 кадров), то вся система, очевидно, не работает. Речь идет не о том, как лучше или хуже. Это просто пройти или провалиться. (или менее 0,0001%). Тогда где источник всплеска GC? Это плохое распределение нагрузки GC. И это потому, что GC фундаментально индетерминирован. Если вы сделаете мусор, то он активирует GC, и всплеск произойдет в конечном итоге. Конечно, в идеальном мире, где загрузка GC всегда будет идеальной, этого не произойдет, но я живу в реальном мире, а не в воображаемом идеальном мире.

Затем, если вы хотите избежать всплеска, вам нужно удалить все ref-types из всей системы. Но это сложно, безумно и даже невозможно из-за неустранимой части, такой как базовая система и библиотека .NET. Просто использование системы без GC намного проще .

В отличие от GC, RC фундаментально детерминирован, и вам не нужно использовать эту безумную оптимизацию (только чисто-значение-только), чтобы избежать всплеска. Что вам нужно сделать - это отслеживать и оптимизировать часть, которая вызывает всплеск. В системах RC шип - это проблема локального алгоритма, но в системах GC шипы всегда являются глобальной проблемой системы.

Я думаю, что мой ответ слишком ушел из-за темы, и в основном просто повторение существующих дискуссий. Если вы действительно хотите претендовать на превосходство /неполноценность /альтернативу или что-либо еще из материалов GC /RC, на этом сайте и StackOverflow существует много существующих обсуждений, и вы можете продолжать сражаться там.

ответил Eonil 4 J0000006Europe/Moscow 2014, 14:51:44
71

Будучи в 3,9 раза быстрее, чем python, язык, который последовательно теряет большинство тестов с большой разницей (хорошо, он наравне с Perl, Ruby и PHP, но он теряет все, что статически типизировано), ничто не должно хвастаться.

тест производительности показывает программы на C ++, которые в большинстве случаев более чем на порядок быстрее, чем программы python. Это не намного лучше, если сравнивать с Java, C # (на Mono), OCaml, Haskell и даже Clojure, который не статически типизирован.

Таким образом, реальный вопрос заключается в том, как Objective-C только в 2,8 раза быстрее, чем python. По-видимому, они тщательно выбрали бенчмарк, где сильно замедляется медленная полностью динамичная отправка ObjC. Любой статически типизированный язык должен быть способен сделать лучше. В сложной сортировке объектов существует много вызовов методов для сравнения объектов, и фактическое сравнение было, вероятно, не очень сложным. Поэтому, если Swift использует хотя бы какое-то преимущество информации о типе, он может легко справиться с вызовами метода, и недостаточно других операций, которые ObjC может быть лучше.

Конечно, как демонстрирует тест-тесты , относительная производительность по различным задачам сильно варьируется, поэтому один критерий не является действительно представитель. Если бы у них был бенчмарк, где у него было больше преимуществ, они бы показали нам, что один вместо этого, поэтому по другим задачам это, вероятно, не лучше или не так много.

ответил Jan Hudec 3 J0000006Europe/Moscow 2014, 14:34:29
4

Objective-C динамически отправляет каждый вызов метода.

Гипотеза: В тесте используется статическая типизация, позволяющая компилятору Swift вытащить метод compare из цикла sort. Для этого требуется ограничение узкого типа, которое допускает только объекты Complex в массиве, а не подклассы Complex.

(В Objective-C вы могли бы поднять метод поиска вручную, если хотите, путем вызова поддержки времени выполнения языка для поиска указателя метода. Лучше убедитесь, что все экземпляры массива имеют очень того же класса.)

Гипотеза: Swift оптимизирует обратный отсчет вызовов из цикла.

Гипотеза: Тест Swift использует сложную структуру вместо объекта Objective-C, поэтому сортировка сравнений не требует динамических методов отправки (поскольку она не может быть подклассифицирована) счетная работа (поскольку это тип значения).

(В Objective-C вы можете вернуться к C /C ++ для производительности, если не связаны объекты Objective-C, например, сортируйте массив C структур.)

ответил Jerry101 23 J0000006Europe/Moscow 2014, 00:37:16
3

Честно говоря, если они не выпустят исходный код для тестов, которые они используют, я бы не стал доверять тому, что Apple должна сказать по этому вопросу. Помните, что это компания, которая переключилась с PPC на Intel по соображениям энергопотребления, когда 6 месяцев назад они говорили, что Intel сосала и фактически сгорела кролика Intel в рекламе. Я хотел бы видеть неопровержимое доказательство того, что Swift быстрее, чем ObjC в большем количестве категорий, чем просто сортировка.

Кроме того, вы должны подвергать сомнению любые статистические данные, выпущенные на WWDC, поскольку у них есть запах маркетинга по всему миру.

Все это говорит о том, что я не провел никаких тестов между быстрым и ObjC самостоятельно, но из того, что я знаю, swift имеет собственные расширения LLVM IR, и возможно, что во время компиляции выполняется больше оптимизации, чем в ObjC.

Полное раскрытие: я пишу компилятор Swift с открытым исходным кодом, расположенный по адресу https://ind.ie/phoenix/

Если кто-то хочет помочь убедиться, что Swift не просто доступен на аппаратном обеспечении Apple, сообщите мне, и я был бы рад включить вас.

ответил greg.casamento 5 Jam1000000amMon, 05 Jan 2015 03:10:01 +030015 2015, 03:10:01
0

Я боролся с помощью учебника Swift, и мне кажется, что Swift больше работает на земле (заставляет меня думать о Visual Basic) с меньшим «объектизацией», чем Objective-C. Если бы они учитывали C или C ++, я предполагаю, что последний выиграл бы, так как они еще более компилируются.

В этом случае я предполагаю, что Objective-C является жертвой объектно-ориентированной чистоты (и накладных расходов).

ответил Painted Black 3 J0000006Europe/Moscow 2014, 13:37:27

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132