4 Commits

Include renames

Author	SHA1	Message	Date
Jon Ross-Perkins	c25177658a	Add more compile benchmark stats (#4408) ... I was discussing some details of cross-compiler lex performance. Since we were talking about LoC initially, and lex performance especially will differ based on bytes and tokens being lexed, throwing in some stats for how we're processing those. Here's some example output: ``` ---------------------------------------------------------------------------------------------------------------------------- Benchmark Time CPU Iterations Bytes Lines Tokens ---------------------------------------------------------------------------------------------------------------------------- BM_CompileAPIFileDenseDecls<Phase::Lex>/256 31828 ns 31798 ns 22528 165.64M/s 6.13247M/s 34.6249M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/1024 147513 ns 147434 ns 5120 220.363M/s 6.64025M/s 39.014M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/4096 611530 ns 610985 ns 1280 232.22M/s 6.59264M/s 39.0501M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/16384 2645671 ns 2643411 ns 320 231.122M/s 6.17119M/s 36.616M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/65536 11593324 ns 11587201 ns 64 217.864M/s 5.64934M/s 33.5378M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/262144 60338069 ns 60313976 ns 16 169.444M/s 4.34607M/s 25.8032M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/256 53355 ns 53308 ns 13312 98.8029M/s 3.65798M/s 20.6535M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/1024 253979 ns 253818 ns 3072 128.001M/s 3.8571M/s 22.6619M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/4096 1052984 ns 1052427 ns 768 134.815M/s 3.82734M/s 22.6705M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/16384 4364730 ns 4362756 ns 192 140.038M/s 3.73915M/s 22.1857M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/65536 19419562 ns 19413505 ns 48 130.035M/s 3.37188M/s 20.0175M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/262144 89023213 ns 88979387 ns 8 114.856M/s 2.94595M/s 17.4905M/s BM_CompileAPIFileDenseDecls<Phase::Check>/256 676254 ns 675605 ns 1024 7.79597M/s 288.63k/s 1.62965M/s BM_CompileAPIFileDenseDecls<Phase::Check>/1024 1412608 ns 1411876 ns 1024 23.0112M/s 693.404k/s 4.07401M/s BM_CompileAPIFileDenseDecls<Phase::Check>/4096 4333665 ns 4331240 ns 256 32.7581M/s 929.988k/s 5.50858M/s BM_CompileAPIFileDenseDecls<Phase::Check>/16384 16566625 ns 16553982 ns 64 36.9065M/s 985.443k/s 5.84699M/s BM_CompileAPIFileDenseDecls<Phase::Check>/65536 68609701 ns 68542189 ns 16 36.8304M/s 955.032k/s 5.66963M/s BM_CompileAPIFileDenseDecls<Phase::Check>/262144 302899379 ns 302596672 ns 8 33.7739M/s 866.265k/s 5.14313M/s ``` Also note, this is the discussion that led to [me looking at bytes per token](https://discord.com/channels/655572317891461132/655578254970716160/1295803122844700786)	2024-10-22 00:22:46 +00:00
Jon Ross-Perkins	e382e6fd97	Refactor FindPreludeFiles into InstallPaths (#4268) ... From the driver's perspective, `FindPreludeFiles` is closely tied to `compile`. This makes it difficult to refactor commands without affecting the test dependencies on `FindPreludeFiles`. `InstallPaths` seems like a decent home since it is responsible for the install structure. I'm switching to an `Error` return to allow callers to choose how to handle it (e.g., in file tests, we typically don't want the direct error stream).	2024-09-04 22:22:48 +00:00
Chandler Carruth	72cb9d0d06	Refactor testing exe path and benchmark main handling. (#4216) ... Consolidates both main libraries into `//testing/base`, and factors out the exe path handling for benchmarks and unit tests into a common library to remove duplication. Refactors how that logic is managed to be cleaner and avoid a confusing bool that came up in code review. Updates all the tests and benchmarks that use these. I still need to update other benchmarks to use the same main, but I wanted to keep this PR somewhat minimal. This also fixes a bug noticed in passing that the compilation benchmark didn't have the required dependency on the benchmark library itself, just the benchmark main library.	2024-08-14 17:50:08 +00:00
3 people	a9c815c9f4	Introduce a source generator and end-to-end compile benchmarks (#4124) ... The big addition here is a very, very rough and very early skeleton of a source code generator framework. This builds upon the lexers identifier synthesis logic, improving on its framework and wiring it up with the most rudimentary of source file generation. This is just enough to roughly replicate my "big API file" source code benchmarks. The source generation works *very* hard to both vary the structure and content of the source as much as possible while ensuring the same *total* amount of each construct is in use, from bytes in identifiers to line breaks, parameters, etc. This lets us generate randomly structure inputs that should consistently take the exact same amount of total work to compile. The complex identifier synthesis logic from the lexer's benchmark is moved over here and the lexer uses APIs in the source generator for identifiers. The other source synthesis in the lexer's benchmark isn't yet moved over, but should likely be slowly absorbed here as it can be refactored into a more principled and re-usable form. Some bits may stay of course if they're just too lexer-specific. Next, this adds a simple end-to-end compile benchmark for the driver that directly and much more clearly reproduces all the measurements I've done manually up until now. It should also be easy to extend to more patterns over time as we add support to the source generator to produce those patterns. Last but not least, I've added a tiny CLI to the source generator so that you can generate source code manually. This is especially nice for generating demo source code to actually run through the driver or look at in an editor. The CLI can also generate C++ source code which lets us do some minimal comparative benchmarking between Carbon and C++/Clang. There are huge number of TODOs in the source generation framework. This is going to be a large ongoing effort I suspect. There are also a bunch of rough edges I've left to try and get this out for review sooner. I've left TODOs for refactorings that really need to be done here, but hoping these can maybe be follow-ups. If not, please flag and I'll try to layer them on here. Sample compile benchmark output, nicely showing where we are w.r.t. our goal speeds (2x behind on lex and check, 5x on parse) at least on a recent AMD server CPU: ``` ------------------------------------------------------------------------------------------------------ Benchmark Time CPU Iterations Lines ------------------------------------------------------------------------------------------------------ BM_CompileAPIFileDenseDecls<Phase::Lex>/256 29420 ns 29419 ns 22860 6.62847M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/1024 146130 ns 146128 ns 4840 6.69959M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/4096 601584 ns 601577 ns 1020 6.69573M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/16384 2547578 ns 2547313 ns 280 6.404M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/65536 10816591 ns 10816389 ns 80 6.05193M/s BM_CompileAPIFileDenseDecls<Phase::Lex>/262144 52191320 ns 52189828 ns 20 5.02261M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/256 101706 ns 101698 ns 6900 1.91745M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/1024 512161 ns 512162 ns 1380 1.9115M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/4096 2078426 ns 2078430 ns 340 1.938M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/16384 8795786 ns 8795583 ns 100 1.85468M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/65536 35073596 ns 35072973 ns 20 1.86639M/s BM_CompileAPIFileDenseDecls<Phase::Parse>/262144 151100688 ns 151097370 ns 20 1.73483M/s BM_CompileAPIFileDenseDecls<Phase::Check>/256 957059 ns 957049 ns 740 203.751k/s BM_CompileAPIFileDenseDecls<Phase::Check>/1024 1956134 ns 1955985 ns 360 500.515k/s BM_CompileAPIFileDenseDecls<Phase::Check>/4096 5797864 ns 5797417 ns 120 694.792k/s BM_CompileAPIFileDenseDecls<Phase::Check>/16384 21219608 ns 21217584 ns 40 768.843k/s BM_CompileAPIFileDenseDecls<Phase::Check>/65536 96311116 ns 96302334 ns 20 679.734k/s BM_CompileAPIFileDenseDecls<Phase::Check>/262144 371637963 ns 371609964 ns 20 705.387k/s ``` Lest someone think this is *bad*, the fact that we're already within 2x of our rather audacious goals makes me quite happy. =D --------- Co-authored-by: Jon Ross-Perkins <jperkins@google.com> Co-authored-by: Richard Smith <richard@metafoo.co.uk>	2024-08-13 19:37:55 +00:00