Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Programming IT Technology

Distributed Compilation 29

BagOBones writes "Tired of waiting for your source to compile? Dreaming of having your own cluster and having something useful to do with it? Well Trolltech might have the answer. Trolltech Teambuilder lets you turn your network into a clustered C/C++ compiler."
This discussion has been archived. No new comments can be posted.

Distributed Compilation

Comments Filter:
  • by ObviousGuy ( 578567 ) <ObviousGuy@hotmail.com> on Thursday June 06, 2002 @10:54PM (#3657410) Homepage Journal
    But isn't the point of having subscriptions to avoid advertisements? [trolltech.com]

    That said, I've certainly worked on products that needed at least 3 hours to build an entire tree. These builds were done regularly around 3 in the morning so that the daily drop was available to QA first thing in the morning. It wasn't really necessary to farm out the compilation across machines because it wasn't a big deal to maximize speed.

    As for developers' machines, it wasn't like every change was accompanied by a full build. You recompile the files that changed and link the object files together. Any smart build system should be able to handle this type of logic. Such a local build would take about 2 or 3 minutes (if that. This time could be made even shorter by using dlls instead of a single binary). I guess this Trolltech system could reduce this wait even further, but I'm not sure I see the point.

    When else are you going to refill your coffee?
    • As for developers' machines, it wasn't like every change was accompanied by a full build. You recompile the files that changed and link the object files together.

      Sure. OTOH, the project I work on has well over a million lines of C++ code in it, about five developers full time, and a pretty tidy OO design is used to model much of our stuff. If you're playing with a new feature, this quite often goes into a base class to add it across a whole range of areas of the code, and changing the wrong header file can cause a good 10-15 minutes of rebuild (the whole project on a fast machine takes ~1hr). It's the sort of thing that's not normally a problem, but if you do it 10 times in a day while trying to fix that nagging bug, and you're shipping within the week so time is of the essence, then this sort of functionality is priceless. I guess the kind of team where I work is (aside from developing under Windoze) exactly the sort of place they're targetting. To our clients paying a significant sum of money per hour for our time, the $750 to save several hours at crunch time is nothing.

      (And before anyone mentions it, yes, I'm aware of the Cheshire Cat idiom and such, thanks. They aren't in common use on the project, which dates from several years ago, and retrofitting them would be difficult to do without a lot of risk. It's cheaper and safer to just speed up build resources, by using faster PCs or something like the product in question here.)

  • Ack... (Score:2, Interesting)

    by drgnvale ( 525787 )
    Maybe its just me, but $750 for a farm size of 5 seems kinda pricey for a few moments saved here and there. At my job, we have pretty speedy machines, and almost nothing we have built has taken more than 10 min for a complete recompile. And since you rarely recompile everything, its usually a couple seconds to a minute to compile your changes. I can't imagine that this would speed that up enough to justify the price.
    • I agree the price seems high.. It was the whole clustering thing that got me interested.

      Hay if you want to compile KDE from source it could come in handy.
    • Yeah, this is the problem I see with the Trolltech guys. I mean, I love Qt and wish it would get a heck of a lot more market penetration, but until they finally make their prices reasonable it'll never happen. Look at Qt itself as an example. Even though it's extremely well designed, allows cross platform, and would make Windows developers' lives easier by replacing MFC, it's not worth $1,550. I mean, as much as I'm biased towards it, it's a toolkit and a sorta IDE. I think they'd sell a lot more licenses for stuff in the end if they'd look around and make their prices more competitive.
      • Re:Ack... (Score:2, Insightful)

        by Anonymous Coward
        I doubt dropping the price would make any sense. It doesn't seem likely that halving the price would double the volume: $775 is still not something a hobbiest would spend, and most companies who feel they need something like Qt won't be affected by saving $775 anyway.
        • Re:Ack... (Score:2, Interesting)

          by drgnvale ( 525787 )
          The biggest problem with Qt that we have at my job is that the cost is per developer, it cost more to get licenses for multiple platforms, which kinda was the point of it anyway, and the faq used to say you couldn't develop with the free edition and then get licenses before you release. Which stinks if you want to see if your product is doable in Qt before you shell out the cash for your development team to start working.
  • Why not dmake? (Score:5, Insightful)

    by wickidpisa ( 41827 ) on Thursday June 06, 2002 @11:20PM (#3657500) Homepage
    What does this package have that makes it any better than dmake(distributed make)? Convincing anyone that uses linux to go with a $750 product over an open source one seems silly, if they were going to do that they wouldn't be using linux in the first place.
  • by Tablizer ( 95088 ) on Friday June 07, 2002 @12:22AM (#3657770) Journal
    use an interpreter. (Okay, it is not new. I lied.)

    BTW, is there "lint"-like utilities for any scripting/interpreted languages that detects "suspicious" stuff before running?

    This may help one get the best of both worlds.

    I personally prefer interpreted languages. They are usually easier to read IMO because there is less formality in the way.

    Interpreted languages attempt to reduce problems by making the view clearer, while compiled languages attempt reduce problems by using a fatter air-bag.

    It is sort of like chosing between a fighter plane that is highly menueverable by being light, or one that is heavily armored. They are both different strategies to the same goal. The choice often depends on the pilot and training.
    • Well, there are obviously fewer things that untrusted input can break in an interpreted language (no buffer overflows for one).

      I don't know if that's what you have in mind, but at least Python's exec() and eval() allow for namespace definition (i.e. only let the exec/eval'ed code to have access to a portion of the variable namespace.
  • ccache (Score:4, Interesting)

    by ryants ( 310088 ) on Friday June 07, 2002 @01:23AM (#3657940)
    A similar idea that I've been playing around with and seems to work is to use ccache [samba.org] and put the cache on a network drive.

    That way, if someone has already built the file you're about to build, it's just a copy. Even better is if you have a continous build script caching results ahead of time for you.

    It has worked pretty well for me so far.

    • Re:ccache (Score:3, Informative)

      by elmartinos ( 228710 )
      ccache is pretty good, but not especially made for distributed compilation, but there is another project at samba.org:
      distcc [samba.org].

      /elmartinos

  • Mosix? (Score:2, Interesting)

    by intu ( 201998 )
    What about {open}Mosix cluster?

    http://www.mosix.org/
    http://openmosix.sourcefo rge.net/
  • free with PVMGmake (Score:5, Informative)

    by bohnsack ( 2301 ) on Friday June 07, 2002 @07:56AM (#3658688)
    You can do this for free with PVMGmake. I have a HOWTO [x-cat.org]
  • distcc (Score:2, Informative)

    by Anonymous Coward
    check out distcc [samba.org] while you're at it. from Martin Pool [advogato.org].
  • by Henry V .009 ( 518000 ) on Friday June 07, 2002 @11:03AM (#3659609) Journal
    Program compilation is not an obvious candidate for parallelization because it is an extremely memory intensive process. So to do this right you'd need very fast communication between your CPUs.

    However, what Trolltech is probably doing, is farming out the independant bits of your program that you would link together in the end anyway. That might really help on rebuilding the entire project at once. However, if your program is set up well, you usually only need to recompile one file at a time.

    So the times when you could see the biggest speed up in compilation, you will need this least.
    • In my case, compilation is a big issue. I may be unique in porting code from an obsolete C++ compiler to another, but I have to go through 4000+ C/C++ files. There is lots of independent libraries that could be built concurrently.
      A build for one platform takes 2-3 hours, which I unfortunately have to test.

    • Sure, if you modify one .cc (or .cpp) file at a time, you will only compile one file. And if you keep your sources short and your headers organised it wont take long anyway. But what if you modify a header file? In a library used by the whole application?

      While I was working over summer, we regularly made changes to a core IDL file (hey, I wasn't the guy who put all the system interfaces in one file!) resulting in a 4-hour coffee-break on a decent PC And this was just the system layer and GUI. To rebuild everything (including embedded code for various modules) would take 12 hours or more.

      Sure you may not recompile everything very often - but imagine what the 12 hours (or 4 hours) would be like if you used the 100 developers PCs on that floor alone. Of course, at some point - probably well before 100 - the cost of organising the distributed compile and transferring files around starts to negate the benefits.

      How many full builds do *you* make before each release, when it can take months from initial feature freeze to release? How much will it affect your shipping date? (and how many $$ in wages are you paying people for those hour long coffee breaks all the time?:)
  • You can do distributed builds with ClearCase (I remember doing this a few years back on Digital UNIX). Quite easy to do really. Quite expensive for cleacase licenses (oh yeah, and DEC compiler licenses...)

    Steve.

THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE

Working...