Сообщение Re[8]: MS забило на дотнет. Питону - да, сишарпу - нет? от 04.09.2021 20:51
Изменено 04.09.2021 20:52 vfedosov
Re[8]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vfedosov, Вы писали:
V>>Ну вот к примеру +- типичная задача: нужно развернуть индекс: есть индекс по одному ключу, надо построить по другому. В пайтоне решается так:
V>>names2data = {"name1": (1, 3, "str1"), "name2": (2, 4, "str2")}
V>>data2names = {data[1]: name for name, data in names2data.items()}
S>Не очень понимаю синтаксис — что делает эта штука?
ну первая строка создает Dictionary<string, (int, int, string)> и заполняет его 2мя элементами. Это индекс — по аналогии с индексами БД — возможность быстро получить данные по имени. Быстро означает за O(ln(n)) или O(1) — полный перебор не канает.
Вторая строка создает новый Dictionary<int, string> — который содержит второй int и key из первого. Это индекс, который позволяет быстро перейти от int к name. Причем после второй строки он уже заполнен и готов к работе. Далее, если в коде тебе нужно получить быстро name для которого второй int = 3, ты пишешь:
name = data2names[3]
V>>я не в курсе, может последние версии шарпа позволяют коротко эту задачу решить — уж лет 6-7 не работаю с шарпом, но пайтон и 10 лет назад это поддерживал. Насколько кратко можно проинициализировать сложную структуру данных и насколько легко с ней работать! Кстати работает мега быстро в отличии от довольно медленного Linq.
V>>Или обработка массивов float — работает почти как на плюсах по скорости. Имеем двумерный numpy массив — картинку (яркости пикселей нормированы к 1.0), надо сделать ярче в 1.5 раза, но значения не должны быть больше 1.0:
V>>array_2d = np.min(array_2d * 1.5, 1.0)
V>>Может слегка с синтаксисом в примерах накосячил (влом проверять) — но суть такая.
V>>Представь чего на шарпе придется нагородить для этого
S>Ну, вот я себе хорошо это представляю.
S>
S>https://github.com/evilguest/linq2d
V>>и сколько это работать будет по времени.
S>Ну, некоторые вещи работают быстрее, чем на плюсах. Может быть, numpy написан получше — можем помериться, если есть желание.
Не может этот код быстро работать, так как там виртуальное вызовы IEnumerable идут — причем несколько вызовов на одну итерацию. Шарп не поддерживает inline для подобных вызовов и работает раз в 10-50 медленнее нативного кода в таких случаях — проверено не раз — я не преувеличиваю. При каждом виртуальном вызове идет копирование всех аргументов, создание точки возврата из функции, обращение к виртуальной таблице — куча ненужного дерьма, которое несопоставимо по объему с основной операцией — умножит на 1.5 и сравнить с единицей. Это если обойдется без аллокаций — а шарп иногда преподносит сюрпризы и выполняет аллокации там, где совсем не ожидаешь, начисто убивая производительность. А в пайтоне используется нативная имплементация без всякой виртуальности — все вызовы функций там заинлайнены и алгоритм выполняет только полезную работу — умножить, сравнить, записать результат, передвинуть указатель к следующему значению (если не последнее) — все!
V>>Работа с массивами в numpy вообще впечатляет — очень элегантно. Занимаясь имадж процессингом, я понял, что плюсы не нужны почти нигде — все можно сделать на пайтоне — и не будет тормозить!
V>>На шарпе это невозможно.
S>Вы недооцениваете шарп.
Да я с ним немало поработал в свое время — знаю пределы возможностей. Но я не считаю, что Шарп must die. Как уже писал, Пайтон бесспорно хорош для простых проектов — желательно с одним разработчиком. В команде уже надо очень жестко следить за тем, кто чего пишет. Иначе код быстро станет несопровождабельным. И для проекта со сложной бизнес-логикой и/или сложным UI я бы все еще выбрал Шарп.
S>Здравствуйте, vfedosov, Вы писали:
V>>Ну вот к примеру +- типичная задача: нужно развернуть индекс: есть индекс по одному ключу, надо построить по другому. В пайтоне решается так:
V>>names2data = {"name1": (1, 3, "str1"), "name2": (2, 4, "str2")}
V>>data2names = {data[1]: name for name, data in names2data.items()}
S>Не очень понимаю синтаксис — что делает эта штука?
ну первая строка создает Dictionary<string, (int, int, string)> и заполняет его 2мя элементами. Это индекс — по аналогии с индексами БД — возможность быстро получить данные по имени. Быстро означает за O(ln(n)) или O(1) — полный перебор не канает.
Вторая строка создает новый Dictionary<int, string> — который содержит второй int и key из первого. Это индекс, который позволяет быстро перейти от int к name. Причем после второй строки он уже заполнен и готов к работе. Далее, если в коде тебе нужно получить быстро name для которого второй int = 3, ты пишешь:
name = data2names[3]
V>>я не в курсе, может последние версии шарпа позволяют коротко эту задачу решить — уж лет 6-7 не работаю с шарпом, но пайтон и 10 лет назад это поддерживал. Насколько кратко можно проинициализировать сложную структуру данных и насколько легко с ней работать! Кстати работает мега быстро в отличии от довольно медленного Linq.
V>>Или обработка массивов float — работает почти как на плюсах по скорости. Имеем двумерный numpy массив — картинку (яркости пикселей нормированы к 1.0), надо сделать ярче в 1.5 раза, но значения не должны быть больше 1.0:
V>>array_2d = np.min(array_2d * 1.5, 1.0)
V>>Может слегка с синтаксисом в примерах накосячил (влом проверять) — но суть такая.
V>>Представь чего на шарпе придется нагородить для этого
S>Ну, вот я себе хорошо это представляю.
S>
S>array_2d = (from a in array_2d select Math.Min(a*1.5, 1.0)).ToArray();
Это ты написал для одномерного массива. Для двумерного это будет сложнее - как раз раза в 3, чем код на пайтоне. А представь, что нужно работать с двумерным массивом RGB пикселей - то есть каждый элемент массива - тоже массив из 3х элементов. Таким образом, массив 3х-мерный. Код на пайтоне будет тот-же, а на шарпе придется дальше разворачивать.
S>S>https://github.com/evilguest/linq2d
V>>и сколько это работать будет по времени.
S>Ну, некоторые вещи работают быстрее, чем на плюсах. Может быть, numpy написан получше — можем помериться, если есть желание.
Не может этот код быстро работать, так как там виртуальное вызовы IEnumerable идут — причем несколько вызовов на одну итерацию. Шарп не поддерживает inline для подобных вызовов и работает раз в 10-50 медленнее нативного кода в таких случаях — проверено не раз — я не преувеличиваю. При каждом виртуальном вызове идет копирование всех аргументов, создание точки возврата из функции, обращение к виртуальной таблице — куча ненужного дерьма, которое несопоставимо по объему с основной операцией — умножит на 1.5 и сравнить с единицей. Это если обойдется без аллокаций — а шарп иногда преподносит сюрпризы и выполняет аллокации там, где совсем не ожидаешь, начисто убивая производительность. А в пайтоне используется нативная имплементация без всякой виртуальности — все вызовы функций там заинлайнены и алгоритм выполняет только полезную работу — умножить, сравнить, записать результат, передвинуть указатель к следующему значению (если не последнее) — все!
V>>Работа с массивами в numpy вообще впечатляет — очень элегантно. Занимаясь имадж процессингом, я понял, что плюсы не нужны почти нигде — все можно сделать на пайтоне — и не будет тормозить!
V>>На шарпе это невозможно.
S>Вы недооцениваете шарп.
Да я с ним немало поработал в свое время — знаю пределы возможностей. Но я не считаю, что Шарп must die. Как уже писал, Пайтон бесспорно хорош для простых проектов — желательно с одним разработчиком. В команде уже надо очень жестко следить за тем, кто чего пишет. Иначе код быстро станет несопровождабельным. И для проекта со сложной бизнес-логикой и/или сложным UI я бы все еще выбрал Шарп.
Re[8]: MS забило на дотнет. Питону - да, сишарпу - нет?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, vfedosov, Вы писали:
V>>Ну вот к примеру +- типичная задача: нужно развернуть индекс: есть индекс по одному ключу, надо построить по другому. В пайтоне решается так:
V>>names2data = {"name1": (1, 3, "str1"), "name2": (2, 4, "str2")}
V>>data2names = {data[1]: name for name, data in names2data.items()}
S>Не очень понимаю синтаксис — что делает эта штука?
ну первая строка создает Dictionary<string, (int, int, string)> и заполняет его 2мя элементами. Это индекс — по аналогии с индексами БД — возможность быстро получить данные по имени. Быстро означает за O(ln(n)) или O(1) — полный перебор не канает.
Вторая строка создает новый Dictionary<int, string> — который содержит второй int и key из первого. Это индекс, который позволяет быстро перейти от int к name. Причем после второй строки он уже заполнен и готов к работе. Далее, если в коде тебе нужно получить быстро name для которого второй int = 3, ты пишешь:
name = data2names[3]
V>>я не в курсе, может последние версии шарпа позволяют коротко эту задачу решить — уж лет 6-7 не работаю с шарпом, но пайтон и 10 лет назад это поддерживал. Насколько кратко можно проинициализировать сложную структуру данных и насколько легко с ней работать! Кстати работает мега быстро в отличии от довольно медленного Linq.
V>>Или обработка массивов float — работает почти как на плюсах по скорости. Имеем двумерный numpy массив — картинку (яркости пикселей нормированы к 1.0), надо сделать ярче в 1.5 раза, но значения не должны быть больше 1.0:
V>>array_2d = np.min(array_2d * 1.5, 1.0)
V>>Может слегка с синтаксисом в примерах накосячил (влом проверять) — но суть такая.
V>>Представь чего на шарпе придется нагородить для этого
S>Ну, вот я себе хорошо это представляю.
S>
Это ты написал для одномерного массива. Для двумерного это будет сложнее — как раз раза в 3, чем код на пайтоне. А представь, что нужно работать с двумерным массивом RGB пикселей — то есть каждый элемент массива — тоже массив из 3х элементов. Таким образом, массив 3х-мерный. Код на пайтоне будет тот-же, а на шарпе придется дальше разворачивать.
S>https://github.com/evilguest/linq2d
V>>и сколько это работать будет по времени.
S>Ну, некоторые вещи работают быстрее, чем на плюсах. Может быть, numpy написан получше — можем помериться, если есть желание.
Не может этот код быстро работать, так как там виртуальное вызовы IEnumerable идут — причем несколько вызовов на одну итерацию. Шарп не поддерживает inline для подобных вызовов и работает раз в 10-50 медленнее нативного кода в таких случаях — проверено не раз — я не преувеличиваю. При каждом виртуальном вызове идет копирование всех аргументов, создание точки возврата из функции, обращение к виртуальной таблице — куча ненужного дерьма, которое несопоставимо по объему с основной операцией — умножит на 1.5 и сравнить с единицей. Это если обойдется без аллокаций — а шарп иногда преподносит сюрпризы и выполняет аллокации там, где совсем не ожидаешь, начисто убивая производительность. А в пайтоне используется нативная имплементация без всякой виртуальности — все вызовы функций там заинлайнены и алгоритм выполняет только полезную работу — умножить, сравнить, записать результат, передвинуть указатель к следующему значению (если не последнее) — все!
V>>Работа с массивами в numpy вообще впечатляет — очень элегантно. Занимаясь имадж процессингом, я понял, что плюсы не нужны почти нигде — все можно сделать на пайтоне — и не будет тормозить!
V>>На шарпе это невозможно.
S>Вы недооцениваете шарп.
Да я с ним немало поработал в свое время — знаю пределы возможностей. Но я не считаю, что Шарп must die. Как уже писал, Пайтон бесспорно хорош для простых проектов — желательно с одним разработчиком. В команде уже надо очень жестко следить за тем, кто чего пишет. Иначе код быстро станет несопровождабельным. И для проекта со сложной бизнес-логикой и/или сложным UI я бы все еще выбрал Шарп.
S>Здравствуйте, vfedosov, Вы писали:
V>>Ну вот к примеру +- типичная задача: нужно развернуть индекс: есть индекс по одному ключу, надо построить по другому. В пайтоне решается так:
V>>names2data = {"name1": (1, 3, "str1"), "name2": (2, 4, "str2")}
V>>data2names = {data[1]: name for name, data in names2data.items()}
S>Не очень понимаю синтаксис — что делает эта штука?
ну первая строка создает Dictionary<string, (int, int, string)> и заполняет его 2мя элементами. Это индекс — по аналогии с индексами БД — возможность быстро получить данные по имени. Быстро означает за O(ln(n)) или O(1) — полный перебор не канает.
Вторая строка создает новый Dictionary<int, string> — который содержит второй int и key из первого. Это индекс, который позволяет быстро перейти от int к name. Причем после второй строки он уже заполнен и готов к работе. Далее, если в коде тебе нужно получить быстро name для которого второй int = 3, ты пишешь:
name = data2names[3]
V>>я не в курсе, может последние версии шарпа позволяют коротко эту задачу решить — уж лет 6-7 не работаю с шарпом, но пайтон и 10 лет назад это поддерживал. Насколько кратко можно проинициализировать сложную структуру данных и насколько легко с ней работать! Кстати работает мега быстро в отличии от довольно медленного Linq.
V>>Или обработка массивов float — работает почти как на плюсах по скорости. Имеем двумерный numpy массив — картинку (яркости пикселей нормированы к 1.0), надо сделать ярче в 1.5 раза, но значения не должны быть больше 1.0:
V>>array_2d = np.min(array_2d * 1.5, 1.0)
V>>Может слегка с синтаксисом в примерах накосячил (влом проверять) — но суть такая.
V>>Представь чего на шарпе придется нагородить для этого
S>Ну, вот я себе хорошо это представляю.
S>
S>array_2d = (from a in array_2d select Math.Min(a*1.5, 1.0)).ToArray();
S>Это ты написал для одномерного массива. Для двумерного это будет сложнее — как раз раза в 3, чем код на пайтоне. А представь, что нужно работать с двумерным массивом RGB пикселей — то есть каждый элемент массива — тоже массив из 3х элементов. Таким образом, массив 3х-мерный. Код на пайтоне будет тот-же, а на шарпе придется дальше разворачивать.
S>https://github.com/evilguest/linq2d
V>>и сколько это работать будет по времени.
S>Ну, некоторые вещи работают быстрее, чем на плюсах. Может быть, numpy написан получше — можем помериться, если есть желание.
Не может этот код быстро работать, так как там виртуальное вызовы IEnumerable идут — причем несколько вызовов на одну итерацию. Шарп не поддерживает inline для подобных вызовов и работает раз в 10-50 медленнее нативного кода в таких случаях — проверено не раз — я не преувеличиваю. При каждом виртуальном вызове идет копирование всех аргументов, создание точки возврата из функции, обращение к виртуальной таблице — куча ненужного дерьма, которое несопоставимо по объему с основной операцией — умножит на 1.5 и сравнить с единицей. Это если обойдется без аллокаций — а шарп иногда преподносит сюрпризы и выполняет аллокации там, где совсем не ожидаешь, начисто убивая производительность. А в пайтоне используется нативная имплементация без всякой виртуальности — все вызовы функций там заинлайнены и алгоритм выполняет только полезную работу — умножить, сравнить, записать результат, передвинуть указатель к следующему значению (если не последнее) — все!
V>>Работа с массивами в numpy вообще впечатляет — очень элегантно. Занимаясь имадж процессингом, я понял, что плюсы не нужны почти нигде — все можно сделать на пайтоне — и не будет тормозить!
V>>На шарпе это невозможно.
S>Вы недооцениваете шарп.
Да я с ним немало поработал в свое время — знаю пределы возможностей. Но я не считаю, что Шарп must die. Как уже писал, Пайтон бесспорно хорош для простых проектов — желательно с одним разработчиком. В команде уже надо очень жестко следить за тем, кто чего пишет. Иначе код быстро станет несопровождабельным. И для проекта со сложной бизнес-логикой и/или сложным UI я бы все еще выбрал Шарп.