LINUX.ORG.RU

Python 3.14

 

Python 3.14

1

4

Вышел Python 3.14.

Из новшеств:

  • официальная поддержка свободной многопоточности (free-threading, PEP 779);
  • новый модуль compression.zstd для сжатия согласно Zstandard (PEP 784);
  • выражения except и except* теперь могут записываться без скобок (PEP 758);
  • многое другое.

Обзор на YouTube о производительности свежих версий Python.

Обзор изменений в диагностике ошибок на Хабре.

>>> Подробности на pythoninsider.blogspot.com

★☆

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 7)
Ответ на: комментарий от yvv1

В питоне, переписывание 1% кода на быстром языке, может дать прирост производительности в сотни, а то и тысячи раз.

Ага, и статическая типизация тоже заодно волшебным образом появляется по всему проекту. Впрочем, с кем я спорю…

dimgel ★★★★★
()
Ответ на: комментарий от yvv1

высокоуровневый язык не обязательно тормозной, как питон.

Да, я понимаю в 2000 году выбирать не из чего было, но сейчас то зачем тянуть это говно. Так и будем теперь до 3000 года с этим пистоном жить что ли?

bread
()
Ответ на: комментарий от Undeadguy

Как минимум для своего времени Питон был крайне читабелен на фоне конкурентов (вспоминаем PHP) и был удобен как ЯП для прототипирования, дескать сейчас проверю идею на питоне, а потом реализовать «по-человечески» на условном C++

Эм, это питон-то читабельнее пхп? У пхп и си синтаксис почти одинаковый, поэтому тому кто пишет на си - пхп всегда будет понятней.

firkax ★★★★★
()
Ответ на: комментарий от mx__

А написать: Вы тупой - это уже переход на личность.

Однако тебе это никто впрямую не писал.

firkax ★★★★★
()
Ответ на: комментарий от cobold

Руби разве не медленнее?

Уже не важно. Но исторически да, руби медленнее всегда был, особенно во времена первых версий. Хотя тогда и требований к бэкенду не было строгих, в общем было пофиг на скорость. Руби и питон из 2000-х самим себе современным тоже драматически сливают, сейчас бы просто смешно было таких черепашек тащить в продакшн. Руби до версии 1.9 это просто песня, сколько там было разных проблем. Второй питон тоже то ещё поделие.

bread
()
Последнее исправление: bread (всего исправлений: 1)

Ничего нового по сути не появилось. Да и чисто гипотетических ситуаций в которых отсутствие GIL даст существенный прирост в скорости мало если тем более у тебя уже assинхронный код написан. Всё так обставлено будто произошло событие века, а по факту пердёж в лужу. Питон концептуально исчерпал себя и ушёл в рефлексию. Он умирает как ПХП и умирать будет долго

rtxtxtrx ★★★
()
Ответ на: комментарий от cobold

Он очень медленный. Это пережиток бума стартапов. Пёрл-доткомов. А питон добьют вайбкодеры и прочие нейропетухи

rtxtxtrx ★★★
()
~
❯ vim ./test_python.py
Found existing alias for "vim". You should use: "vi"

~ 59s
❯ ./test_python.py

CPUs detected: 12, using workers=16
Parameters: CPU_TASKS=40, CPU_WORK=50000, IO_TASKS=200, IO_SLEEP=0.0200

CPU sequential                : 0.234 s
CPU ThreadPoolExecutor        : 0.050 s
CPU ProcessPoolExecutor       : 0.160 s
IO sequential                 : 4.017 s
IO ThreadPoolExecutor         : 0.264 s
IO ProcessPoolExecutor        : 0.340 s

Summary (lower is better):
 CPU thread speedup over seq: 4.66
 CPU process speedup over seq: 1.47
 IO thread speedup over seq:  15.21
 IO process speedup over seq: 11.82

~
❯ python --version
Python 3.14.0

~
❯ asdf set python system

~
❯ python --version
Python 3.13.7

~
❯ ./test_python.py

CPUs detected: 12, using workers=16
Parameters: CPU_TASKS=40, CPU_WORK=50000, IO_TASKS=200, IO_SLEEP=0.0200

CPU sequential                : 0.186 s
CPU ThreadPoolExecutor        : 0.198 s
CPU ProcessPoolExecutor       : 0.046 s
IO sequential                 : 4.017 s
IO ThreadPoolExecutor         : 0.263 s
IO ProcessPoolExecutor        : 0.278 s

Summary (lower is better):
 CPU thread speedup over seq: 0.94
 CPU process speedup over seq: 4.06
 IO thread speedup over seq:  15.25
 IO process speedup over seq: 14.44

~
❯ python -c 'import sys; print(sys._is_gil_enabled())'
True

~
❯ asdf set python latest

~
❯ python -c 'import sys; print(sys._is_gil_enabled())'
False

Пуньк-среньк… Какие ваши оправдания, фонаты питона? Я хочу их выслушать, а то я последнее время пишу на пхп… так как работу найти из-за засилия тупорылых херок с нейродриснявыми ats уже невозможно

test_python.py

#!/usr/bin/env python3
"""
bench_nogil_test.py

Benchmarks:
 - CPU-bound: compute many Fibonacci numbers (iterative) or count primes (sieve-lite)
 - IO-bound (simulated): time.sleep to simulate blocking I/O
Compares: single-thread, ThreadPoolExecutor, ProcessPoolExecutor.

Usage:
  python3 bench_nogil_test.py    # usual CPython
  python-nogil bench_nogil_test.py  # nogil build (name may vary)
"""

import time
import math
from concurrent.futures import ThreadPoolExecutor, ProcessPoolExecutor, as_completed
import argparse
import multiprocessing

# --- Parameters you can tweak ---
CPU_TASKS = 40  # number of tasks to submit for CPU-bound test
CPU_WORK = (
    50000  # parameter controlling per-task CPU work (tune to take ~0.5-2s per task)
)
IO_TASKS = 200  # number of tasks for IO-bound test
IO_SLEEP = 0.02  # seconds each IO task sleeps (simulated blocking I/O)
MAX_WORKERS = None  # if None, will use min(32, os.cpu_count()+4)


# --- Helper functions (CPU-bound examples) ---
def cpu_work_fibonacci(n):
    # iterative fibonacci-ish expensive loop (not using recursion to avoid stack)
    a, b = 0, 1
    for _ in range(n):
        a, b = b, (a + b) % 10**9  # keep numbers bounded
    return a


def cpu_task(idx, work=CPU_WORK):
    # do somewhat heavy math (mix of loops + sqrt) to consume CPU
    s = 0.0
    # do some mixed load to stress interpreter and math
    for i in range(1, work):
        s += math.sqrt(i) * ((i & 1) * 2 - 1)
    # do a small Fibonacci pass to add Python-level ops
    fib = cpu_work_fibonacci(200)
    return (idx, s + fib)


def io_task(idx, sleep_time=IO_SLEEP):
    # simulates blocking I/O
    time.sleep(sleep_time)
    return idx


# --- Runner utilities ---
def run_executor(fn, tasks, executor_ctor, workers):
    start = time.perf_counter()
    results = []
    with executor_ctor(max_workers=workers) as ex:
        futures = [
            ex.submit(fn, *t) if isinstance(t, tuple) else ex.submit(fn, t)
            for t in tasks
        ]
        for f in as_completed(futures):
            results.append(f.result())
    elapsed = time.perf_counter() - start
    return elapsed, results


def run_sequential(fn, tasks):
    start = time.perf_counter()
    results = [fn(*t) if isinstance(t, tuple) else fn(t) for t in tasks]
    elapsed = time.perf_counter() - start
    return elapsed, results


def summarize(name, elapsed):
    print(f"{name:30s}: {elapsed:.3f} s")


def benchmark_all(
    cpu_tasks=CPU_TASKS,
    cpu_work=CPU_WORK,
    io_tasks=IO_TASKS,
    io_sleep=IO_SLEEP,
    workers=None,
):
    if workers is None:
        workers = min(32, (multiprocessing.cpu_count() or 1) + 4)
    print(f"\nCPUs detected: {multiprocessing.cpu_count()}, using workers={workers}")
    print(
        "Parameters: CPU_TASKS=%d, CPU_WORK=%d, IO_TASKS=%d, IO_SLEEP=%.4f\n"
        % (cpu_tasks, cpu_work, io_tasks, io_sleep)
    )

    cpu_tasks_list = [(i, cpu_work) for i in range(cpu_tasks)]
    io_tasks_list = [(i, io_sleep) for i in range(io_tasks)]

    # CPU-bound: sequential
    t_seq_cpu, _ = run_sequential(cpu_task, cpu_tasks_list)
    summarize("CPU sequential", t_seq_cpu)

    # CPU-bound: threads
    t_threads_cpu, _ = run_executor(
        cpu_task, cpu_tasks_list, ThreadPoolExecutor, workers
    )
    summarize("CPU ThreadPoolExecutor", t_threads_cpu)

    # CPU-bound: processes
    t_proc_cpu, _ = run_executor(cpu_task, cpu_tasks_list, ProcessPoolExecutor, workers)
    summarize("CPU ProcessPoolExecutor", t_proc_cpu)

    # IO-bound: sequential
    t_seq_io, _ = run_sequential(io_task, io_tasks_list)
    summarize("IO sequential", t_seq_io)

    # IO-bound: threads
    t_threads_io, _ = run_executor(io_task, io_tasks_list, ThreadPoolExecutor, workers)
    summarize("IO ThreadPoolExecutor", t_threads_io)

    # IO-bound: processes
    t_proc_io, _ = run_executor(io_task, io_tasks_list, ProcessPoolExecutor, workers)
    summarize("IO ProcessPoolExecutor", t_proc_io)

    print("\nSummary (lower is better):")
    print(f" CPU thread speedup over seq: {t_seq_cpu / t_threads_cpu:.2f}")
    print(f" CPU process speedup over seq: {t_seq_cpu / t_proc_cpu:.2f}")
    print(f" IO thread speedup over seq:  {t_seq_io / t_threads_io:.2f}")
    print(f" IO process speedup over seq: {t_seq_io / t_proc_io:.2f}")


if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Simple nogil performance microbench")
    parser.add_argument("--cpu-tasks", type=int, default=CPU_TASKS)
    parser.add_argument("--cpu-work", type=int, default=CPU_WORK)
    parser.add_argument("--io-tasks", type=int, default=IO_TASKS)
    parser.add_argument("--io-sleep", type=float, default=IO_SLEEP)
    parser.add_argument("--workers", type=int, default=None)
    args = parser.parse_args()
    # Update globals (so functions capture the same parameters)
    CPU_TASKS = args.cpu_tasks
    CPU_WORK = args.cpu_work
    IO_TASKS = args.io_tasks
    IO_SLEEP = args.io_sleep
    benchmark_all(
        cpu_tasks=CPU_TASKS,
        cpu_work=CPU_WORK,
        io_tasks=IO_TASKS,
        io_sleep=IO_SLEEP,
        workers=args.workers,
    )

rtxtxtrx ★★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от dimgel

Статическая типизация переоценена.

Она не отменяет тесты, все равно их писать, и они куда больше регрессий отлавливают.

Года три назад еще можно было хвастаться прекрасным intellisense на типах, но сегодня есть нейрокомплит, который тебе дополнит не только имя функции, но и вставит все нужные аргументы, если надо добавит уместную обработку ошибки или продолжит второй функцией, и вообще, бывает, допишет до конца текущий блок. intellisense такого не может даже в теории.

Что там осталось из бонусов? Оптимизация? Или редактор подсветит где забыл переименовать метод?

Это вообще не стоит затрат на дополнительную возню с типами по всему коду.

dredd_test
()
Ответ на: комментарий от dimgel

Ага, и статическая типизация тоже заодно волшебным образом появляется по всему проекту.

Для высокой производительности статическая типизация не обязательна. Если динамический код типостабилен, то JIT компилятор может оптимизировать его так же хорошо, как и статический код. Пример - julia. Но для питона невозможно сделать нормальный JIT компилятор, т.к. он в принципе не типостабилен.

yvv1
()
Ответ на: комментарий от dimgel

Другой вопрос зачем спорить с artix-земельцем, которому яйц… «отсутствие» типизации виновато во всем, который не читает гайды, мануалы и не в состоянии настроить линтер и lsp… Попроси на работе какого-нибдь смузихлеба помочь, если корону сможешь с головы снять, которая мешает уже объективно воспринимать реальность

rtxtxtrx ★★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от dimgel

Тем временем у нас стажёры и джуны делают внутренние финансовые отчёты, SQL измеряется сотнями строк в каждом, и отправляют это в ревью чужих сервисов, где докапываются до каждой строчки, каждого недостающего юнит-теста, каждой ошибки в процессе доставки (не дай бог затормозишь очередь). Ни о каких SQL-инъекциях речи даже быть не может, проблемы скорее возникают из-за неэффективных запросов, которые обусловлены дедлайнами, а не нежеланием делать правильно. И вырасти из такого джуна непросто: нужно не просто всё это уметь делать, а делать стабильно много. И при этом есть куда развиваться, более компетентное отношение к работе возможно.

kaldeon
()
Ответ на: комментарий от kaldeon

Тем временем у нас стажёры и джуны делают внутренние финансовые отчёты, SQL измеряется сотнями строк в каждом, и отправляют это в ревью

Синьор-смузихлеб вместо того чтобы код писать, сидит проверяет чужой, докапываясь до эффективности запросов… Таких нужно гнать в шею

Ни о каких SQL-инъекциях речи даже быть не может

SQL-инъекция в запросе из соснолечки… Понятно.

И вырасти из такого джуна непросто

Лычки и лампасы уже ничего не значат. Начальство идиоты раз позволили рулить процессами погромистов, тем более 23 yo «синьоров», не знающих про битовые флаги

rtxtxtrx ★★★
()
Ответ на: комментарий от seiken

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

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от rtxtxtrx

Синьоры тоже пишут код, но на этом их польза не заканчивается. Только они умеют общаться с заказчиками, причём довольно эффективно — вещь, которая у джунов развивается очень медленно. Только они хорошо владеют огромнейшим контекстом.

Я сам держу лычку джуна, ибо ленюсь работать эффективно, за что получал претензии неоднократно и, кажется, дело идёт к уходу. Но разница даже между обычным программистом и старшим всё же заметна — я бы пока что не смог выполнять роль синьора.

докапываясь до эффективности запросов

Разве плохо? Сервис огромный (несколько сотен отчётов) и масштабировать его дорого (таблицы с миллионами строк), а один тяжёлый запрос может прилично съесть ресурсов.

И речь идёт не о микрооптимизациях, а об ощутимых тормозах. Нередко они вызваны некомпетентностью, но это некомпетентность совсем другого уровня: написать хороший запрос очень сложно (особенно если в нём несколько сотен колонок), не делать SQL-инъекцию — очень просто.

SQL-инъекция в запросе из соснолечки… Понятно.

SQL-инъекция может прийти из GraphQL, интеграцию с которым делает всё тот же разраб. Эти отчёты лежат во внутренней админке.

Конечно, это не публичный ресурс, но даже в этом контексте SQL-инъекции просто не возникают. Prepared statements — давно решённая проблема.

не знающих про битовые флаги

Причём тут и с чего бы они это не знали? Каждый программист фильтруется парочкой задач уровня leetcode.

Да и битовые флаги не то чтобы пригодились где-нибудь. Сподручнее понимание работы LSM-дерева на базовом уровне.

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 8)
Ответ на: комментарий от nuxster

Как говорится за всё хорошее против всего плохого

doomer
()
Ответ на: комментарий от kaldeon

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

rtxtxtrx ★★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 3)
Ответ на: комментарий от rtxtxtrx

Заказчик — внутреннее лицо. В идеале общение должно идти через бизнес-аналитика и так оно нередко происходит для негорящих задач, но на практике слепо следовать идеалу не получается. Бывает такое, что бизнес-аналитики приходят позже.

Во избежание недопониманий: речь идёт про Ozon Банк.

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 2)
Ответ на: комментарий от kaldeon

Вообще какой-то бред. Бизнес-аналитики менеджеры проектов это просто дармоеды и лентяи. Не нужны они вообще. Я пробовал уже руководить когда все неизвестно кто чем занят но в итоге тот же самый результат что с контролем когда все отчитываются перед условным менеджером проекта. Всё как в муравейнике. Просто в муравейнике большинство муравьёв работает, их никто не заставляет ничего делать насильно, есть часть лентяев, которые ничего не делают тупо бродят взад-вперёд или где-то в норах прячутся, есть такие, но большинство-то всё равно работает… и с людьми точно так же всё работает. Дураки любят работу . Я не отрицаю что все эти менеджеры и аналитики они какую-то работу выполняют. Но от неё пользы вообще ноль. Все эти должности по моему мнению придуманы чтобы набрать в крупные компании на западе женщин и негров, выполнить квоты по разнообразию в рамках HR-культа.

rtxtxtrx ★★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 3)
Ответ на: комментарий от kaldeon

Хорошо. Ozon - это по-прежнему дно. Где на собеседование заставляют решать шарады.

rtxtxtrx ★★★
()
Ответ на: комментарий от MoldAndLimeHoney

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

Нет, я действительно не понял, о чём речь. Предполагал, что речь об инструментах типа black, и гадал, о каких же проблемах в них идёт речь.

Синтаксис ЯП/конфига должен позволять полностью восстановить логику, даже если форматирование полностью сбито и вся программа теперь представляет одну строку.

Я разрабатываю уже больше 25 лет. Ни разу не сталкивался с ситуацией, когда «форматирование полностью сбито и вся программа представляет одну строку». В результате чего это может произойти? Космические лучи фигурно выпиливают символы перевода строки в строго определённых ячейках памяти?

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

Chiffchaff
()
Ответ на: комментарий от wandrien

В Питоне вообще не очевидно, когда можно что-то переносить на новую строку, а когда нельзя. Язык для входящих в него программистов интуитивно ощущается как line-oriented.

Это очень интересный аргумент с точки зрения дизайна языка. Мелочь, которая меняет картину на большем масштабе.

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 1)
Ответ на: комментарий от liksys

Это называется декларативный стиль программирования. А ты топишь за императивный. Декларативный по общему правилу более приоритетный. Большинство скорее тебя будет говнокодером считать, а не его.

rtxtxtrx ★★★
()
Ответ на: комментарий от liksys

Так декларативный стиль и нужен чтобы избежать ошибки. Многократно копипастя код ты лишь повышаешь шансы допустить ошибку нежели вызывая какой-то метод функцию и тому подобное. И легче эту ошибку исправить в одном месте. Это вообще про декларативный стиль, а не про тот конкретный пример, где он этих мапов налепил

rtxtxtrx ★★★
()
Последнее исправление: rtxtxtrx (всего исправлений: 1)
Ответ на: комментарий от MichIs

Мне как человеку, который разобрался и использует язык редактирования sam (аналог awk/sed), не представляет труда выразить и прочесть решение этой задачи на sam. Это просто дело привычки.

x/[0-9]+/ {
  +#0-/./ g/[02468]/ +#0-/[0-9]+/ |echo `{cat} '^' 2 |bc
  +#0-/./ g/[13579]/ +#0-/[0-9]+/ |echo `{cat} '^' 3 |bc
}

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

kaldeon
()
Последнее исправление: kaldeon (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

фломастеры разные важны; фломастеры разные нужны

трёхбуквие nih тож на три буквы анализ

автор(ки) Xonsh ты или Я?!

qulinxao3 ★☆
() автор топика
Ответ на: комментарий от dimgel

действительно вам не кажется и вы уверены что машкод лучший инструмент! вы последователь фон Ноймана?

qulinxao3 ★☆
() автор топика
Ответ на: комментарий от MoldAndLimeHoney

выкинь ; (все) из обычного блочного(в голштанге и жабеПодСкриптами частично справились но не полностью) языка и пусть редактор автораставит - всегда будет востановлена семантика ?!

qulinxao3 ★☆
() автор топика
Ответ на: комментарий от dimgel

проблема твоих(субьективных) прогибов что ты в найме

зачем тебе начальники - достаточно заказчиков

а сразу пилишь под целевой платформу.

зачем мириады таргетов если достаточно jvm|clr|llvm

и наполном серьёзе:
[hr] вы за суперкомпиляцию?
[hr] вы за полиморфный код исполнения?

qulinxao3 ★☆
() автор топика
Ответ на: комментарий от yvv1

Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий

dimgel

ps:

Да и сам я, если честно, нихрена не понимаю эту логику.

qulinxao3 ★☆
() автор топика
Ответ на: комментарий от dimgel

на вашей целевой платформе тегированная памать данных? а кода?

qulinxao3 ★☆
() автор топика
Ответ на: комментарий от bread

Хотя тогда и требований к бэкенду не было строгих, в общем было пофиг на скорость.

отличная фолк хистори

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

qulinxao3 ★☆
() автор топика
Ответ на: комментарий от qulinxao3

torch lua кста

Это было слишком давно и для исходного торча, а не пайторча, который уже более на нём не основано. Сейчас https://github.com/pytorch/pytorch

Python 59.7%
C++ 32.3%
Cuda 2.9%
C 1.4%
Objective-C++ 1.1%
CMake 0.6%
Other 2.0%
anonymous_incognito ★★★★★
()
Ответ на: комментарий от yvv1

На джулии своя нативная ML экосистема есть. Весьма продвинутая.

Да, есть. Не особо ей интересовался, но действителбно есть.

anonymous_incognito ★★★★★
()
Ответ на: комментарий от wandrien

«дело привычки»

очевидно что односторонии языки

lisp как префиксный

forth как постфиксный <- тут для var-arg достаточно открывающего терма команда которая var-arg автоматом и есть закрывающая

али apl где специально отказались от общепринятой нотации приоритетов операций - и почти сразу расширили набор символов до домотканых

и как и любая нотация есть граница после которой окружающие могут тригернутся что её абузять

qulinxao3 ★☆
() автор топика
Ответ на: комментарий от Chiffchaff

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

SpaceRanger ★★★
()
Ответ на: комментарий от yvv1

И прекращаем фантазировать.

https://ftp.math.utah.edu/u/ma/hohn/linux/python/numericalpython.pdf

Тиобе это опрос «школоты» т.е кто «ищет лучшее из предложенного в супермаркете»

при этом многие «товары» остаются (и даже уходят из супермаркетов в ниши некоторые товары) в меньшем

сила питона была до навязывания публике которая сообщи о важности вышевания крючком сразу пояснит друг другу в скилах грейдах и прочей софтухе в навыке крючкоплетения

qulinxao3 ★☆
() автор топика
Ответ на: комментарий от cobold

Руби разве не медленнее?

С выходом 3ки они сильно подняли скорость, автор еще хвастался что вроде скорость будет 3х3 но что у него не вышло.

Помню когда давно собирал 3ку, то там при компиляции можно было указать какой JIT компилятор юзать, вроде самый нормальный был (не побоюсь этого слова) на rust (yjit), приходилось его на время сборки включать :(

P.S. https://programming-language-benchmarks.vercel.app/python-vs-ruby

Что я не пойму, ruby/yjit 3.4.5 во всех тестах сильно обходит cpython 3.13.5.

mx__ ★★★★★
()
Последнее исправление: mx__ (всего исправлений: 5)
Ответ на: комментарий от SpaceRanger

не знал, что он выстрелит

Он мог уже тогда чувствовать, что выстрелит. Если есть объективные причины выстреливания, то они же существовали уже тогда. А если их и сейчас нет, то это не выстрел, а так, флуктуация.

Saakx
()
Ответ на: комментарий от dredd_test

Что там осталось из бонусов? Оптимизация?

Ну хотя бы. А так-то конечно нафиг эти типы продумывать и описывать, накидал быстренько по всему коду хештаблиц и пошел бухать. Все равно на следующей итерации всё это творчество перепишут к хренам такие же чебурашки.

bread
()
Ответ на: комментарий от Saakx

Он мог уже тогда чувствовать, что выстрелит.

На самом деле Питон заменил в дистрах Линукса perl. Сейчас уже многие дистры можно поставить вообще без perl, а вот без python многие дистры вообще нельзя установить.

И получается он уже сразу есть в системе, нужно что то, хлоп - скриптик набросал и пашет.

mx__ ★★★★★
()
Ответ на: комментарий от qulinxao3

всегда есть хотелки превышающие текущие возможности

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

bread
()
Ответ на: комментарий от SpaceRanger

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

В тот момент, для хобби, и на первых работах, писал на C и C++.

Я тогда увлёкся Linux, и т.к. Интернета либо не было, либо он был очень медленным, читал всё, до чего мог дотянуться, включая код дистрибутивных скриптов: установщики, служебные утилиты.

И меня сильно заинтересовало, что это за .py файлы такие, о которых никто не слышал и не писал в книгах, но код в них выглядел абсолютно понятным без знания синтаксиса языка. Начал ковыряться, прочитал от корки до корки всю доку, что входила в состав языка (python tutorial, дока по stdlib), втянулся. Начал потихоньку пытаться продвигать в компаниях, где работал. Потом нашёл компанию, где CTO был таким же энтузиастом Python. Шанс был один на миллион - в России о Python тогда никто даже не слышал, но когда чем-то увлечён, всегда такое происходит.

Так всё и закрутилось.

Chiffchaff
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.