Comments 19
Сложилось впечатление, что чувак хочет заново изобрести Vala.
Это не чувак отдельно взятый, а Microsoft уже готовит свою копию Go, например G# .NET ☉⏝⚆
Кстати Vala, как это ни печально, тупиковая ветвь развития.
На Go уже перекинули все QML биндинги, потихоньку строят мосты в Glib/GTK библиотеки вроде GStreamer и так далее.
Кстати Vala, как это ни печально, тупиковая ветвь развития.
На Go уже перекинули все QML биндинги, потихоньку строят мосты в Glib/GTK библиотеки вроде GStreamer и так далее.
Фишка Vala в том, что в нем GObject является нативной объектной моделью. Поэтому непонятно, какое отношение к нему будет иметь Go, и уже тем более, QML.
Я изначально сумбурно высказался, на самом деле вот, что я имел в виду.
Последний раз игрался с Vala летом 2012, после двух лет на С# это было действительно в кайф. Я активно его поддерживал в спорах с товарищами, потихоньку делал биндинг для С-версии SFML, ковырял интроспектор libafrodite и намеревался сделать плагин умного дополнения для Sublime Text 2, поскольку CTags с поддержкой Vala довольно банальное решение.
Ну а потом я посмотрел на Qt и пошло поехало, вот уже полтора года пишу на Qt/QML за белую зарплату и делаю свои курсовые. Соответственно, с оглядкой назад, выводы такие: vala делали и делают полтора человека, отладка кода невозможна, в 2012 у них текли компоненты gtk+ (кнопку 10000 раз нажать и память утекла), api ломалось и ломается, ад с версиями зависимостей (точно не помню, но кажется он libgee-1.0 переименовали в libgee-0.6, сломав api стандартных контейнеров а-ля HashMap), отсутствие инструментов разработки (самое адекватное средство это libafrodite, хотя все использующее эту либу инструменты не обновлялись с 2011).
Если бы не ElementaryOS, можно было бы зафиксировать дату смерти, но у них там своя атмосфера и язык используется, хотя Yorba, судя по блогу, впали в спячку весной 2012.
Теперь, собственно, при чём тут QML/QtQuick. Я надеюсь, что для вас не будет открытием абсолютное превосходство последнего над Gtk+. Это как сравнивать Intel и какое-нибудь наследие СССР, холодная война закончилась с выходом Qt5.
Так вот, специалист из Canonical уже наладил мост Go и Qml, уровень поддержки фактически как в Qt. Другие спецы из сообщества прокинули нужные мосты в glib и всякие библиотеки великого наследия вроде gsteamer. В Go можно встроить C/C++ код и обернуть любой нужный API как вздумается, а на выходе получим такой же нативный бинарник, только вот Go это человеческая технология, с мощной поддержкой и далёким будущим,
а с Vala вы опоздали на пару лет, тусовка кончилась ;)
Последний раз игрался с Vala летом 2012, после двух лет на С# это было действительно в кайф. Я активно его поддерживал в спорах с товарищами, потихоньку делал биндинг для С-версии SFML, ковырял интроспектор libafrodite и намеревался сделать плагин умного дополнения для Sublime Text 2, поскольку CTags с поддержкой Vala довольно банальное решение.
Ну а потом я посмотрел на Qt и пошло поехало, вот уже полтора года пишу на Qt/QML за белую зарплату и делаю свои курсовые. Соответственно, с оглядкой назад, выводы такие: vala делали и делают полтора человека, отладка кода невозможна, в 2012 у них текли компоненты gtk+ (кнопку 10000 раз нажать и память утекла), api ломалось и ломается, ад с версиями зависимостей (точно не помню, но кажется он libgee-1.0 переименовали в libgee-0.6, сломав api стандартных контейнеров а-ля HashMap), отсутствие инструментов разработки (самое адекватное средство это libafrodite, хотя все использующее эту либу инструменты не обновлялись с 2011).
Если бы не ElementaryOS, можно было бы зафиксировать дату смерти, но у них там своя атмосфера и язык используется, хотя Yorba, судя по блогу, впали в спячку весной 2012.
Теперь, собственно, при чём тут QML/QtQuick. Я надеюсь, что для вас не будет открытием абсолютное превосходство последнего над Gtk+. Это как сравнивать Intel и какое-нибудь наследие СССР, холодная война закончилась с выходом Qt5.
Так вот, специалист из Canonical уже наладил мост Go и Qml, уровень поддержки фактически как в Qt. Другие спецы из сообщества прокинули нужные мосты в glib и всякие библиотеки великого наследия вроде gsteamer. В Go можно встроить C/C++ код и обернуть любой нужный API как вздумается, а на выходе получим такой же нативный бинарник, только вот Go это человеческая технология, с мощной поддержкой и далёким будущим,
а с Vala вы опоздали на пару лет, тусовка кончилась ;)
Вот бы еще официальный порт .NET Framework под *nix с такими планами увязать.
Да ладно, Java производительнее, чем C#?
Таково мнение Даффи. Если бы утверждение о превосходстве Java над C# по производительности высказал кто-то из Sun, Oracle или даже из Java-сообщества, я бы счёл это пиаром, хвастовством и не поверил. Но когда сотрудник Microsoft утверждает о превосходстве конкурента, я не нахожу причин ему не верить. Хотя лично для меня данное утверждение тоже выглядит странно.
У сановского JVM реально лучше оптимизирующий JIT. Раньше был и более быстрый GC, но сейчас я за это уже не поручусь. Мне доводилось слышать такое объяснение этому: в JVM JIT-компилируется не все подряд, и есть байткодный интерпретатор, поэтому JIT можно сделать дорогим и долгим, но выдающим очень качественный результат, а потом включать его выборочно только для горячего кода. В CLR же архитектурно вообще нет интерпретатора байткода, там все JIT-компилируется — и компилятор, соответственно, должен быть достаточно быстрым, что ограничивает возможность использовать более дорогие оптимизации.
Поэтому при прочих равных, JVM мог выдавать более быстрый код, с более агрессивным инлайнингом, вытаскиванием объектов на стек etc.
Но на практике C# предоставляет куда больше возможностей для ручной оптимизации, благодаря наличию структур, unions (StructLayoutKind.Explicit), сырых указателей, stackalloc, fixed-полей и т.п. вещей. Поэтому «прочих равных» не получается.
Кстати, на самом деле, если внимательно посмотреть на C#, то единственное, что ему не хватает для системного программирования — это сырые указатели на функции. В остальном, он полностью покрывает весь спектр возможностей, которые есть в C. Ну, еще нужно как-то отвязать GC — для стандартных типов это вполне можно сделать подсчетом ссылок.
Поэтому при прочих равных, JVM мог выдавать более быстрый код, с более агрессивным инлайнингом, вытаскиванием объектов на стек etc.
Но на практике C# предоставляет куда больше возможностей для ручной оптимизации, благодаря наличию структур, unions (StructLayoutKind.Explicit), сырых указателей, stackalloc, fixed-полей и т.п. вещей. Поэтому «прочих равных» не получается.
Кстати, на самом деле, если внимательно посмотреть на C#, то единственное, что ему не хватает для системного программирования — это сырые указатели на функции. В остальном, он полностью покрывает весь спектр возможностей, которые есть в C. Ну, еще нужно как-то отвязать GC — для стандартных типов это вполне можно сделать подсчетом ссылок.
Может поясните, если знаете, мне странной показалась фраза: «Но удивительно, как много можно достичь при помощи хорошего оптимизирующего компилятора в противовес JIT-компиляции.». Я то всегда думал, что JIT гибче и может оптимизировать, учитывая статистику использования.
единственное, что ему не хватает для системного программирования — это сырые указатели на функции
Marshal.GetDelegateForFunctionPointer, Marshal.GetFunctionPointerForDelegate ну и опкод Calli, который передаёт управление на произвольный адрес. В принципе, средствами Mono.Cecil можно этот самый Calli внедрить в нужные места и будет полноценный вызов по указателю.
Поэтому при прочих равных, JVM мог выдавать более быстрый код, с более агрессивным инлайнингом, вытаскиванием объектов на стек etc.Не надо забывать про такую штуку как NGen (или mono --aot), которые позволяют прекомпилировать сборку со всеми нужными оптимизациями.
Да, я знаю, что на уровне CLR указатели на функции есть. Но надо это вытащить в сам язык.
NGen мог бы быть более оптимизирующим. Но на практике он генерит ровно такой же код, как обычный JIT, а местами даже и хуже (потому что не может делать инлайнинг вызовов из одной сборки в другую, из-за ограничений версионности, за исключением некоторых методов в стандатной библиотеке, на которые явно повешен атрибут «это можно инлайнить всегда»).
NGen мог бы быть более оптимизирующим. Но на практике он генерит ровно такой же код, как обычный JIT, а местами даже и хуже (потому что не может делать инлайнинг вызовов из одной сборки в другую, из-за ограничений версионности, за исключением некоторых методов в стандатной библиотеке, на которые явно повешен атрибут «это можно инлайнить всегда»).
сырых указателей, stackalloc, fixed-полей
Но от этого же неизбежно страдает безопасность, а на графике почему то этого не видно.
Странно, что он так взъелся на JIT и GC. Тот же Рихтер имеет противоположенное мнение: что у JIT'а больше вариантов для оптимизаций, а GC зачастую эффективнее, чем ручное управление памятью, так как выделение является крайне дешевой операцией по сравнению с С/С++. Существует проблема фрагментации, с этим не спорю, но при грамотном построении приложения получается, что GC даже быстрее, как раз из-за описанных преимуществ. Не говоря о том, что на хабре полгода назад была статья, что будет новый JIT, кстати, вот она.
Хотя в целом С++ побыстрее, конечно, будет, да и грамотно работают с памятью далеко не все. Но это скорее не проблемы языка, а проблемы программистов, которым проще засунуть планку на 4гб, чем оптимизировать приложение. В целом по моим ощущениям C# медленнее С++ в среднем на величину около 30%, а иногда даже быстрее. Зато плюшек у него ощутимо больше. Хотя, конечно, могли бы JIT сделать поумнее: например, компилировать быстро без оптимизаций, а затем собирая статистику, перекомпилировать «hot path» в приложении. В конце концов, раз уж ругают «монструозный .Net», жрущий кучу ресурсов и памяти, пусть хоть с толком ими распоряжается.
Хотя в целом С++ побыстрее, конечно, будет, да и грамотно работают с памятью далеко не все. Но это скорее не проблемы языка, а проблемы программистов, которым проще засунуть планку на 4гб, чем оптимизировать приложение. В целом по моим ощущениям C# медленнее С++ в среднем на величину около 30%, а иногда даже быстрее. Зато плюшек у него ощутимо больше. Хотя, конечно, могли бы JIT сделать поумнее: например, компилировать быстро без оптимизаций, а затем собирая статистику, перекомпилировать «hot path» в приложении. В конце концов, раз уж ругают «монструозный .Net», жрущий кучу ресурсов и памяти, пусть хоть с толком ими распоряжается.
Интересно что там будет по сути. В смысле — какие конкретно расширения предлагается внести в C#.
Sign up to leave a comment.
C# для системного программирования