Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#34540 closed defect (wontfix)

gaul-devel build varies based on number of CPUs

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: Veence (Vincent)
Priority: Normal Milestone:
Component: ports Version: 2.1.1
Keywords: Cc:
Port: gaul-devel

Description

gaul-devel builds itself differently depending on how many CPUs / cores are available. This may result in a non-optimal configuration when a port is built on one computer and installed on a different computer. This is a common situation now that we have a buildbot.

To solve this, you could create variants for all possible values of number of CPUs / cores, and select the appropriate variant based on the current computer.

Change History (6)

comment:1 Changed 12 years ago by Veence (Vincent)

Ryan, If I am not mistaken, what you suggest would result in the buildbot compiling just its hardware configuration, so that all other cases would have to rely on a machine build instead of downloading the Buildbot one… is that correct?

Your remark is also relevant to Atlas… but in this case we would have dozens of variants to manage… Wouldn't it be easier to add a command disabling binary download of the ports whose building and performance are strongly connected to the hardware they’re running on?

comment:2 in reply to:  1 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to vince@…:

If I am not mistaken, what you suggest would result in the buildbot compiling just its hardware configuration, so that all other cases would have to rely on a machine build instead of downloading the Buildbot one… is that correct?

Yes, that's the idea.

Your remark is also relevant to Atlas… but in this case we would have dozens of variants to manage…

Yeah, that would be problematic.

Wouldn't it be easier to add a command disabling binary download of the ports whose building and performance are strongly connected to the hardware they’re running on?

You can already do that by setting archive_sites to empty in a portfile. It doesn't solve the problem of a user manually moving an archive from one machine to another, and it doesn't provide an indication in "port installed" that the build is any different from any other build, but short of variants I'm not sure how to fix those problems.

comment:3 Changed 12 years ago by Veence (Vincent)

Can we warn the user when (s)he opts for a binary download that the version (s)he will install may be suboptimal?

comment:4 Changed 12 years ago by Veence (Vincent)

Resolution: wontfix
Status: newclosed

So what shall we do? Nothing?

comment:5 in reply to:  4 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to vince@…:

Can we warn the user when (s)he opts for a binary download that the version (s)he will install may be suboptimal?

I'm not sure if there's a way to detect that.

Replying to vince@…:

So what shall we do? Nothing?

I just wanted to make sure you were aware of the issue; it's up to you if we should do something about it. I'm not familiar with gaul so I don't know how bad it is if, say, a gaul configured for four processor cores (which seems to be how many cores our buildbots are configured to use) runs on a system with only one or two.

comment:6 Changed 12 years ago by Veence (Vincent)

There is always a trade-off involved with binaries. For example, Qt autodetects the vector units of the processor that performs the compilation. If you happen to compile qt4-mac on an Ivy Bridge machine and install the resulting binary on a Core Duo Mac, you face the risk of crashing due to AVX/SSE4.2 instructions not being supported on the latter (that’s what I do, though, and up to now it has been fine). If you proceed the other way round, you won’t get the performance boost allowed by the new hardware/instructions. Since it is better to lose efficiency than to crash, ideally a binary should be produced on the oldest machine of a given architecture. That’s what plagues all the Window$®™ binary distributions, some of which have to be compatible with old Pentium processors…

Note: See TracTickets for help on using tickets.