Conversation
- Also add expected output file for tests. The test will generate an actual.txt file and compare that with the expected output.
Update makefile to run tests
Brilliant work again, cheers :) Sorry for not pushing too much myself this week work's been a bit hectic. I'll add an initial Build instructions section in the Readme but feel free to add anything you think should be there. |
Oh, don't worry about pushing yourself on a side project. I'm looking to test what Andrei Alexandrescu had asked on reddit. I just ran Flint++ on it, and it finished in 3.5 seconds If Flint wins, then I'll profile Flint++ to see where it's losing time and On Sat, May 10, 2014 at 10:10 PM, Joss Whittle notifications@github.comwrote:
|
I'd be interested to see those benchmarks. I have a feeling Facebook's D implementation will be significantly faster than their original C++ version, but if anything that will likely be due to overhead in their Folly library on the C++ side. I've also been toying with the idea of using OpenMP to lint multiple files in parallel. Seeing as all lint messages are buffered in a report object before output there shouldn't be any garbled output. |
Couldn't the std::thread and C++11 concurrency model itself allow for that? I have never used OpenMP, so I may be missing the advantages. On Sun, May 11, 2014 at 10:03 AM, Joss Whittle notifications@github.comwrote:
|
my main motivation behind using OpenMP was that I use it frequently for my research so I feel confident in my ability to optimize a program using it. I've been looking at I've refactored the |
The only downside to using OpenMP is that That said, OpenMP is supposed to be coming 'soon' for the trunk |
Good shout @kevinushey, I didn't realize Clang didn't ship with OpenMP support. Seems like Currently every check which (for example) needs to run for each class/struct/union definition all iterate over the whole file to find those initial linting conditions. Similarly, many of the tests iterate over the whole file without being able to skip any tokens like the NULL vs nullptr check. If some of these tests could be grouped into a single pass over the token stream I think it could really speed things up. |
So I tested Flint++, Flint C++ and Flint D against our internal project (it's 31K LOC in C++11). Flint++ - 0m0.987s Flint C++ - 0m0.391s Flint D - 0m2.047s I'm not sure why the D version is slower than the C++ versions. |
So we're half as fast as their original code. I think this can be partly attributed to their use of a class called |
The test will generate an actual.txt file and compare that with the
expected output.
I'm not sure where in the README.md you'd want to put an instruction for running the tests, so I left that.