Hacker News new | past | comments | ask | show | jobs | submit login

I work in embedded. When I told my boss I was leaving he asked what the other company was offering me - compiler licenses. Without enough each firmware build took 40-60 minutes. With enough, 10 minutes.



hey! would love to hear your experience about this. we’re building a system that should help alleviate this pain when developing embedded systems. emails / cal link are within my person site on bio!


We were using a CPU core vendor's compiler with flexlm licensing(well, Edison Design Group frontend and proprietary backend). We kept using it for ages because it regularly beat GCC due to some issues in GCC with register allocation and instruction reordering that only microchip seems to have ever fixed.

A traditional makefile like setup would only build one compilation unit per compiler invocation.

Each compiler invocation requires a license checkout over TCP. This was badly impacted by Nagling and delayed ACK. The license server was not managed by engineering rather the IT department so we were unable to get them to enable TCP_NODELAY.

Multiprocess scaling was challenging - you could give the compiler multiple compilation units, but sometimes doing so would effect the order of things in the object file, now you lose reproducible builds. These seemed to always be minor things that didn't significantly effect the executable, but rarely you'd crash the compiler and all its jobs would need restarted on the next rebuild.

For those of us batching our compiler invocations for local development builds, the last straw came when an ops team unfamiliar with the tools was put in charge of license management. They started kicking out license checkouts beyond a few seconds in the name of fairness. Build times increased further, but license checkouts per second went up so they thought they were helping.

Eventually I realized it wasn't the 1970s anymore and since I no longer smoke I was bored out of my skull just waiting for timesharing computer to compute again.

Several teams did move to GCC when it got bad enough - hand tuning loops and such when needed.

Probably shouldn't've had so much code in headers - APIs had a lot of dependencies and when I needed to change CompanyName.h, I was in for a few 90%+ rebuilds.

It was a combination of: not my problem, nobody's problem, I got mine, codebase is already like that, death by a thousand cuts, we've never better so how can you say this is bad, network latency.


It’s crazy that in 2024 we are still struggling with the kinds of things highlighted in your comment. Almost all are self-imposed pain, too.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: