Comments 11
Разработчики ASAN относятся к сабжу с сомнением.
Да, интересное сравнение. Вот только осталось загадкой для меня, как они определили, что AddressSanitizer быстрее, если железки, с которой можно прогнать тесты, нет ещё. Софтварная версия вполне допускаю медленнее.
Тем не менее, плюсы MPX тоже очевидны. Так что «думайте сами, решайте сами».
Тем не менее, плюсы MPX тоже очевидны. Так что «думайте сами, решайте сами».
Было бы интересно поговорить про плюсы MPX по сравнению с ASAN.
Насколько я понимаю, в ASAN используется инструментация + битмап, в котором помечены валидные для обращения байты. Существенный недостаток — не обрабатывается переполнение буфера внутри структуры (т.е. когда мы перетерли соседние поля в структуре, но за пределы структуры не вылезли).
Насколько я понимаю, в ASAN используется инструментация + битмап, в котором помечены валидные для обращения байты. Существенный недостаток — не обрабатывается переполнение буфера внутри структуры (т.е. когда мы перетерли соседние поля в структуре, но за пределы структуры не вылезли).
Сам ручками ASAN не трогал, но даже по тому, что написано в приведенной вами статье, достоинства очевидны. В частности абсолютно верно сказано про переполнения буфера внутри стурктуры без выхода за пределы самой структуры, аля
struct T {int x[10], y[20]; };…
T t;…
t.x[15];
Кроме того, ASAN не способен отлавливать overflows с большим размером:
int a[10];…
a[1000000] = 0;
Ну и MPX должен быстро работать для случаев длинных циклов с итерациями по массивам. Что, кстати, весьма свойственно для компилятора Intel, который часто используется для получения высокой производительности, то есть для HPC кода. А вот в нем то как-раз таких циклов много.
Ну и в целом, не стоит забывать, что эта фича не самая главная, но очень приятное добавление к тому, что уже есть. Если вы взяли себе компилятор от Intel (а сделали это скорее всего для получения хорошей производительности), то подобный функционал для поиска возможных проблем и отладки приложения будет явно не лишним. А вдобавок подстраховаться ASAN'ом никто не запретит я думаю.
struct T {int x[10], y[20]; };…
T t;…
t.x[15];
Кроме того, ASAN не способен отлавливать overflows с большим размером:
int a[10];…
a[1000000] = 0;
Ну и MPX должен быстро работать для случаев длинных циклов с итерациями по массивам. Что, кстати, весьма свойственно для компилятора Intel, который часто используется для получения высокой производительности, то есть для HPC кода. А вот в нем то как-раз таких циклов много.
Ну и в целом, не стоит забывать, что эта фича не самая главная, но очень приятное добавление к тому, что уже есть. Если вы взяли себе компилятор от Intel (а сделали это скорее всего для получения хорошей производительности), то подобный функционал для поиска возможных проблем и отладки приложения будет явно не лишним. А вдобавок подстраховаться ASAN'ом никто не запретит я думаю.
И, кстати, написанное ими про то, что MPX не может отлавливать «use-after-free bugs» не правда. Ну, точнее, Pointer Checker, то есть софтовая реализация, это как раз может и я привел даже пример про это. А вот насколько знаю, в «железе» (именно в самой технологии MPX) это появится не сразу, но появится.
я думал такие проблемы в прошлом, сейчас же все умные указатели используют. Это может пригодится разве что только на микроконтроллерах под С
Это далеко не так. Проблема ещё весьма и весьма актуальна.
Не очень понятно, за что заминусовали человека. В реальной жизни все эти malloc, free, void* ptr в нормальном плюсовом коде нынче встречаются крайне редко, скорее из области «С с классами». Задачу, в которой нужно использовать обычный массив вместо std::vector не так-то просто придумать, разве что правда какие-нибудь микроконтроллеры, где ресурсы всего и всея максимально ограничены, и мы не можем тратиться на жирную стандартную библиотеку.
Я не говорю, что представленная технология плохая — отнюдь. Другое дело, что использование современных возможностей языка уже давно позволяет не ломать себе голову со всякими выходами за пределы массива (итераторы) или различного рода memory leaks (умные указатели).
Я не говорю, что представленная технология плохая — отнюдь. Другое дело, что использование современных возможностей языка уже давно позволяет не ломать себе голову со всякими выходами за пределы массива (итераторы) или различного рода memory leaks (умные указатели).
это видать те кто не умеет пользоваться умными векторами или не хочет т.к. «старое самое лучшее», в противном случае могли бы и объяснить
Это те, кому нужна производительность и кто работает с HPC кодом. Поверьте, там ещё до сих пор работают с простыми «старыми» массивами, потому как уж очень не любит векторизатор всё новое. Он даже простые указатели то «недолюбливает».
Так вот если нужно, чтобы всё работало быстро — точно не сторонники умных векторов.
Так вот если нужно, чтобы всё работало быстро — точно не сторонники умных векторов.
Ещё не стоит забывать про огромное количество уже существующего кода в разных областях, который нужно поддерживать. Переписывать его пока мало кто собирается. Новый функционал — возможно, но только не созданный продукт. Вообщем, не стоит думать что это всё для любителей «старого самого лучшего».
Sign up to leave a comment.
Pointer Checker: проверим наши указатели