2. try but most is said, just clarifying

Article: Computational Efficiency in Modern Processors
By: Michael S (already5chosen.delete@this.yahoo.com), November 15, 2009 1:58 am
Room: Moderated Discussions
Gabriele Svelto (gabriele.svelto@gmail.com) on 11/14/09 wrote:
---------------------------
>Michael S (already5chosen@yahoo.com) on 11/14/09 wrote:
>---------------------------
>>For me it's not even a link step which is most irritating but a make itself. Gnu
>>make under cygwin absolutely horribly sucks!
>>The one think I can not understand is how it manages to suck about equally on 3GHz
>>Prescott with regular SATA drive and on 2.66 GHz Nehalem with two SATAs in RAID-0.
>
>It's certainly because of fork() and friends. The implementation is incredibly
>inefficient, unfortunately it's the only way to do it on Windows and GNU/make makes
>plenty use of those calls.

I don't believe fork() has anything to do with it.
To be clear, I am talking about slowness in the case where nothing or almost nothing has to be recompiled. So I'd expect that the only forks executed are forks of make itself for recursive processing of directories. So, since there are less than 20 directories there would be less than 20 forks. As slow as they are 20 forks can't take several seconds.

> Wouldn't it be worth to give a try with virtualization?

No, it would not.
The main task of computer in question is fpga development. Software compilation is secondary. If virtualization slows down the primary task by mere 5% it's already prohibitive.
Besides, even on the software side make that ends up doing almost nothing is a most common use case but not the only one. Sometimes we recompile the whole project or major parts of it. In this situation Nehalem's 8 hardware threads simply rock.
And that's just a theory. In practice we have a couple of more serious problems:
1. No common windows/Linux source control infrastructure. And no, I don't consider sharing directories with windows a proper solution.
2. Developers that are afraid of Linux desktop.
Both problems are soluble and the first one hopefully will be solved pretty soon but right now that is the case.

>I'm currently using a Debian installation under VirtualBox which shares a few directories
>with my Windows installation so that it can work on them. With only one core of
>this system (very similar to yours) assigned to the VM it *flies* past Cygwin.
>



>>I don't know whether VS2005 uses classic make for build management or some less
>>generic technology but somehow it manages to work more than order of magnitude faster than gnu make under cygwin.
>
>Yet I am bemused by the inherent sluggishness of VS2005 (& 2008) on a Nehalem system.
>A full build under Linux of a project of similar size is significantly faster. I
>wonder if I have mis-configured something.

It seems we are talking about different things.
I am talking about how much time it takes to the tool to figure out what to do and to start actual compilation. I want the case of 0,1,2 files recompiled to be very fast and am willing to accept relatively slow build in hopefully rare case of recompilation of 100s of modules.
You, on the other hand, seem to be concerned with the total compilation time in the case when rather heavy recompile is indeed required.
In the later case VS2005 one-thread-per-project approach is, indeed, sub-optimal, especially for "debug" builds.

BTW, I didn't try VS2005 on Nehalem yet. I do hear similar claims from co-workers, i.e. Nehalem measurably slower than C2D.
< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
Article: Computational Efficiency in Modern Processors by DKMoTheG2009/11/08 07:02 AM
  Article: Computational Efficiency in Modern Processors by DKnone2009/11/08 07:15 AM
  Silverthorne and OoO vs. InOrdMoTheG2009/11/08 07:22 AM
    Silverthorne and OoO vs. InOrdDavid Kanter2009/11/08 04:11 PM
      Magical 100x speedupsAM2009/11/09 09:03 AM
        Magical 100x speedupsDavid Kanter2009/11/09 12:41 PM
          Magical 100x speedupsnone2009/11/09 01:36 PM
            Magical speedupsDavid Kanter2009/11/09 03:24 PM
              Magical speedupsnone2009/11/09 03:40 PM
              Hardware SpecsMS2009/11/09 05:49 PM
                44x faster than a single cpu coreVincent Diepeveen2009/11/10 08:17 AM
              Magical speedupsVincent Diepeveen2009/11/10 08:02 AM
          Xeon 130x speedup vs XeonEric Bron2009/11/10 08:20 AM
          Magical 100x speedupsAM2009/11/10 10:42 AM
            Magical 100x speedupsLinus Torvalds2009/11/10 01:19 PM
              Mega speedupsAM2009/11/11 06:21 AM
        Bogus 100x speedupsDavid Kanter2009/11/10 01:26 AM
          No speedups for CPUs for the general programming populaceMoTheG2009/11/10 05:26 AM
          Bogus 100x speedups?2009/11/10 05:45 AM
          Bogus 100x speedupshobold2009/11/10 07:31 AM
          Bogus 100x speedupsVincent Diepeveen2009/11/10 08:26 AM
          Bogus 100x speedupssylt2009/11/10 10:00 AM
          Bogus 100x speedupsAM2009/11/10 10:47 AM
      GPU vs. CPUMoTheG2009/11/09 11:30 AM
        GPU vs. CPUa reader2009/11/09 07:58 PM
          ease of programmingMoTheG2009/11/09 11:45 PM
            yes for GPU programming you need non-public infoVincent Diepeveen2009/11/10 08:36 AM
              yes for GPU programming you need non-public infoPotatoswatter2009/11/11 08:06 AM
                yes for GPU programming you need non-public infoVincent Diepeveen2009/11/11 11:23 AM
                  yes for GPU programming you need non-public infoPotatoswatter2009/11/11 01:26 PM
                  Real businesses use GPGPU.Jouni Osmala2009/11/11 11:00 PM
        GPU vs. CPU?2009/11/10 06:01 AM
          2. try but most is said, just clarifyingMoTheG2009/11/10 10:24 AM
            2. try but most is said, just clarifying?2009/11/11 01:11 AM
              you missread meMoTheG2009/11/12 12:33 AM
                you missread me?2009/11/12 01:18 AM
            2. try but most is said, just clarifyingPotatoswatter2009/11/11 08:22 AM
              2. try but most is said, just clarifying?2009/11/12 01:22 AM
                loose, not so orderlyMoTheG2009/11/12 12:47 PM
                  loose, not so orderlyPotatoswatter2009/11/12 06:50 PM
                2. try but most is said, just clarifyingrwessel2009/11/12 01:01 PM
                  2. try but most is said, just clarifyingGabriele Svelto2009/11/13 12:39 AM
                    2. try but most is said, just clarifying?2009/11/13 01:14 AM
                      2. try but most is said, just clarifyingGabriele Svelto2009/11/13 01:30 AM
                      2. try but most is said, just clarifyingrwessel2009/11/13 01:24 PM
                  2. try but most is said, just clarifyingMichael S2009/11/14 01:08 PM
                    2. try but most is said, just clarifyingGabriele Svelto2009/11/14 11:38 PM
                      2. try but most is said, just clarifyingAndi Kleen2009/11/15 01:19 AM
                      2. try but most is said, just clarifyingMichael S2009/11/15 01:58 AM
                        2. try but most is said, just clarifyingEric Bron2009/11/15 02:25 AM
                          /MP optionEric Bron2009/11/15 02:33 AM
                            /MP optionPaul2009/11/15 09:42 AM
                              /MP optionEric Bron2009/11/15 01:22 PM
                        2. try but most is said, just clarifying?2009/11/15 03:13 AM
                          2. try but most is said, just clarifyingMichael S2009/11/15 05:14 AM
                  2. try but most is said, just clarifyingEugene Nalimov2009/11/14 09:24 PM
    Atom pointAM2009/11/09 09:00 AM
      Atom TDPDavid Kanter2009/11/09 12:48 PM
        Atom TDPhobold2009/11/10 07:41 AM
        Atom TDPAM2009/11/10 10:49 AM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell avocado?