3 ms·

I meant reprocessing the same set of header files for every single cpp file including them. Precompiled headers suppose to speed it up. But they still need to

by ww520 16y ago

I meant reprocessing the same set of header files for every single cpp file including them. Precompiled headers suppose to speed it up. But they still need to be read in and re-created in memory for each cpp file. Why not just compile all the cpp files in one process rather than spawning off a compiler process for every file? That can ensure reusing all the header files processed and are still in memory. My point is: run the profiler, see what are the bottlenecks, and pick those areas for optimization. Rather than speculating that L1/L2 cache misses are causing the major delay. If they ran the profiler and L1/L2 cache misses are really the problem, then I have nothing else to say.

astrange 16y ago
> But they still need to be read in and re-created in memory for each cpp file. This is just mmap for Clang. For GCC it... isn't. The other one you mentioned is called a compile server and nobody seems to have cared enough to implement it. > If they ran the profiler and L1/L2 cache misses are really the problem, then I have nothing else to say. http://gcc.gnu.org/ml/gcc/2011-04/msg00315.html http://gcc.gnu.org/ml/gcc/2011-04/msg00315.html
- ww520 16y ago
  Compile server, interesting concept. If no one cares to implement it, that means performance is not a high value item for people to improve upon. That's an interesting problem in doing a lot of lookup from main memory since the data structures are too big to fit in L1/L2. But that usage is not allocating a lot of short lived objects and freeing them, and reusing the freed memory right the way for next allocations. That's what Linus arguing for to reused the L1/L2 for the short lived objects, and thus GC is inappropriate. I would imagine compilers typically allocate objects that have long lifetime, such as declarations that have scope through the whole compile cycle. Also if memory allocation/deallocation is really a performance problem, then don't deallocate, just reuse the buffers. Reusing the same set of buffers would make sure they are hot in L1/L2. Anyway it has been an interesting discussion.

by ww520 16y ago

astrange 16y ago

> But they still need to be read in and re-created in memory for each cpp file. This is just mmap for Clang. For GCC it... isn't. The other one you mentioned is called a compile server and nobody seems to have cared enough to implement it. > If they ran the profiler and L1/L2 cache misses are really the problem, then I have nothing else to say. http://gcc.gnu.org/ml/gcc/2011-04/msg00315.html http://gcc.gnu.org/ml/gcc/2011-04/msg00315.html

ww520 16y ago
Compile server, interesting concept. If no one cares to implement it, that means performance is not a high value item for people to improve upon. That's an interesting problem in doing a lot of lookup from main memory since the data structures are too big to fit in L1/L2. But that usage is not allocating a lot of short lived objects and freeing them, and reusing the freed memory right the way for next allocations. That's what Linus arguing for to reused the L1/L2 for the short lived objects, and thus GC is inappropriate. I would imagine compilers typically allocate objects that have long lifetime, such as declarations that have scope through the whole compile cycle. Also if memory allocation/deallocation is really a performance problem, then don't deallocate, just reuse the buffers. Reusing the same set of buffers would make sure they are hot in L1/L2. Anyway it has been an interesting discussion.