3 ms·

I disagree. I compile a lot. Every day. Almost daily in Java, Objective C, and C++ (Yes, I work actively on all three languages these months). 90% of the time

I disagree. I compile a lot. Every day. Almost daily in Java, Objective C, and C++ (Yes, I work actively on all three languages these months). 90% of the time I compile one file (the one I just changed) and then I link. Linking is not parallel and it takes about 4-15 seconds (dep. on the project/lang.). I use an i9 with 8 cores, but I suspect that a CPU with fewer cores, that go really fast for seconds before throttling would be quite good for most of what I do during the day. Including testing+debugging the executable. Recompiling everything takes minutes. It happens maybe once per hour, and I often combine the recompile with a coffee-break. So since it happens rarely it doesn't matter if that takes 0.5-5 minutes (dep. on project). I don't mind waiting for the recompile, but I hate changing a few lines, compiling, waiting for 20 seconds, and then testing. I find that hose medium length waits destroy flow and creativity during the day. I would definitely prefer fast single-file compilation + linking + testing, over fast full project recompiles. In summary, I think these M1 devices will actually be great for developers using compiled languages.

PaulDavisThe1st 6y ago
It does depend on project scale, and what you're doing with it. A full compile of my project on my 2950X (16 core threadripper gen 1) takes 4m20s. If I'm messing around with a new GUI-visible feature, then yes, often it's 1 or 2 files to compile, then a link step (thank you, llc, for parallel linking). Anything can handle that, even if it is C++ :) But if I'm doing a change to the core headers, it typically means multi-minute wait even on the threadripper. And that's something I've been doing for a couple of months now, working on basic architectural changes. The idea of doing such work on machine that took 50-100% longer to do a full build would be a serious problem. I don't see anything on the horizon (yet) that uses Apple silicon that helps that kind of development process.
- joakleaf 6y ago
  Yes. Agreed. Header files really kill productivity in C++ projects as they grow beyond 1-500.000 lines. I admit, sometimes I work around or postpone a fix in a vital header file, because I know it will initiate a recompile and undesired wait. I simply don't understand this isn't properly fixed after 30 or so years. It is so inefficient for developer time, cpu resources, and overall energy usage that it becomes ridiculous sometimes. I remember moving from Turbo Pascal in the mid 90s over to C and C++ and wondering what the hell was going on...
  - PaulDavisThe1st 6y ago
    It would involve somehow being able to identify changes that require compilation from those that don't. This is hard to do in C++. At least waf (build system) ignores changes to comments :)

PaulDavisThe1st 6y ago

It does depend on project scale, and what you're doing with it. A full compile of my project on my 2950X (16 core threadripper gen 1) takes 4m20s. If I'm messing around with a new GUI-visible feature, then yes, often it's 1 or 2 files to compile, then a link step (thank you, llc, for parallel linking). Anything can handle that, even if it is C++ :) But if I'm doing a change to the core headers, it typically means multi-minute wait even on the threadripper. And that's something I've been doing for a couple of months now, working on basic architectural changes. The idea of doing such work on machine that took 50-100% longer to do a full build would be a serious problem. I don't see anything on the horizon (yet) that uses Apple silicon that helps that kind of development process.

joakleaf 6y ago
Yes. Agreed. Header files really kill productivity in C++ projects as they grow beyond 1-500.000 lines. I admit, sometimes I work around or postpone a fix in a vital header file, because I know it will initiate a recompile and undesired wait. I simply don't understand this isn't properly fixed after 30 or so years. It is so inefficient for developer time, cpu resources, and overall energy usage that it becomes ridiculous sometimes. I remember moving from Turbo Pascal in the mid 90s over to C and C++ and wondering what the hell was going on...
- PaulDavisThe1st 6y ago
  It would involve somehow being able to identify changes that require compilation from those that don't. This is hard to do in C++. At least waf (build system) ignores changes to comments :)