The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I had one of the early laptops (by Olivetti) with twin floppy drives (no HD). I had the compiler and source code on one floppy, the libraries on another floppy. I had a long commute when I was travelling home for the weekend on the train, about four hours. The battery on the laptop would also last about four hours. I would edit my C++ code using Brief for a while, sometimes most of the trip, but sometimes I would want to test some small change so would have to do a build. A full build took just over three and a bit hours so I would just have time to do some editing, do a full build, run a couple of tests on the results, make TODO notes and shutdown just before the battery packed in, and then get off the train.
I would read a paperback book during the build - sometimes a whole one. Ah, the good old days!
- I would love to change the world, but they won’t give me the source code.
It was less build time than startup time - the app built in under a minute, but the open project dialog took a few minutes to load (pulling a zillion times more data from the DB to build fat models instead of the 3 or 4 columns from a single table needed for the list) followed by the detailed application model taking a few minutes to compute (overly complex model, and because it was time dependent and took a while to stabilize computing way more data than actually shown).
I ended up spending a few months trying to figure out how to build a Binder Clip Star[^] using a poor set of directions (the linked one at least shows which wire goes on the outside at all steps, but is missing anything about how you need to hold it at some steps to keep it from self-destructing halfway through).
Eventually we got out of crunch mode and I was able to look at things that weren't my assigned tasks (no one else cared that performance was a tire dump fire ) and un- ed the startup code, sped the main model calculation up by a factor of ~2x, and changed how it was used to not need computing huge amounts of data beyond the displayed range for something like 5-20x typical improvement; and got the compile to start testing my code changes cycle down to under a minute. It still took the model a few weeks to go from bogus starting values to a fully stable state; my not done before the contract ran out next step would've been to save daily snapshots of the model state in the DB to allow faster startup (saving the displayed per minute values would've exploded its size and ate the disk, so we had to recompute on load) by another factor of 5-10x at which point it wouldn't have any obnoxiously long "did it lock up?" pauses.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
If compile time is an essential part of the build time, then you are making a program.
You are not making a software system composed of sevearal program components merged into a whole.
You are not making a software product with nasty elements such as documentation, test logs, ...
Or, maybe you are, but when you say "build time" you are not talking of building the software system product, but to "build" a linkable unit from a source file. Then you might see compiling filling a noticeable part of the build time. Maybe half a second out of two seconds build time ...
Last time I did a make clean, rebuilt the system from scratch, and inspected the last written timestamp on the compiled files, there were typically six to eight of them completed per second. (And last time I did this little exercise was around ten years ago; we've got faster machines today.)
Using compile time as an argument against compiled languages, in favor of interpreted ones, might have been valid in the 1980s. It is not today.
Besides: Because interpreted languages traditionally had lousy run time performance, all major interpreted languages today start the interpretation by doing an on-the-fly compilation... (if they do not find an already compiled version in a cache). So you don't escape the compile time - you just count it as part of the run time.
First, you should learn to consider that someone might be joking. This is the lounge.
Secondly, when I think build I think of the entire thing. Compile and link.
If you use second-party libraries for much of your source the it will be much quicker than it really should be. Mostly, what I did I built from scratch. An exception to this was the .lib file that came with an A/D converter. For FORTRAN, years ago, I even built a graphics .lib I coded in Assembler. The whole thing, if I did it all at once, would be done in a minute, tops (on an 80286 w/HDD and 1 MB RAM).
Mostly, however, the libraries were compiled once and, with the exception of an occasional addition, left as they were. Compile/link took seconds, usually.
You need to get a grasp on context when commenting in the forum. Not every, and perhaps hardly anything, is taken seriously. Certainly not if there's an opening for a laugh. Maybe that long sunless winter's getting to you?
Well, back when it was Turbo Pascal: Used the bathroom (took a book), got a cup of coffee, chatted up the receptionist (you could do that, then), checked the telex machine, read a bit of Byte magazine and then topped off my coffee again.
Some microcontrollers do not have RTC support or any other kind of timer-like tick coming in so cooperation seems like the best option for them. I seem to remember an article or two here on that topic.
I've also found that introducing multithreading into a system you already can't debug using a traditional debugger is a recipe for a nightmare in practice.
What I've done on this dual core monster I am working with is I keep exactly two threads - each with its own core affinity, and they basically do very little communication with each other, and all of their work is internally cooperatively multitasked.
It doesn't have an RTC per se, but like most CPUs it has a timing crystal connected so you can get the number of milliseconds since boot with it. I use that to make timers.
I have a similar issue. I have a big bunch of code to debug that needs to run on a GPU. I have written it so it can also run on the CPU so I am doing all my initial debugging on the CPU and then I'll try it on the GPU. I have already tried small bits on the GPU and it looks good so far.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"