Veikkaan että make:ssa ei ole mitään keinotekoista rajaa (en jaksa etsiä sorsista). Jonkun pointterin perässä ne threadit on, että sen pointterin bittisyys määrittää maksimin, jos se on yli 16bit pointteri niin ihan varmana leviää kerneli/scheduleri käsiin. Tosin ennen lie tulee reaaliongelmaksi ongelmaksi löytää kone jossa on niin paljon coreja, että se pointteri loppuu kesken (pois lukien tuo 16bit tapaus jossa usignedilläkin "vain" 65+k corea riittää).
Ei käytännössä missään ole mitään 16-bittisiä pointtereita enää. Pointterit on 64-bittisiä 64-bittisessä käyttiksessä. Tarkoittanet jotain muuta kuin pointteria puhuessasi pointterista.
Koodin kääntäminen toki on myös kivasti rinnakkaistuva ongelma, ei tarvi tehdä keinotekoisia rajoja. Pelimoottorissa voi hyvinkin tarvita, mutta sen ny voi koodailla silti niin ettei se kosahda ympäri jos on liian monta corea.
Koodin kääntämisen rinnakkaistus on itseasiassa monimutkaisempi juttu, kuin mitä triviaalisti luulisi.
Tyypillisessä makefileessä käännellään ensin kooditiedostot objektitiedostoiksi, ja sen jälkeen ne linkataan yhteen.
Ja käytännössä tuo linkkaus on täysin yhdessä prosessissa ja säikeessä ajettava ei-rinnakkaistumaton asia, jonka voi tehdä vasta kun kaikki kooditiedostot on ensin käännetty.
Eli, meillä on kaksi eri työvaihetta, toinen rinnakkaistuu (melkein) kooditiedostojen määrän verran, toinen ei yhtään.
Ja perinteinen make tyypillisesti oletuksena ajetaan yhdelle hakemistolle kerrallaan, ja se sitten kutsuu rekursiivisesti alihakemistoille makea, mutta kerralla siis käännetään vain yhtä hakemistoa.
Jos koodi on sijoiteltu suureen määrän hakemistoja joissa jokaisessa on melko pieni määrä kooditiedostoja, rinnakkaistus ei ole kovin hyvää.
Eli pitäisi myös rinnakkaistaa eri hakemistojen kääntäminen rinnakkain, että saisi rinnakkaisuutta tarpeeksi, mutta koska niitä kutsutaan normaalisti rekursiivisesti, säikeiden määrää olisi silloin vaikea rajoittaa, ja riskinä olisi helposti laukoa eksponentiaalinen määrä säikeitä hakemistorakenteen hierarkian syvyyteen nähden. (minkä takia se make ei siis tee tätä oletuksena)
Eli käytännössä jos halutaan hyvin rinnakkaistuvaa kääntösysteemiä, pitääkin se ehkä tehdä jollain muulla kuin makella, tai vähintään käyttää makea hyvin eri tavalla kuin miten sitä on perinteisesti totuttu käyttämään.
Lisäksi erityisesti melko oliopohjaisessa C++-koodissa (ainakin jos siinä käytetään paljon esim. templateja) tulee vastaan helposti sellainen ongelma, että suuurin osa kääntöajasta ei itse asiassa usein kulu varsinaiseen koodin kääntämiseen, vaan siihen, että preprosessori parsii headeita, kun koodi inkludoi vaikka mitä jotka taas ne inkludoivat vaikka mitä, jotka inkludoivat vaikka mitä, ja tämä headerien parsiminen vie saman määrän aikaa, olisi varsinainen koodi hyvin lyhyt tai hyvin pitkä. Tämä tarkoittaa sitä, että jos halutaan vähentää tähän kuluvaa turhaa työtä, kannattaakin samaan kooditiedostoon laittaa mahdollisimman paljon koodia, ja minimoida kooditiedostojen määrä - mikä taas on rinnakkaistamisen kannalta huono.
Isot softaprojektit ovat kyllä usein optimoineet koodin sijoitteluaan tiedostoihin ja kääntöjärjestelmiään aika paljonkin, jotta aikaa ei kulu turhiin headerien parsimisiin, mutta silti saadaan hyödynnettyä paljon rinnakkaisuutta, jotta ne kääntyvät siedettävän nopeasti ja hyötyvät suuresta määrästä ytimiä - mutta sen tekemiseen on jouduttu näkemään paljon vaivaa.
