Оптимизация в питоне?

в clang тоже завезли. Если без defer жизнь не мила, то вот пример того, как это можно сделать

Ну да, ожидаемо, поскольку clang - это попытка освободить GCC от GPL, сохраняя совместимость.

просто популярность такого подхода в среде сишников примерно нулевая

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

Зачем городить огород, если в подавляющем большинстве случаев можно обойтись банальным goto?

Goto не позволяет определить потерю видимости переменной. А если тебе очень хочется котроль и предсказуемость, то лучше используй ассемблер.

И что же более удобно, чем java?

Эм-м-м.... всё? Бери любой мало-мальски развитый язык - я найду, почему он более удобен, чем жава. Кроме C#, который является клоном Java. И кроме C/C++, породивших огромное число глючного, падающего, и текущего софта, и зашкваривших таким образом саму идею ручного управления памятью, заменив ее крайней противоположностью - полной невозможностью оказывать влияние на процессы высвобождения памяти.

Я здесь пишу про язык Java, а не про JVM, которая вполне сносна в качестве низкоуровневой виртуалки со сборкой мусора для высокоуровневых языков, способных эту сборку мусора действительно оправдано использовать.

Тот же системд

Про системдэ лучше нинада ) То, что там кто-то впитывает, это, скорее, антиреклама )

Goto не позволяет определить потерю видимости переменной.

Goto позволяет перейти прямиком к тому месту где все локальные объекты пора почистить. Целый кернел запилили с опорой на этот незамысловатый подход. Есть ли какой-нибудь наглядный пример того, где это не работает?

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

Ты снова про асм-стиль программирования. Да, на ассемблере писали ядра ОС, не спорю. Но сейчас, на фоне расширения ресурсоемких функций компиляторов по оптимизации кода, писать на асме не просто бесполезно, а даже контрпродуктивно: компилятор сгенерирует код лучше тебя, поскольку в него внесены алгоритмы работы самых прошаренных ассемблерщиков, которые знакомы с оптимизацией лучше тебя.

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

Целый кернел запилили с опорой на этот незамысловатый подход. Есть ли какой-нибудь наглядный пример того, где это не работает?

Ядро - это хороший пример, где это не работает. Например: https://access.redhat.com/security/cve/cve-2017-6074
Спустя 12 лет этот баг нашли - а сколько подобных багов еще не нашли? Повышение прав юзера до рута из-за неправильной работы с памятью - это чума, которой болеет линукс всю историю своего существования. Справедливости ради замечу, что близкие по архитектуре и методике разработки ОС тоже этим болеют.

писать на асме не просто бесполезно, а даже контрпродуктивно

нет возражений

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

Вовсе нет. Вполне достаточно указать КАК освободить ресурс, ( а если в ЯП нет деструкторов? контролируйте все ручками, жаба превед) а остальное сделает автомат. Автомат - это не обязательно компилятор, вот о чем речь.

да еще и через Goto, которое ломает всю структуру функции.

goto ломает глаза и структуру только если нарушает data flow, а при переходе сверху-вниз проблем не вызывает, скорее наоборот.

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

Ну просто С работает с памятью, в отличие, к примеру, от языков с GC. Как только ЯП с чем то работает там тут же возникают проблемы. Недавно новость про дичайший косяк с питонолибой пробегала, из-за которого накрылись медным тазом труды ученых-химиков. А как можно писать ОС и при этом не работать с памятью это вопрос мильярдов на триста.

Вполне достаточно указать КАК освободить ресурс, ( а если в ЯП нет деструкторов? контролируйте все ручками, жаба превед) а остальное сделает автомат. Автомат - это не обязательно компилятор, вот о чем речь.

Про какой автомат речь? Ни один компилятор Си до введения cleanup в GCC не умел корректно сам осовобождать ресурсы.

goto ломает глаза и структуру только если нарушает data flow, а при переходе сверху-вниз проблем не вызывает, скорее наоборот.

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

Ну просто С работает с памятью, в отличие, к примеру, от языков с GC. Как только ЯП с чем то работает там тут же возникают проблемы

Почему С++ победил Си? Потому что работа с памятью может организовываться по разному. Она может быть совершенно беспорядочной, как это сделано в Си, и она может быть организованной, пусть и слабо, как это сделано в C++. Банальное упорядочивание работы с памятью даст потерю 5-10-20% производительности, но устранит целый слой багов на корню - по крайней мере в тех алгоритмах, где эта организация всеобъемлюща, не размешана с другими.

Про какой автомат речь?

Подсчет ссылок в плюсах пример автомата реализованного не в компиляторе. И без помощи GC.

Ни один компилятор Си до введения cleanup в GCC не умел корректно сам осовобождать ресурсы.

Компиляторы и с этой опцией освободят только то, что сказано. А что и как освобождать они (компиляторы) увы, сами не догадаются без ЦУ девелопера.

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

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

У сей множество недостатков. Главная же проблема в том, что одна и та же задача может быть решена множеством способов, каждый из которых не имеет шансов стать каноничным и единственным. Где-то удобно так, где-то по другому. На вопрос «а как же правильно» в стандартах ответа нет. То ли дело гошечка - defer и никаких гвоздей. Любой ЯП с прибитым гвоздями каноничным методом решения проблем выигрывает, апатамушта меньше способов выстрелить в ногу себе и людям. Меньше вопросов, больше ответов, проще жить. Цена за это уплачена, но она может быть вполне соразмерной и в куче кейсов очень даже приемлемой. Так что я не топлю за всеобщий и единственный си. Просто хочу сказать что, на мой взгляд, дело не в принципиальной невозможности сделать что-то, а в удобстве и сахаре.

Подсчет ссылок в плюсах пример автомата реализованного не в компиляторе. И без помощи GC.

Подсчет ссылок в плюсах не имеет свой ценности без автоматических конструкторов и деструкторов. Иначе ведь и на Си можно подсчет ссылок вручную сделать. Так что подсчет ссылок в плюсах вполне в компиляторе сделан, и возможности подсчета органичены возможностями компилятора.

Ни один компилятор Си до введения cleanup в GCC не умел корректно сам осовобождать ресурсы.

Компиляторы и с этой опцией освободят только то, что сказано. А что и как освобождать они (компиляторы) увы, сами не догадаются без ЦУ девелопера.

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

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

Один ресурс использует другой. Значит, либо их нужно развязать перед освобождением второго ресурса, либо нужно освободить их вместе. Эту логику весьма тяжело писать на Си, и, по этой причине, легко допустить ошибку - а их было допущено огромное кол-во. Все буфера, в конечном счете, таки особождаются в одном, ясно обозначенном месте - это free(), но делу это никак не помогает, потому что проблемой является принятие решения об освобождении, а не само освобождение.

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

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

И чо? В жаве можно одну и ту же проблему решить разными способами, но это не мешает делать надежные приложения. Питон, PHP, Javascript - та же история. Главная проблема Си заключается в том, что он склоняет программиста совершать неуловимые ошибки с непредсказуемыми последствиями (пресвятое undefined behaviour), и от квалификации программиста зависит только кол-во ошибок. Этого нет в паскале, этого нет в фортране, этого нет в коболе - это специфика именно Си. И именно за это Си любят - за возможность написать программу с ошибками, которая при этом будет исправно работать во все дни недели, кроме субботы - ну и черт с ней. в субботу все равно никто не работает. Так приложения с ошибками крутятся на ответственных машинах, изредка падая, что списывается на кару божью, пока спустя десять-двадцать лет кто-то случайно не находит уязвимость удаленного исполнения кода.

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

Атрибут cleanup дает ровно такую же возможность, как и defer в Го. При этом, точно так же можно руками освобождать ресурс - я не вижу здесь отличия в языках. При этом, Го намного, намного надежнее, чем Си.

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

Этот «сахар» называет компилятор, и он уже много десятилетий упрощает работу программиста.

Так что подсчет ссылок в плюсах вполне в компиляторе сделан, и возможности подсчета органичены возможностями компилятора.

Все фичи ЯП ограничены возможностями компилятора.

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

Компилятор не умеет? Научим. Псевдокод.

my_dirty_func1(resources, ...){
    res1 = resources.get(MEM);
    ....
    if(smth) return;
    res2 = resources.get(FD);
    ....
    res2 = resources.get(MY_VERY_SPL_RES);
    ....
}
my_dirty_func2(resources, ...){
    res1 = resources.get(MEM);
    ....
    res2 = resources.get(FD);
    ....
    res2 = resources.get(MY_VERY_SPL_RES);
    ....
    // break, return, whatever
}

my_clean_func(dirty_func_t func, ...){
    res_t resources;
        func(resources, ...);
    resourses.cleanup();
}

Где-то на необъятных просторах инета уже видел такое. Функция my_clean_func одна, отладить ее как два пальца об асфальт, и можно уже ничего никогда самому не чистить в пределах любой из dirty_func.

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

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

Вот и я о том же. За свою 15 летнюю карьеру программиста ничего удобнее java я в руках не держал и не подержу. Потому что java с самого рождения заткнула всех за пояс и с каждым годом продолжает всех затыкать. Хипстакам это, конечно же, не нравится. Отсюда и питоны всякие и го.

Так что подсчет ссылок в плюсах вполне в компиляторе сделан, и возможности подсчета органичены возможностями компилятора.

Все фичи ЯП ограничены возможностями компилятора.

Подсчет ссылок можно сделать на асме, и даже на машинных кодах. Но автоматический подсчет ссылок можно сделать только с компилятором С++, точнее, использовать автоматические вызовы конструкторов/деструкторов для реализации увеличения/уменьшения счетчика ссылок.

Компилятор не умеет? Научим. Псевдокод.
my_dirty_func1(resources, ...){
my_clean_func(dirty_func_t func, ...){

Поздравляю, ты только что превратил три строчки кода в нечитаемый вырвиглазный кошмар, где выделение ресурса разнесено в отдельную от выделения функцию. Да, это лучше, чем goto - но оба варианта ужасны в плане читаемости, поддерживаемости, и устойчивости к человеческим ошибкам. Кто-то использует неинициализированное значение в res_t resources - насколько мне известно, компиляторы Си не способны отслеживать не инициализированные функциями поля в структурах. Код прям-таки просит «ну дай мне обрести неопределенное поведение».

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

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

Как я понимаю, те «беспроблемные» сишные проги, которые ты имеешь в виду, представляют собой ось, утилитки, компиляторы/интерпретаторы, которые в результате длительного разностороннего тестирования были вылизаны до возможности использования. Так еще давным давно писался оракл, который живет только благодаря десяткам миллионов (в прямом смысле) тестов. В репе линукса нет тестов - некоторые говорят, что это потому, что кодеры ядра настолько круты, что им не нужны тесты. К сожалению, в репах линукса нет тестов потому, что тесты эти намного больше исходников ядра, и представляют собой самый разный софт на самом разном железе, который гоняется многие месяцы в поисках проблем.

Я хочу продемонстрировать свои слова снова тем же 12-летним багом - слишком уж он хорош. Проблема была при включенной опции IPV6_RECVPKTINFO - то есть, маловостребованная опция, потому ее мало тестировали. IPv6 стал более популярным - бага всплыла на тестах. Так ее и спустя 30 лет бы никто не нашел - примерно так горы багов прямо сейчас лежат в драйверах и ждут своего дня.

Как я понимаю, те «беспроблемные» сишные проги, которые ты имеешь в виду, представляют собой ось, утилитки, компиляторы/интерпретаторы, которые в результате длительного разностороннего тестирования были вылизаны до возможности использования.

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

Я хочу продемонстрировать свои слова снова тем же 12-летним багом - слишком уж он хорош. Проблема была при включенной опции IPV6_RECVPKTINFO - то есть, маловостребованная опция, потому ее мало тестировали. IPv6 стал более популярным - бага всплыла на тестах. Так ее и спустя 30 лет бы никто не нашел - примерно так горы багов прямо сейчас лежат в драйверах и ждут своего дня.

Хочу напомнить тебе о питонолибе, погубившей труды ученых-химиков. Все ДУМАЛИ, что она работает. Ваще никаких внешних признаков. Там хоть речь о мертвой ветке кода, которую стали юзать и внезапно случился ой. А тут юзали либу во все поля. ГЦ? - есть. Сахар? - есть. Чего нет? - мозгов нет. И это не исправить каким-то волшебным компилятором или чем там еще.

Хочу напомнить тебе о питонолибе, погубившей труды ученых-химиков. Все ДУМАЛИ, что она работает.

Виноваты бездари-ученые, которые как обычно через анус написали свой софт. Нельзя на glob завязывать результаты своей работы - оно в принципе для этого не предназначено. Еще раз: кто-то фармит лича в лордероне, а кто-то фармит докторское звание.

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

Легкий в освоении ЯП для не-программистов должен быть таким, чтобы думать как можно меньше, а сделать как можно больше.

Ну что, сделали? Молодцы, поздравляю. Если ты делаешь код, который используется десятками людей, то «авось прокатит» уже не прокатывает.

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

И это тоже не прокатывает, потому что ты банально не сможешь открыть файл с диска по имени.

больших и открытых OpenSource проектов и перелез на GNU/Linux

я уже могу создать формочку с кнопками, да?

ух блин, у меня аж в глазах зарябило от обилия синтаксиса

slack на безопасной платформе электрон радует чуть ли не ежедневно

буквально 2 недели назад сожрал всю память и комп завис

оч безопасно, а радует как!!

Ну добавь 128 гиг и все будет ok!

ты уже можешь сервера писать на нем

а кнопочки с формочками делаются в JS - либо в браузере, либо в Электроне

я уже могу создать формочку с кнопками, да?

Конечно, к твоим услугам:

• GTK#3(GNU LIBRARY GENERAL PUBLIC LICENSE Version 2)
• Avalonia (The MIT License (MIT))
• Xamarin.Forms (The MIT License (MIT))

Все под капотом используют Gtk, так что будет выглядеть нативненько на линуксе.

Так и запишу:

типичным прогам которые не хелловорлд на электроне надо 128 гиг памяти

ты уже можешь сервера писать на нем

сервера я буду писать на C а не на неизвестно чем

а кнопочки с формочками делаются в JS - либо в браузере, либо в Электроне

у хипстоты которая жрет всё что ей дают

WPF тоже к моим услугам, да?

я могу взять любую опенсорс программу на вашем пресловутом сисярпе и скомпилить под линукс? без пританцовок? а если там GUI на WPF?

росказни про опенсорс очень интересны, все почему-то опускают информацию что он крайне ограничен и на практике вылазит куча проблем и непоняток

если я буду писать что-то на GUI то у меня достаточно библиотек, но C# я точно для этого не возьму

WPF тоже к моим услугам, да?
я могу взять любую опенсорс программу на вашем пресловутом сисярпе и скомпилить под линукс? без пританцовок? а если там GUI на WPF?

WPF умер. Его поддерживают, но его не развивают. К сожалению, WPF вышел накануне бума игрофонов, потому windows-only desktop-only инструмент оказался мимо кассы, и MS быстро переключилось на UWP. Есть Авалония, есть Мунлайт, которые очень близки к WPF - это, по крайней мере, живые технологии.

MS быстро переключилось на UWP

он же наверняка тоже открыт и уже билдится под линукс, да?

он же наверняка тоже открыт и уже билдится под линукс, да?

Открыт, вот https://github.com/microsoft/microsoft-ui-xaml

MIT License

Можешь портировать на Linux.

Можешь портировать на Linux.

изначально я отвечал на фразу стиви:

с тех пор Шарпей переродился в один из самых больших и открытых OpenSource проектов и перелез на GNU/Linux

сечешь, да?

сечешь, да?

Что такого что части библиотек нет под какую-то платформу?

Внезапно, например, JavaFX(возьмём как аналог WPF) нет для OpenIndiana, OpenBSD, DragonflyBSD, Haiku и возможно для каких-то других операционных систем.

Означает ли это, что Java не кроссплатформенна и не OpenSource?

OpenIndiana, OpenBSD, DragonflyBSD, Haiku

а что сразу не с первой плойки начал ну или 4.3BSD-RENO?

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

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

ну и при чём здесь работа с памятью?

На пальцах - даже если ЯП не работает с памятью это не избавляет от ошибок. Тебе разрешили работать с файловой системой - ты и там накосячишь.

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

Проблемы разработчиков энд-юзера не волнуют.

Если прога похоронила годы усилий, то отмазка типа «а зато ни разу память не попортила!» не проканает )

Если прога похоронила годы усилий, то отмазка типа «а зато ни разу память не попортила!» не проканает

Эта ошибка легко предотвращалась, но крайне низкий уровень навыков человеков, писавших этот софт, выкидывает обсуждение вопроса вообще за рамки этого треда, поскольку не имеет отношения ни к работе с памятью, ни к проектированию языков, ни к оптимизации. Чтобы эта ошибка не произошла, нужно было написать в документации по glob что-то абсурдное, уровня руководства к микроволновке, вроде «модуль не предназначается для использования в ответственном ПО для научных вычислений».

модуль не предназначается для использования в ответственном ПО для научных вычислений

ахах )))

дисклеймер перед использованием любого ЯП

За все что вы нарукожопите при помощи этого ЯП редакция ответственности не несет. 
При создании компилятора ни одно животное не пострадало.

На таком высоком уровне ты ничего не оптимизируешь. Тут работают только оптимизации на уровне алгоритмов.

Не согласен, на ТыТрубе есть ролики по теме.

ТыТрубе есть ролики по теме

Сильный аргумент.

Туповатый тролль какой-то. Тезисы - C# говно, буду писать сервера на Си. Какие ты сервера собрался писать на Си? тс накинул, и сбежалось стадо троллей на оптимизацию питона, причём про питон 1 комментарий из ста.

твой папаша туповатый

когда ты на практике сталкиваешься с кодовой базой каждый второй софтины на C# и пытаешься хоть как-то сделать чтобы оно заработало не только на винде начинаешь понимать что «кроссплатформенность! ататат! линукс поддерживается!!» это росказни лоровских крикунов, не более того

Смотря какой софт, ты всё в кучу то не мешай. Тема то про питон. Чем не кросс-платформа? А кроссплатформенным GUI толком и не может быть, самое удобное решение - вебкит и софт на базе него.

ТыТрубе есть ролики по теме

Сильный аргумент.

но проверять я его конечно не буду? :)

Ты же написал багрепорты?

Ты же написал багрепорты?

Написал багрепорт. К сожалению, там непаханное поле, и я ушел в другую степь. Проблема как бы в том, что даже если мультиинтерпретаторы сделают - под что их потом использовать?

На пальцах - даже если ЯП не работает с памятью это не избавляет от ошибок.

копетан, перелогиньтесь

Тебе разрешили работать с файловой системой - ты и там накосячишь.

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

Сильный аргумент.

но у тебя-то вообще никакого нет.

Есть, просто у кого-то дислексия. Читаешь текст и не одупляешь там написанного. Могу снизойти и разжевать.

чел не разобравшись, как работает функция, начал её использовать, а виноват, конечно же язык

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

Яйца те же - вид сбоку.

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

Это не аргумент, а «кококо, я скозал»