1.2, Аноним (-), 11:24, 04/11/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
>представлена... реализация... не будет GIL.
По крайне мере хорошо, что эти релизации идут независимо и... не блокируют друг друга)
| |
1.5, Аноним (-), 12:05, 04/11/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +17 +/– |
>высокой производительности, близкой к производительности традиционных системных языков, таких как C++.
По горло уже сыт этим враньём, "близкого" там и в помине нет и быть не может.
| |
|
2.6, A.Stahl (ok), 12:15, 04/11/2015 [^] [^^] [^^^] [ответить]
| +10 +/– |
Если вы произнесёте достаточно большую ложь и будете её повторять, то люди в итоге в неё поверят.
| |
|
|
4.17, Красные Глаза (ok), 15:11, 04/11/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если вы произнесёте достаточно большую ложь и будете её повторять, то люди в итоге в неё поверят.
| |
|
3.19, Аноним (-), 15:56, 04/11/2015 [^] [^^] [^^^] [ответить]
| +3 +/– |
Если вы произнесёте достаточно большую правду и будете её повторять, то люди в итоге в неё поверят.
| |
|
2.16, Нимано (?), 14:59, 04/11/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
> По горло уже сыт этим враньём, "близкого" там и в помине нет
> и быть не может.
Читайте внимательнее!
> нацелена на достижение высокой производительности, близкой к производительности традиционных системных языков, таких как C++
> нацелена на достижение
Т.е. похвальное стремление к светлому будущему!
Ну а то, что "не шмогла я, не шмогла!", это уже издержки нашей реальности ...
| |
|
|
4.30, Нимано (?), 18:09, 04/11/2015 [^] [^^] [^^^] [ответить]
| +4 +/– |
> питон даже обмазанный JITами не будет иметь такой
> производительности.
Да легко! Делов-то:
с помощью либастрала забабахать нормальное предсказание типов и освобождение памяти (т.е. убрать подсчет ссылок/ГЦ) и запилить 100% unboxing при компиляции.
Ну или тихой сапой протолкнуть некоторые вещи в плюсовой стандарт.
А еще: вполне может быть, что прилетят инопланетяне и подарят схему спец-ЦПУ, который будет работать исключительно на питоне.
| |
4.51, freehck (ok), 12:50, 05/11/2015 [^] [^^] [^^^] [ответить]
| +/– |
Нет, ну почему же. Очень даже может. Это ж не виртуальная машина, как скажем JVM, где такой же производительности быть точно не может. Если они используют JIT именно что для компиляции в нативный код -- то высокая производительность в принципе сможет быть достигнута.
Вот если бы Вы то же самое сказали по поводу JVM, это было бы более справедливо. Впрочем, недавно мне матёрые явисты объяснили, что проблема тут в выдёргивании слов из контекста: Java действительно обеспечивает производительность компилируемых языков *за счёт хорошо спроектированного параллелизма выполнения*. То есть когда явисты говорят о том, что обгоняют компилируемые языки, надо отдавать себе отчёт, что сравниваются многопоточные java-приложения с не очень хорошо распараллеленными C-аналогами. И кстати недавняя новость о переписанной на сях Apache Cassandra явное тому подтверждение.
| |
|
5.52, userd (ok), 15:18, 05/11/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Опыт, конечно, говорит - "никогда не говори никогда",
но по поводу «Очень даже может» есть серьёзные сомнения.
у Python (в реализации CPython) тоже виртуальная машина.
Для любой функции на python с помощью dis.dis можно получить код:
>>> import dis
>>> def ps(a,b): print a+b
>>> dis.dis(ps)
3 0 LOAD_FAST 0 (a)
3 LOAD_FAST 1 (b)
6 BINARY_ADD
7 PRINT_ITEM
8 PRINT_NEWLINE
9 LOAD_CONST 0 (None)
12 RETURN_VALUE
Это стековая машина, манипулирующая данными в довольно абстрактной манере.
Всё - числа, строки, списки, экземпляры объектов и т.п. - всё представляется в виде PyObject* ( https://docs.python.org/2/c-api/intro.html, https://docs.python.org/2/c-api/structures.html )
и код виртуальной машины "не знает" что он складывает и печатает - числа, строки или объекты. Конечно, в какой-то момент времени интерпретатор выяснит что оба слагаемые - числа, вычислит и вернёт сумму, но по логике работы интерпретатора это должно произойти как можно позже.
Я не очень внимателен к достижениям авторов jit и компиляторов (это я про Nuitka), но как мне показалось первые достижения связаны с разворачиванием цикла интерпретатора + генерацией кода в эпилоге функции + улучшение реализации циклов.
Предполагаемая высокая производительность требует разумного отказа от PyObject*,
но это довольно сложно.
| |
5.54, all_glory_to_the_hypnotoad (ok), 01:07, 06/11/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Если они используют JIT именно что для компиляции в нативный код -- то высокая производительность в принципе сможет быть достигнута.
Это сильно зависит от ЯП. Питон задизайнен внутри так, то такое в принципе невозможно. Да и у любых аналогичных по динамичности ЯП точно такие же проблемы (ruby, js и прочий крап). Убогий пых имеет значительно больший потенциал для оптимизаций чем всё это вместе взятое.
| |
|
6.55, Аноним (-), 15:04, 06/11/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
Ставка на оптимизацию в наш век сверхбыстрых камней и грошовой памяти явный моветон. Никому это сейчас не нужно....
| |
|
|
|
|
|
3.45, Нимано (?), 22:49, 04/11/2015 [^] [^^] [^^^] [ответить]
| +3 +/– |
> погугли polimorphic inline cache
погуглите "static dispatch" и "dynamic dispatch" (заодно и и подумайте на досуге, почему первое всегда будет быстрее второго. Особенно там, где "динамизм" используется вовсю (как например в батарейках питона).
Я прокапитаню:
Даже минимальная проверка типа с вызовом метода всегда будет медленнее вызова без проверки (информацию о типе нужно где-то хранить и извлекать. Все это может быть проделанно хоть и очень быстро, но отнюдь не мгновенно).
А если еще учитывать такие штуки как векторизация/SIMD, "inlining классический", "branch prediction" железки и то, что сам CPU-кэш отнюдь не резиновый ...
Так что, особенно при работе с большими массивами примитивных типов, если нет гарантий того, что тип всегда одинаков (а их, как ни странно, обычно таки нет – динамическая типизация-с) все будет может и не совсем (на порядок) уныло, но однозначно и заметно медленне.
| |
|
2.41, Аноним (-), 20:59, 04/11/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
почему у JavaScript близкая к C++ производительность получилась, а у python невозможна?
| |
|
1.9, anonymous (??), 12:28, 04/11/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> В текущем виде Pyston на 25% быстрее CPython и на 25% PyPy 4.0
С pypy.org
> The geometric average of all benchmarks is 7.0 times faster than CPython
Кто-то нагло звиздит.
| |
1.40, Аноним (-), 20:57, 04/11/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>В текущем виде Pyston на 25% быстрее CPython
jit компилятор быстрее интерпретатора на четверть. Это круто!
| |
1.42, Я (??), 21:10, 04/11/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Почему они пилят реализацию второй ветки, когда все кроме легаси уже несколько лет как перешли на третью?
| |
|
2.49, xPhoenix (ok), 11:30, 05/11/2015 [^] [^^] [^^^] [ответить]
| +/– |
К сожалению, не все. Есть одна фирма-лидер [сарказм], которая идёт к успеху и начинает новый проекты на Python с использованием Python 2.7 и Django 1.4.
| |
|
|