cheapest/best setup for fast compiles? cloud compiling or personal

>>62222467
Cloud computing has a really dodgy price structure imho. It's a clusterfuck.

100 raspberry pies and then distcc

I just use python for everything. That way I don't need to worry about compile times :^)

>>62222467
if I were you I'd build a workstation without even thinking, but i'm biased towards having everything onsite and not relying more than the absolute necessary on cloud computing/storage

>>62222467
I think a somewhat decent Ryzen or i7 really is fast enough at compiling.

And if it's for development, do cached compiles / "hot" compiler that keeps its shit in memory. Not like you change all files every time.

>>62223403
PS: What language(s) are you even compiling? Various languages have various solutions, most that don't suck will have pretty nice caches / compilers that really shouldn't even be much of a problem on a regular desktop.

Or if you somehow need a full compile, you can leave that to CI which runs side-by-side with you continuing your work, if lights turn red I guess you address it then, but you already will have done some minutes of work while it just did its thing in the background, no need to pay attention "while" it compiles.

> Find a good hosting provider with variable hourly pricing, ideally one where I can have a lot of storage available and scaling CPUs available. This way I can pay less when I'm sitting in vim, and pay more only when it scales up to 64CPUs and I want my builds to complete faster.
If you pay while sitting in vim, something is wrong. You really can do that locally on your hardware, either way.

>>62222626
This is the feeling I get from looking at AWS/etc. pricing. But it seems strange to me. They must have lots of processing power just sitting idle. Processing power that will be obsolete in a few years. I would think prices would be lower.
(also, nice digits)

>>62223098
>>62223114
sensible chuckle

>>62223335
See, from where I'm sitting, I think on-site is worse and I'm trying to avoid it. On-site means I have to worry about power consumption and my power bill, and I have to worry about surge/lightning protection, and I am limited to slower internet, etc. etc. etc. All the things that datacenters have figured out.

>>62223403
Yes, this is for development, not for personal/gentoo-type usage.
And of course you avoid full rebuilds if you can help it. But sometimes you can't avoid it, and I don't like to make too many changes without a full rebuild to make sure that I'm not committing on top of previous mistakes.
I don't think an 8c/16t Ryzen is going to appreciably improve my build times to the point where it makes sense to spend the money. If I'm going to spend money on a build server, I'll happily spend the extra $750 for a 16c/32t threadripper over a 1700.

The issue with a lot of the PC building advice online is that it heavily revolves around gaming. Idiots online will say, "gee wiz, 64GB ram, what a waste. And you don't need all those threads, you need high clocks. OMG, you don't have a graphics card what are you doing!", etc. etc. etc.

I appreciate the replies, all.

>>62223562
may we ask on what is your current hardware, build times and some clue on what are you working with, software wise?

>>62223468
> If you pay while sitting in vim, something is wrong. You really can do that locally on your hardware, either way.
I just worry about the process of keeping my local copy and the build copies in sync... But you're right, that's a solved problem.

> Or if you somehow need a full compile, you can leave that to CI which runs side-by-side with you continuing your work, if lights turn red I guess you address it then, but you already will have done some minutes of work while it just did its thing in the background, no need to pay attention "while" it compiles.
The reason I'm looking into a build server is that I'm doing some embedded work lately and because I'm dealing with real hardware I'm not able to make changes, wait for green checkmarks on unit tests, and then move on to the next issue. I have to build, flash to hardware, test on hardware, and then move on. And so I spend a lot of time waiting for builds to finish.

>>62223718
> current hardware
4-core intel box with hyperthreading, relatively old
> build times
20 to 30 minute for a full rebuild
> what kind of project/software
What I'm recently working on is embedded linux development, openembedded/yocto/etc. But we're getting off topic here, I'm not looking for solutions to slow builds on what I'm working on right now. I've been frustrated by slow build times in the past on other projects, too, and it's gotten to the poit where I'm willing to invest some money into a solution. I'm just looking for advice on which way to go-- cloud based compiling or a dedicated personal box.

Just get a bitmining setup and do your compiling through the graphics cards you loser.

>>62223929
well, on a threadripper build you'd see 3 to 4 times faster build times, putting a long full rebuild at 10m to 7m30s, if you really want to go faster than that I think a cloud based solution would be a lot more cost efficient than building a small cluster inside your home

>>62224050
yeah,... I doubt that this is possible

>>62223562
> But sometimes you can't avoid it
Very, very rarely. As a precaution when you hit a bug that you can't otherwise explain or something, or maybe as part of QA before a publication.

And that could be done by a push to CI.

>I don't think an 8c/16t Ryzen is going to appreciably improve my build times to the point where it makes sense to spend the money.
Why not? Are you using a compiler / build tooling that is ill capable of compiling in parallel?

Also, from my Gentoo type of usage (which is ultimately more software than any of us will ever write), I really wonder what the fuck you ARE compiling that takes so long even on a full compile.

But if it just takes long regardless, honestly, I'd kinda advise to start with a CI server that does the compiles + tests in the background on a git commit while you continue.

>>62223765
>I just worry about the process of keeping my local copy and the build copies in sync... But you're right, that's a solved problem.
Yea, really, use Git with a "local" and a remote "CI server" branch?

You'll know what hash either the local or remote commit had, you'll have the ability to go back to it locally at any time, you'll have control over what you actually push to CI, and so on.

> and because I'm dealing with real hardware I'm not able to make changes, wait for green checkmarks on unit tests
I'm not sure this is a fact. If it's computerized hardware, there must be SOME way to measure if it works correctly.

Even if you made a ROM for a dishwasher or whatever, you could test many things after a build automatically and then just give the green light on the CI at least for that partial coverage.

>>62222467
I've been thinking about clustering a shitload of these: https://shop.udoo.org/usa/x86/udoo-x86-ultra.html

>>62224555
That's probably useless, it's not a common method with the big boys that run compute clouds or anything (and yea, they do their processing power per dollar calculations well).

Pretty sure you're better off just hooking up a few Ryzen, Opterons, i7, Xeons or such.