Pull to refresh
58
0
Alexander Kalinin @alec_kalinin

User

Send message

Рекомендую проект https://pyscript.net/. Можно посмотреть примеры, Python в броузере в PyScript реализации уже выглядит вполне реальным инструментом. А с учетом того, что PyScript детище anaconda.io, разработчика наиболее популярного научного дистрибутива Python, кажется что этот проект может взлететь.

В общем, Python скоро всех съест...

Попробуйте LiveCharts2. Также можно посмотреть на пример RealtimeDemo в библиотеке OxyPlot. На моей машине рендеринг графика из 20000 точек идет со скорость 60 FPS.

В моей области WPF очень популярен для разработки приложений для медицинской диагностики и медицинской визуализации. В таких приложениях обычно маловато типовых форм, и необходим достаточно сложный кастомный GUI с большой долей графики и анимации.

Типовой пример это приложение Varian Eclipse для планирования протонной терапии.

Спасибо за статью! Добавлю несколько библиотек от себя

  • WPF UI -- современная библиотека визуальных стилей, молодая и активно развивающаяся

  • OxyPlot -- библиотека 2D графики, тянет real-time отображение

  • Helix Toolkit -- высокоуровненая библиотека 3D графики

Добавлю свои соображения, как разработчик GUI на WPF.

Если кратко, то перспективы у WPF вполне себе неплохие. Microsoft сделала очень правильную вещь, открыла код .NET и WPF. Репозиторий WPF активный, пулл-реквесты мержутся, roadmap адекватный. Впрочем WinForms себя чувствуют даже лучше WPF. И в целом для простых GUI задач я советую выбирать WInForms.

Но а если длинно, то Microsoft достаточно сильно запуталась в своих GUI фреймворках. WinForms это удобная обертка над Win32 API, она никуда не денется. Но WinForms тесно завязан на визуальный дизайнер форм, поэтому масштабное GUI на нем писать сложно.

WPF очень красив архитектурно со своей MVVM моделью и рендерингом на DirectX. Первоначально он оказался не таким быстрым, как планировался и достаточно сложным. Но со временем детские проблемы были решена, и он завоевал ведущую роль в разработке GUI под Windows.

Но потом Microsoft подзабила на WPF и стала развивать концепцию UWP. UWP это приложения, отделенные от Win32API, живущие в своей песочнице, но способные работать на разных устройствах. Но UWP приложения так и не завовевали популярность. И получилась так сказать фрагментация платформы Windows. Одновоременно существовала старая добрая Win32, но совсем списывать в утиль UWP Microsoft не захотела.

Новая иницатива Microsoft это создание нового универсального WindowsAPI, объединяющая Win32 и UWP. И новый GUI фрейморк WinUI3. Недавно была выпущена версия 1.0. Но по обсуждениям в GitHub пока это все жутко тормозное и глючное. И не факт, что взлетит.

Плюс в Microsoft пошла новая инициатива, все пересписать на Web технологии. По крайней мере, лобби этого направление сильно.

К счастью, Microsoft наконец объединила .NET и .NET фреймворк в единую платформу .NET и открыла код. Все это дало новую жизнь WinForms и WPF.

Так что на текущий момет времени если писать сложное GUI под Windows desktop не по web технологиям, то WPF почти безальтернативый выбор. Собственно поэтому он сейчас достаточно неплохо чувствует, развивается и его будущее выглядит вполне неплохим.

Сдается мне, джентльмены, что в родительском комментарии про C++ и ASM это была ирония.

А если серьезно, то бекэнд бекэнду рознь. Одно дело, если это какая-то типовая финансовая бизнес логика, то тут может быть Python и не самый идеальный выбор. А вот если нужно обрабатывать данные, которые укладываются в численный python с его NumPy + Jax + нейронные сетки, то Python по производительности еще даст фору многим нативным решениям.

В целом да, Qt это для C++. Хотя у них есть QML/QtQuick для написания UI на основе декларативного JavaScript.

Но огромный плюс Qt это очень стабильный API для кроссплатформенного декстопа. Qt было, есть и будет. Хотя и на C++.

А вот что и когда Microsoft решить закопать в следующий раз, это большой вопрос. Начинать проект на WPF сейчас крайне рискованно. Команду WPF почти разогнали и не факт, что восстановят. Пулл-реквесты висят годами.

А WinUI 3 где-то раз в 100 медленнее WPF.

И что делать?...

Самым удивительным является тот факт, что WinForms сейчас гораздо живее WPF. Если поглядеть на GitHub репозиторий WPF, то большинство коммитов сейчас делается автоматическим копированием зависимостей с WinForms.

В общем это даже понятно. WinForms является оберткой над Win32 API, а это в некотором смысле основа десктопа Windows.

А вот WPF Microsoft старательно закапывает ради нового продукта под названием Win UI 3, надстроенного над новым Windows App SDK, который является в некотором смысле реинкарнацией невзлетевшего UWP.

Но пока Win UI 3 крайне сырая и медленная. Более того, многих возможностей WPF там нет, и не скоро появятся. В частности довольно удобная 3D графика WPF в WinUI 3 не факт, что вообще когда-нибудь появится.

Так что если что-то сейчас писать для Windows декстопа, то вариантов то почти нет. WPF Microsoft старательно убивает, WinUI может вообще не взлететь. Писать на JavaScript под Electron? Или ReactNative?

С этой точки зрения WinForms живее всех живых.

А вообще, я бы рекомендовал Qt для нового декстоп проекта под Windows.

Я бы для этой задачи использовал бы scientfic python с использованием свертки

import numpy as np
from scipy.ndimage import convolve

board = np.zeros(shape=(height, width), dtype=np.uint8)

kernel = np.array([[1, 1, 1], 
                   [1, 0, 1], 
                   [1, 1, 1]], dtype=np.uint8)
board_state = convolve(board, kernel, mode="wrap")

Для огромных досок используем sparse matrix representation, а для быстрых сверток можно использовать какой-нибудь deep learning framework.

Это хайп по фразе вырванной из контекста. Собственно ответом на это и была статья. Там был вопрос в духе "Можно ли будет запустить WinUI 3 на Xbox". И ответ - в ближайшее время нет, используйте UWP и WinUI 2.X, который продолжает развиваться.

Может быть и так. Но я вот смотрю историю WinUI 3 roadmap в GitHub и вижу, что все упоминания UWP в контексте WinUI 3 были старательно убраны, например фразу

There's also a preview version of WinUI 3 available that supports
building UWP apps - 
see the [preview release notes](https://aka.ms/winui3/projectreunion-0.8preview).

заменили на

There's also a version of WinUI 3 available that includes experimental features.
You can read more about the Windows App SDK Preview at the following documentation.

По последним новостям WinUI 3 не будет поддерживать UWP. И, как следует из фразы разработчиков WinUI 3, "...Our focus is on trying to reach out to the existing very large community of Win32 desktop developers" идет возврат опять к классическому Win32 десктопу. Поэтому будущая судьба UWP у меня под большим вопросом.

И эти метания Microsoft, честно говоря, уже надоели. WPF вроде как уже legacy, будет ли поддерживаться UWP большой вопрос. Тогда в чем смысл WinUI 3? Очередная обертка над Win32?

В этом плане Qt выглядит как оплот стабильности для современной декстоп разработки.

Как-то это все не слишком идеоматичный Питон. Вообще, я думаю все эти задачи решаются однострочниками.

Например, первая задача решается так
print('\n'.join([' '.join([str(i)] * i) for i in range(6)]))


Вторая так
n = 5
print('\n'.join([' '.join([str(i + 1)] * (n - i)) for i in range(n)]))


И так далее…
Пара слов про pybind11. Если вы глянете на исходники pybind11, то станет понятно, что это во многом синтаксический сахар над тем самым исходным core C API. И то, что pybind11 стал таким простым, этот как раз заслуга исходной хорошо продуманной интеграции C. Да и в целом, на Python есть биндинги почти к любой библиотеке на C/C++/Fortran. Вряд ли это было бы возможно при плохо продуманной интеграции.

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

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

А что касается более мощных языков. Мне они крайне интересны. Но все, что я хочу, чтобы люди не совершали ошибок, при которых мы переписали всё на $КРУТОЙЯЗЫК, но стартап всё равно не взлетел.
Вот тут не соглашусь. По большому счету, весь современный Machine Learning это TensorFlow + PyTorch. А это все Python.

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

А связано это с тем фактом, что современное hardware для научных вычислений довольно таки гетерогенное: многоядерные CPU, кластеры машин, GPU, TPU. Вручную параллелить алгоритмы на весь этот зоопарк слишком тяжело.

И несколько лет назад акцент в научных вычислениях сместился к идеологии потоковых вычислительных графов. Лучше всего это описано в документации к TensorFlow. Каждый алгоритм мы представляем в виде графа вычислений. Каждый узел графа это какая-то операция, дифференцирование, интегрирование, свертка и т.п. Далее этот граф компилируется под каждое специализированное hardwarе, и через него пропускается сплошной поток данных.

Оказалось, что большое количество вычислительных задач крайне эффективно вписывается в эту схему. А язык Python оказался идеальным для создания таких графов.
Для линейной алгебры никто питоновские массивы не использует, так что наличие слайсов в языке погоды не меняет, библиотеки все решают.
Встроенные слайсы, оператор '@' для матричного умножения и много всего другого. Поглядите на сравнение одинаковых операций Python c MatLab. Python гораздо красивее выглядит чем Matlab. А MatLab специально создавался для научных вычислений с матрицами. Понятно, что все делается через библиотеки. Но оцените, как органично эти библиотеки вписываются в сам язык!

Идеальное взаимодействие с СИ?! приходится всё руками делать, поддержка плюсов вообще сомневаюсь что есть, слишком уж это сложная проблема
А вы пробовали pybind11. Я уже и не знаю, что проще то может быть, пара строчек и получем бесшовную интеграцию C++ кода в Python:
#include <pybind11/pybind11.h>

int add(int i, int j) {
    return i + j;
}

PYBIND11_MODULE(example, m) {
    m.doc() = "pybind11 example plugin"; // optional module docstring

    m.def("add", &add, "A function which adds two numbers");
}
Если рассматривать просто как язык, то ничем не лучше, а местами так-то и хуже, а где-то и вообще плохо.

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

Теперь можно построить буквально парой строчек + парой аннотаций крайне производительный код, который перемолет огромные массивы данных крайне быстро, почти на 100% эффективно используя доступные ресурсы.
Ну да, это можно назвать путем костылей. А еще можно назвать естественной эволюцией наиболее приспособленного к реальным нуждам инструмента. Так то у нас тоже есть не один баг в дизайне. Однако как то живем, вполне успешно при этом.

Может быть Python и создавался как один из простейших скриптовых языков. Но с рождения он получил очень много преимуществ: a) крайне понятный для чтения язык, б) в целом почти естественная поддержка массивов со слайсами, что идеально вписалось в научные вычисления, основанные на линейной алгебре, c) идеальное взаимодействие с Fortran/C/C++, d) внятная система пакетов.

В результате Python стали «идеальным клеем» для связи между численными библиотеками, позволяя их вызывать почти без оверхеда. Это позволило стать Python почти идеальным языком для вычислений, основанных на концепции потокового графа, как в Tensorflow. А это позволило для ряда задач почти решить проблему гетерогенных вычислительных систем (CPU + GPU) с автоматической параллелизацией.

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

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

То, что я вижу в Numba, вполне в духе дзена Python и позволяет получить производительность, близкую к нативной. По крайней мере Numba c типами гораздо ближе к красивому Python, чем те же расширения на монструозном Cython.

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

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity