Вроде понял посыл статьи, что-то в этом есть, сам много раз такое чувствовал, не люблю когда мне впаривают целебные свойства циркониевых браслетов потому что восточная мудрость так сказала, но всё гораздо сложнее же.
способ максимально эффективного взаимодействия с реальностью
Пусть Вы хотите узнать, поможет ли Вам лекарство X от Вашей болезни Y. Что из нижеперечисленного будет эффективнее?
а) Заболеть болезнью Y двести раз, из них сто раз принимать лекарство X и сто раз выздороветь самостоятельно, навести матстат.
б) Изучить имеющиеся научные работы по теме, убедиться что в них нет явных ошибок, постараться воспроизвести эксперименты.
в) Поверить авторитетному врачу вслепую. Если не поможет, поверить другому авторитетному врачу вслепую.
Мне очевидно, что научный метод не эффективен, потому что требует огромных усилий. Получение хотя бы одного внятного результата во многих случаях может занять недели, месяцы, годы — научный метод не состоялся бы без переиспользования результатов трудов тысяч учёных за сотни лет. Результаты — надёжные, переиспользуемые истины — в быту почти никогда не нужны, потому что простые бытовые эвристики работают гораздо лучше, хоть и заметно врут временами. Тем более когда речь про познание себя, где нельзя переиспользовать чужие результаты, а на исследование отводится один человеко-век (pun intended).
Это как наиболее эффективный способ писать программы. Если из-за ошибки будут падать самолёты или теряться миллионы долларов на бирже, то вы изучаете физику, вовлекаете математику с этой её математической точностью, используете зашибенные паттерны проектирования и пишете верифицируемый код. А если цена ошибки ничтожна, то вполне можно считать, что природа боится пустоты, все нечётные числа простые, написать три строчки на бейсике и радоваться.
Как-то ковырялся с чем-то таким по другому поводу (под линуксом). Там лажа была что всякие валгринды не понимали что есть утечка, потому что всё потом освобождалось. Тоже перехватывал api захвата-освобождения и разбирал многогигабайтные csv-трассы malloc/calloc/realloc/free, хоть и питоном. При этом вся память перед смертью приложения освобождалась, а просто при ничего не делании (скажем "перейти во вкладку, перейти обратно в исходное положение" (1)) неограниченно росла, поэтому всякие валгринды не осиливали.
То есть да, неосвобождённая память в любой момент до смерти программы разделяется на ту что "просто ещё не освободилась но нужна", и на ту что мы хотим найти, которая тоже ещё не освободилась, которая тоже потом освободится, но которая "не нужна". Поэтому можно проскипать любой кусок истории вначале, когда программа насоздавала объектов один раз чтобы с ними жить. И, разумеется, кусок истории "в конце", когда "ненужная" память будет тоже удалена и мы всё потеряем.
А потом я просто тыкал сценарий (1) и глазами смотрел на трассу утечек и находил повторяющиеся аллокации. Получить по ним бэктрейс — уже кто как умеет, мне повезло что там аллок с красивым числом байтов был и я кондишнл-брейк просто поставил. А так либо инструмент сразу даст все бэктрейсы, либо ставить больше брейков, на разные библиотеки, и тоже поиск логарифмически сложный выходит.
А поделитесь секретом — насколько локализован был баг на небольшой площади кода? В смысле ну статический анализ смог бы найти?
Вроде понял посыл статьи, что-то в этом есть, сам много раз такое чувствовал, не люблю когда мне впаривают целебные свойства циркониевых браслетов потому что восточная мудрость так сказала, но всё гораздо сложнее же.
Пусть Вы хотите узнать, поможет ли Вам лекарство X от Вашей болезни Y. Что из нижеперечисленного будет эффективнее?
а) Заболеть болезнью Y двести раз, из них сто раз принимать лекарство X и сто раз выздороветь самостоятельно, навести матстат.
б) Изучить имеющиеся научные работы по теме, убедиться что в них нет явных ошибок, постараться воспроизвести эксперименты.
в) Поверить авторитетному врачу вслепую. Если не поможет, поверить другому авторитетному врачу вслепую.
Мне очевидно, что научный метод не эффективен, потому что требует огромных усилий. Получение хотя бы одного внятного результата во многих случаях может занять недели, месяцы, годы — научный метод не состоялся бы без переиспользования результатов трудов тысяч учёных за сотни лет. Результаты — надёжные, переиспользуемые истины — в быту почти никогда не нужны, потому что простые бытовые эвристики работают гораздо лучше, хоть и заметно врут временами. Тем более когда речь про познание себя, где нельзя переиспользовать чужие результаты, а на исследование отводится один человеко-век (pun intended).
Это как наиболее эффективный способ писать программы. Если из-за ошибки будут падать самолёты или теряться миллионы долларов на бирже, то вы изучаете физику, вовлекаете математику с этой её математической точностью, используете зашибенные паттерны проектирования и пишете верифицируемый код. А если цена ошибки ничтожна, то вполне можно считать, что природа боится пустоты, все нечётные числа простые, написать три строчки на бейсике и радоваться.
Ну, справедливости ради, кланг всё-таки старается немножко (clang-cl, -fms-compatibility, -fdelayed-template-parsing, https://clang.llvm.org/docs/MSVCCompatibility.html).
Хоть цель и была "потыкать самому", всёж советую
clang-queryиASTMatchersдля таких задач.Наверное даже можно сделать инструмент, который будет её хорошо решать, чтобы ему надо было только кормить запущенное приложение и моменты.
P.S. Извиняюсь за самоповторы в комменте выше, старческий маразм/оверредактиринг.
Как-то ковырялся с чем-то таким по другому поводу (под линуксом). Там лажа была что всякие валгринды не понимали что есть утечка, потому что всё потом освобождалось. Тоже перехватывал api захвата-освобождения и разбирал многогигабайтные csv-трассы malloc/calloc/realloc/free, хоть и питоном. При этом вся память перед смертью приложения освобождалась, а просто при ничего не делании (скажем "перейти во вкладку, перейти обратно в исходное положение" (1)) неограниченно росла, поэтому всякие валгринды не осиливали.
То есть да, неосвобождённая память в любой момент до смерти программы разделяется на ту что "просто ещё не освободилась но нужна", и на ту что мы хотим найти, которая тоже ещё не освободилась, которая тоже потом освободится, но которая "не нужна". Поэтому можно проскипать любой кусок истории вначале, когда программа насоздавала объектов один раз чтобы с ними жить. И, разумеется, кусок истории "в конце", когда "ненужная" память будет тоже удалена и мы всё потеряем.
А потом я просто тыкал сценарий (1) и глазами смотрел на трассу утечек и находил повторяющиеся аллокации. Получить по ним бэктрейс — уже кто как умеет, мне повезло что там аллок с красивым числом байтов был и я кондишнл-брейк просто поставил. А так либо инструмент сразу даст все бэктрейсы, либо ставить больше брейков, на разные библиотеки, и тоже поиск логарифмически сложный выходит.
А поделитесь секретом — насколько локализован был баг на небольшой площади кода? В смысле ну статический анализ смог бы найти?