-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Batch mode formation minor fixes #15091
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Batch mode formation minor fixes #15091
Conversation
@swift-ci please test |
lib/Driver/ToolChain.cpp
Outdated
sortBatchInputJobs(ArrayRef<const Job *> jobs, | ||
SmallVector<const Job *, 16> &sortedJobs, | ||
Compilation &C) { | ||
llvm::StringMap<const Job *> jobsByInput; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mapping by string seems expensive. Is it not possible to just use the order of jobs before shuffling?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, but I can perform a shuffle in a way that maintains the order if you prefer. I would like to leave this in as an assert that the orders match, in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it doesn't matter cause we do tons of other string lookups. This just wasn't the obvious way to get the original order back for me.
Build failed |
Build failed |
14f3904
to
4bdc0cf
Compare
4bdc0cf
to
409c23c
Compare
@jrose-apple pushed update that does the shuffle on indices not jobs, thus maintaining invariant. Switched the comparison-to-the-input sequence to just be an assert. |
@swift-ci please test |
Build failed |
Build failed |
lib/Driver/Compilation.cpp
Outdated
for (const Job *Cmd : Batchable) { | ||
maybeAdvanceToNextPartition(i, Partition, Batchable.size()); | ||
std::vector<const Job*> &P = Partition[i]; | ||
for (size_t i = 0; i < Batchable.size(); ++i) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you want, there's an llvm::for_each
that can do parallel iteration over two containers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assuming you mean swift::for_each (in include/swift/Basic/STLExtras.h), nice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, forgot it was us and not them.
lib/Driver/Compilation.cpp
Outdated
// size of the first Remainder of them. | ||
if (P < Remainder) | ||
++TargetSize; | ||
for (size_t N = 0; N < TargetSize; ++N) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could use std::fill_n
here but I guess it may or may not be clearer than just writing it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure.
// RUN: %swiftc_driver -enable-batch-mode -driver-batch-seed 1 -driver-print-jobs -driver-skip-execution -j 3 -emit-module -module-name foo %t/file-01.swift %t/file-02.swift %t/file-03.swift %t/file-04.swift %t/file-05.swift %t/file-06.swift %t/file-07.swift %t/file-08.swift %t/file-09.swift >%t/out.txt | ||
// RUN: %FileCheck %s <%t/out.txt | ||
// | ||
// Each batch should get 3 primaries; check that each has 3 modules _in the same numeric order_. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are we going to do with this test when we switch to output file maps? Just delete it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I can add a note to that extent.
409c23c
to
fa830fe
Compare
@swift-ci please test and merge |
1 similar comment
@swift-ci please test and merge |
@swift-ci please test Linux platform |
Build failed |
@swift-ci please test Linux platform |
Build failed |
@swift-ci please smoke test and merge |
The test suite fails after this pull request on Fedora Linux 27 (with ToT clang/llvm). Build log: http://znu.io/pr15091.log The relevant error:
|
Uh, hm. The random number generation should be deterministic, since the definition |
Do the Swift Linux build bots use libstdc++ or libcxx? |
Whatever stock ubuntu is, afaict. But .. well, I'm .. sympathetic to the idea that the prng ought to be stable, since it's spec'ed, but also that I meant the test that fails there to be not-sensitive to PRNG order, and I missed that the failing test here will now be sensitive. @davezarzycki can you run this test and see if it passes? https://github.com/google/libcxx/blob/master/test/numerics/rand/rand.predef/minstd_rand.pass.cpp |
I built it with the same compiler I use to build Swift ToT. It passes. I also just did a clean build and reinstall of ToT clang+llvm+lld in case it matters, and then did a clean build-and-test of llvm+clang+swift. Same error. |
@davezarzycki Interesting; I wonder if this has something more to do with a container type behaving differently, like in the job queue or such. Can you grab the actual-output from the failing line of the test (eg. modify test/Driver/batch_mode.swift to redirect the 3rd %swiftc_driver execution -- the SEED2 one -- to a file and pastebin it?) |
Here you go: http://znu.io/seed2.out |
@davezarzycki Great, that clarified that it's definitely a different sequence, and that was enough to find the issue: the PRNG is spec'ed tightly enough not to vary this way, but std::shuffle isn't -- it uses the PRNG in a way that leaves some variation in implementation: libstdc++: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_algo.h#L3777-L3858 Different shuffle algorithms :( So I need to make the test more order-insensitive. Thanks for catching this! |
Hi @graydon – Thanks for being so responsive and helpful in debugging this :-) |
Oh, oops. Once I ruled out the obvious thing I didn't keep thinking. Of course std::shuffle isn't spec'd in the same way. |
This fixes a couple minor issues that arose while testing batch mode. Neither is critical to correct functioning, they just help testing.
The first eliminates a quadratic assert, which I incorrectly assumed was cheaper than a path I thought was already occurring at worse-than-quadratic complexity (relative to batch size). This is not true and to keep things moving quickly on large batches I believe it's not worth making this assertion; it doesn't check a condition that's very plausible anyways.
The second fixes a potential mismatch between the emitted order of primary-file arguments and additional output arguments passed to the frontend. This doesn't happen in normal runs, but when shuffling the batch constituents with -driver-batch-seed -- as happens when doing randomized testing -- it does. And in general it's a condition we ought to be ensuring regardless (at least until we do away with positionally pairing-up primaries and their additionals on the frontend command line).