Де потрапляє Objective-C у континуум мовної роботи?

20

Здається, існує багато дискусій про різні переваги швидкості для C або C ++ порівняно з, наприклад, Java або Python, але я рідко бачу, як згадується Objective-C. Приблизно, де вона потрапляє з точки зору мовної роботи?

programming-languages objective-c

— Фоміт
джерело

23

1986 - Бред Кокс і Том Лав створюють Objective-C, оголошуючи, що "ця мова має всю безпеку пам'яті C у поєднанні з усією палаючою швидкістю Smalltalk". Сучасні історики підозрюють, що двоє були дислексичними. ( джерело )

— Мейсон Уілер

4

Він потрапляє в діапазон, коли продуктивність не має великого значення. Це єдина підтримувана мова для взаємодії з какао, тому якщо ви хочете це зробити, більше нічого не працює. Щодо іншого, я вважаю це страшним вибором, незалежно від продуктивності.

— Джеррі Труну

1

"продуктивність" - це не характеристика мови, а мовна реалізація та, що ще важливіше, програм, написаних цією мовою. Ви можете писати дуже швидкі програми в Objective-C, або ви можете дуже повільно писати.

— Калеб

Він не в змозі мати огидний синтаксис, але це не погано працює мова, заснована на його поточних компіляторах, оскільки продуктивність більше базується на компіляторі / vm, ніж на фактичній мові.

— Ріг

28

На відміну від C ++, Objective-C розроблений як чистий надмножина C. Нечисленні компілятори Objective-C, які я використовував, більш відомі як компілятори C, але також обробляють Objective-C.

Отже, можна припустити, що в рівні генерації коду C і Objective-C рівноцінні.

Перша відмінність з'являється в OOP ABI, який також називають "пізнім методом зв'язування". Як і в C ++, Objective-C покладається на створені компілятором таблиці функцій вказівників, які проходять під час виконання.

Однак, на відміну від C ++, метод зв'язування є більш "динамічним", і він сприяє використанню idсуперкласу всюди, роблячи його трохи повільніше, ніж C ++ в теорії. На практиці ця різниця набагато нижче вимірюваної.

Нарешті, найважливішим питанням ефективності є якість використовуваних бібліотек. Оскільки Objective-C користується популярністю лише в системах Apple, розумно вважати, що ви використовуєте його з какао; що є прекрасним набором бібліотек високого рівня. У більшості випадків ви можете залишити важкий підйом на них, тому ваш код або не повинен бути таким швидким, або якщо ви робите важкі хрускіт, то, ймовірно, це буде в основному статична база коду, приблизно схожа на звичайну C .

TL; DR: саме там є мови C та C ++, де це найбільше важливо. Якщо ви не отримуєте хорошої продуктивності, перевірте свої алгоритми; так само, як і в будь-якій серйозній мові.

— Хав'єр
джерело

4

Насправді сучасний aim-c - це настільки ж суперсклад, як і сучасний C ++. У C вам дозволяється робити арифметику на довільних покажчиках, ви не можете в ObjC. Також різниця в продуктивності завдяки пошуку методу вимірюється: швидкий шлях objc_msgSend приблизно в чотири рази важчий, ніж виклик функції члена (а повільні шляхи не такі швидкі, як швидкі шляхи).

11

Objective-C повільніше, ніж C / C ++. Причиною є час виконання Objective-C, який динамічно розсилає методи пошуку під час виконання так само, як Smalltalk, з якого він перейняв цю модель виконання. Відправлення всіх методів під час виконання називається "істинне повідомлення надсилає" на відміну від виклику функції в C / C ++, де адреса функції визначається під час компіляції (за винятком віртуальних методів C ++). Але я не можу сказати, наскільки повільніший Objective-C. ASAIK використовується лише для розробки додатків через покарання за продуктивність.

— OlliP
джерело

1

Знайшов це порівняння продуктивності з C: rmarcus.info/?p=488 Схоже, що Objective-C все-таки досить близький до C.

— OlliP

Було б добре порівняти Objective C з рештою пакету в грі Benchmark '

— Мисливець на оленів

Я думаю, що порівняння продуктивності потрібно брати з частинкою солі, оскільки код Objective-C є деяким розширеним кодом C, а не повідомленням Objecttive-C. Я не знаю, що таке зниження. Я займався розробкою Smalltalk протягом більше десяти років, і Objective-C базується на Smalltalk багатьма способами. Я думаю, знаю, про що я говорив.

— OlliP

Не потік; Мене насамперед цікавлять сильно чисельні алгоритми, динамічна відправка не має великого значення в них.

— Мисливець на оленів

8

Коротка відповідь: Складається у подібному форматі, як C / C ++ / D / Go / Rust. Він не використовує віртуальне середовище на зразок Java / .Net. І це не трактується як Python / Ruby / Lua / JavaScript. Так це на більш швидкому кінці спектру.

— Jacks_Gulch
джерело

7

Основні відмінності швидкості між Obj-C і C / C ++, як каже Олівер нижче, обумовлені динамічним відправленням методу.

Ця стаття оглядає цей наклад в Obj-C http://it.toolbox.com/blogs/macsploitation/bypassing-objectivecs-message-passing-mechanism-for-speed-24946

Він також забезпечує дуже приємний трюк для оптимізації коду Obj-C, коли ви визначаєте, що відправка методу (тобто objc_msgSend) є обмежуючим фактором - отримайте вказівник на функцію один раз і використовуйте його для виклику функції багато разів. Це не повинно допомагати, оскільки Obj-C виконує цю оптимізацію автоматично .

Зауважте, що справжня вартість відправки динамічного методу обумовлена помилками кешу, оскільки це порушує передбачення гілок процесора. Їх важко профайлювати, і можливо, що цитований вище код не вимірює справжню вартість пропуску кешу.

Ще кілька корисних обговорень можна знайти тут: http://www.cocoabuilder.com/archive/cocoa/106535-instance-variable-access.html#106605

Підсумок: найбільші відмінності між мовами - це ваші алгоритми. Крім цього, існує принципова різниця швидкостей між Obj-C, C і C ++, що обумовлено динамічним або віртуальним методом відправки. Цей другий пункт не здається великим. І наведена вище стаття дає підказку для її оптимізації, якщо ви можете знайти гарячі точки за допомогою профілювання, що може бути складно через помилки кешу процесора.

— MHH
джерело