Attack #848

mayaswissa · 2024-11-12T13:07:51Z

No description provided.

fix ATTACK_LOG, call attack

change PGDAttack *_pgdAttac in ENgine to std::unique_ptr

wu-haoze · 2024-12-11T13:50:05Z

There seem to be extra files like .vscode/launch.json that need to be removed from the PR.

idan0610 · 2024-12-15T07:29:51Z

Does this solve the start up time issues described in #754 when linking libtorch? If so, how did you do it?

We are not actually solve this issue, and that's why we added a new CMake flag to allow building Marabou without importing the torch library, if someone is not interested in this delay when running multiple number of short queries in a row. But if someone else wants to run a more difficult query, that is expected to take a much longer time, this delay becomes negligible, and the adversarial attack is expected to significantly improve runtimes at least for SAT queries.

MatthewDaggitt · 2024-12-16T02:53:55Z

We are not actually solve this issue, and that's why we added a new CMake flag to allow building Marabou without importing the torch library, if someone is not interested in this delay when running multiple number of short queries in a row. But if someone else wants to run a more difficult query, that is expected to take a much longer time, this delay becomes negligible, and the adversarial attack is expected to significantly improve runtimes at least for SAT queries.

Thanks for you answer @idan0610. While I understand the pragmatics of this decision, this proliferation of build flags seems like a mistake to me in the long term... What happens if the performance incompatibilities with the PyTorch build options get worse? How do we know how this flag interacts with all the other possible flags for Marabou?

If this is the approach taken then, given that we have known compatibility issues with this build config, my advice would be that at the very least we should run the whole test suite twice - once with the PyTorch build flag on and once with it off.

MatthewDaggitt · 2024-12-16T02:56:47Z

This should also be documented in the Changelog.

idan0610 · 2024-12-16T12:01:53Z

.vscode/launch.json

remove this file from PR

idan0610 · 2024-12-16T12:02:19Z

.vscode/settings.json

idan0610 · 2024-12-16T12:05:33Z

CMakeLists.txt

@@ -20,29 +20,29 @@ option(RUN_SYSTEM_TEST "Run system tests on build" OFF)
 option(RUN_MEMORY_TEST "Run cxxtest testing with ASAN ON" ON)
 option(RUN_PYTHON_TEST "Run Python API tests if building with Python" OFF)
 option(ENABLE_GUROBI "Enable use the Gurobi optimizer" OFF)
-option(ENABLE_OPENBLAS "Do symbolic bound tighting using blas" ON) # Not available on Windows


Return the default value to ON

idan0610 · 2024-12-16T12:05:46Z

CMakeLists.txt

 option(CODE_COVERAGE "Add code coverage" OFF)  # Available only in debug mode
-
+option(BUILD_TORCH "Build libtorch" ON)


Default should be OFF

idan0610 · 2024-12-16T12:09:16Z

src/configuration/GlobalConfiguration.cpp

@@ -78,7 +78,7 @@ const bool GlobalConfiguration::PREPROCESS_INPUT_QUERY = true;
 const bool GlobalConfiguration::PREPROCESSOR_ELIMINATE_VARIABLES = true;
 const bool GlobalConfiguration::PL_CONSTRAINTS_ADD_AUX_EQUATIONS_AFTER_PREPROCESSING = true;
 const bool GlobalConfiguration::NL_CONSTRAINTS_ADD_AUX_EQUATIONS_AFTER_PREPROCESSING = true;
-const double GlobalConfiguration::PREPROCESSOR_ALMOST_FIXED_THRESHOLD = 0.00001;


Return the previous default value of 0.0001

idan0610 · 2024-12-16T12:25:20Z

src/configuration/Options.cpp

@@ -71,6 +73,7 @@ void Options::initializeDefaultValues()
    _intOptions[SEED] = 1;
    _intOptions[NUM_BLAS_THREADS] = 1;
    _intOptions[NUM_CONSTRAINTS_TO_REFINE_INC_LIN] = 30;
+    _intOptions[ATTACK_TIMEOUT] = 60; // todo?


60 seconds sounds fine by me, remove todo

idan0610 · 2024-12-16T12:34:25Z

src/engine/Marabou.cpp

@@ -57,6 +57,7 @@ Marabou::~Marabou()

 void Marabou::run()
 {
+    std::cout << "start run time: " << TimeUtils::now().ascii() << std::endl;


remove print, or transfer to log

idan0610 · 2024-12-16T12:34:38Z

src/engine/Marabou.cpp

@@ -69,6 +70,8 @@ void Marabou::run()

    if ( Options::get()->getBool( Options::EXPORT_ASSIGNMENT ) )
        exportAssignment();
+
+    std::cout << "end run time: " << TimeUtils::now().ascii() << std::endl;


here as well

idan0610 · 2024-12-16T13:49:28Z

src/engine/Marabou.cpp

    if ( _engine->processInputQuery( _inputQuery ) )
    {
+        if (_engine->getExitCode() == Engine::ATTACK_SAT)


fix coding style

idan0610 · 2024-12-16T13:49:37Z

src/engine/Marabou.cpp

@@ -300,6 +308,11 @@ void Marabou::displayResults( unsigned long long microSecondsElapsed ) const
            printf( "\n" );
        }
    }
+    else if (result == Engine::ATTACK_SAT)


…omDNN.cpp, ATTACK_SAT to SAT,

idan0610 · 2024-12-16T14:27:03Z

We are not actually solve this issue, and that's why we added a new CMake flag to allow building Marabou without importing the torch library, if someone is not interested in this delay when running multiple number of short queries in a row. But if someone else wants to run a more difficult query, that is expected to take a much longer time, this delay becomes negligible, and the adversarial attack is expected to significantly improve runtimes at least for SAT queries.

Thanks for you answer @idan0610. While I understand the pragmatics of this decision, this proliferation of build flags seems like a mistake to me in the long term... What happens if the performance incompatibilities with the PyTorch build options get worse? How do we know how this flag interacts with all the other possible flags for Marabou?

If this is the approach taken then, given that we have known compatibility issues with this build config, my advice would be that at the very least we should run the whole test suite twice - once with the PyTorch build flag on and once with it off.

I understand your concerns, and I'm not sure what is the preferred way to handle this either.
@guykatzz What do you think?

guykatzz · 2024-12-31T13:07:58Z

Hi all, and apologies for the delay in my reply.

Matthew, I'm not sure I understand your particular concern about PyTorch. Marabou uses a bunch of other external packages - most notably Gurobi, but also blas, and boost, and possibly a few others. Sure, it is good to run tests with this flag set to both ON and OFF; but are you especially concerned about this package?

MatthewDaggitt · 2025-01-01T03:28:14Z

Matthew, I'm not sure I understand your particular concern about PyTorch. Marabou uses a bunch of other external packages - most notably Gurobi, but also blas, and boost, and possibly a few others. Sure, it is good to run tests with this flag set to both ON and OFF; but are you especially concerned about this package?

I'm concerned about this package in particular because when we build with Pytorch, we know that the performance of Marabou degrades noticeably (wish we knew why). At least as far as I'm aware there's not a known incompatibility issue with the rest of the code base when building with Gurobi/blas/boost.

MatthewDaggitt · 2025-01-01T03:32:17Z

I'm definitely not in anyway trying to block this PR from merging, but I did want to highlight that it's potentially a hit to maintainability of the code base!

guykatzz · 2025-01-02T12:35:07Z

Can you elaborate on what you mean by "we know that the performance of Marabou degrades noticeably"?

My understanding was that loading PyTorch incurred a certain overhead for each query, but that would only happen if the flag was set to true, right? And in Maya and Idan's experiments we see a significant speedup for certain queries.

MatthewDaggitt · 2025-01-03T04:00:17Z

Can you elaborate on what you mean by "we know that the performance of Marabou degrades noticeably"?

My understanding was that loading PyTorch incurred a certain overhead for each query, but that would only happen if the flag was set to true, right?

Yes, this overhead was what I was referring to. Sorry, I should have said "degrades noticeably on some types of queries".

For context, the added overhead for each query when building with PyTorch can't be a "we're running extra code" issue, but instead is some incompatibility with the build settings of PyTorch and Marabou and should really be fixable.

If we could fix it then we should always build with PyTorch because then we could use the tensor library in the neural network parsers to fix the existing performance issues. I could then actually make progress in replacing most of the Python parsers with calls to the C++ parser. However, it was (rightly!) judged that the effects building with the PyTorch flag on was unacceptable.

mayaswissa added 30 commits June 15, 2024 15:09

add attack files

b94fdde

changes for attack

f7f4fdc

cmake

fb07f91

fix

d7e67ef

all

96f31ef

install torch

502118c

fix attack and torch

aac8eb1

torch

654619b

fix attack and torch

4cad1dc

check nlr null

ad2cb59

output bounds check

336c3dc

onnexParser 975 &

1b23749

check _networkLevelReasoner not null in Engine.cpp

0e1f9a1

minor changes

f524517

minor changes

367abaa

change to cmake cluster

d159b78

fix activations

5791447

fix bounds and output, improve loss and verify customDNN

7051166

change num iters and CMakeLists.txt for cluster.

7c6385f

maxPool and improve LR

476c519

update DEFAULT_NUM_RESTARTS

7b69540

find delta to find example

bc1375d

improve loss

51c7090

pgd class &

1102cbf

fix customDNN class &

7cbe917

fix customDNN

1d19289

exit if attack succeeded

343bbbf

change default restarts

61d1cbf

change default restarts and iterations

53738b6

remove prints

8b7aeb8

mayaswissa added 6 commits November 26, 2024 17:48

CMakeLists.txt

105a769

CMakeLists.txt BUILD_TORCH ON

42cc2f6

CMakeLists.txt : set(TORCH_CXX_FLAGS "-Wno-error=array-bounds")

a5a6ff6

fix ATTACK_LOG, call attack

change PGD logging

174bb45

ENGINE_LOGGING, CUSTOM_DNN_LOGGING, PGD_LOG=true

7f4565c

change model in PGD to std::unique_ptr<CustomDNN> _model.

46011cf

change PGDAttack *_pgdAttac in ENgine to std::unique_ptr

Fix memory leak + change default for running pgd attack to false

58723cc

idan0610 reviewed Dec 16, 2024

View reviewed changes

remove vscode files , Marabou_LOG to LOG , sources.popBack(); in Cust…

36d5b71

…omDNN.cpp, ATTACK_SAT to SAT,

idan0610 closed this Dec 16, 2024

idan0610 reopened this Dec 16, 2024

mayaswissa added 5 commits December 16, 2024 16:30

CHANGELOG.md

ddb068d

PGD_LOGGING, CUSTOM_DNN_LOGGING = false

77041b5

Engine.cpp #ifdef BIULD_TORCH

8bba518

change attack time log

dbd57d5

change attack time log

88c90d5

mayaswissa closed this Dec 18, 2024

mayaswissa deleted the attack branch December 18, 2024 11:55

change timeout attack error

d870652

mayaswissa reopened this Dec 18, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Attack #848

Attack #848

mayaswissa commented Nov 12, 2024

wu-haoze commented Dec 11, 2024

idan0610 commented Dec 15, 2024 •

edited

Loading

MatthewDaggitt commented Dec 16, 2024 •

edited

Loading

MatthewDaggitt commented Dec 16, 2024

idan0610 Dec 16, 2024

idan0610 Dec 16, 2024

idan0610 Dec 16, 2024

idan0610 Dec 16, 2024

idan0610 Dec 16, 2024

idan0610 Dec 16, 2024

idan0610 Dec 16, 2024

idan0610 Dec 16, 2024

idan0610 Dec 16, 2024

idan0610 Dec 16, 2024

idan0610 commented Dec 16, 2024 •

edited

Loading

guykatzz commented Dec 31, 2024

MatthewDaggitt commented Jan 1, 2025

MatthewDaggitt commented Jan 1, 2025

guykatzz commented Jan 2, 2025

MatthewDaggitt commented Jan 3, 2025

		option(CODE_COVERAGE "Add code coverage" OFF) # Available only in debug mode

		option(BUILD_TORCH "Build libtorch" ON)

Attack #848

Are you sure you want to change the base?

Attack #848

Conversation

mayaswissa commented Nov 12, 2024

wu-haoze commented Dec 11, 2024

idan0610 commented Dec 15, 2024 • edited Loading

MatthewDaggitt commented Dec 16, 2024 • edited Loading

MatthewDaggitt commented Dec 16, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

idan0610 commented Dec 16, 2024 • edited Loading

guykatzz commented Dec 31, 2024

MatthewDaggitt commented Jan 1, 2025

MatthewDaggitt commented Jan 1, 2025

guykatzz commented Jan 2, 2025

MatthewDaggitt commented Jan 3, 2025

idan0610 commented Dec 15, 2024 •

edited

Loading

MatthewDaggitt commented Dec 16, 2024 •

edited

Loading

idan0610 commented Dec 16, 2024 •

edited

Loading