PyPy Tokyo sprint 23/4 - 29/4 announcement

Hello LLVM,

During this sprint we will also look at using LLVM JIT for our project.
What exactly we will do in Tokyo very much depends on who will attend. So if you are interested please contact me beforehand so we can make sure everyone will have a fun and productive time.

cheers,
Eric van Riet Paap

Tokyo PyPy Sprint: 23rd - 29th April 2006

Developers:

Please visit PR723 http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=723,
read it and cast your vote on whether release 1.7 should default the
configure script to building optimized or whether the status quo (debug
build) should be kept. It is likely that we now have more active users
than active developers and we should respond to that change of
circumstances with the default build configuration.

Reid.

Defaulting to optimized is fine with me. Another potential option that might be even better: we could make CVS default to debug, but releases default to optimized?

-Chris

Reid Spencer wrote:

Developers:

Please visit PR723 http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=723,
read it and cast your vote on whether release 1.7 should default the
configure script to building optimized or whether the status quo (debug
build) should be kept. It is likely that we now have more active users
than active developers and we should respond to that change of
circumstances with the default build configuration.

One consideration to weigh is that a debug build of LLVM provides users with more diagnostic information to submit with bug reports (since many bugs are caught by assertions, which print a readable stack trace). The tradeoff seems to be faster and smaller LLVM tools (optimized build) vs. better diagnostic information for bug reports (debug build).

If the LLVM developers who regularly fix user bugs depend on that information, we should keep it a debug build by default. Otherwise, I think an optimized build would be fine.

-- John T.

Another option is to build an optimized build with assertions on. Do to local demand, I added a build option 'make ENABLE_OPTIMIZED=1 ENABLE_ASSERTIONS=1' that provides this.

-Chris

I think this may be a good compromise. The user base of LLVM still seems to be primarily developers, but it does seem to be expanding. It would be useful to keep assertions on so that we can get valuable feedback from the various types of programs that people are compiling.

-Tanya

How does this compare size and performance wise with a debug build or a
release build?

Andrew

I haven't done any scientific measurements. Here is some educated guessing :slight_smile:

I know that a debug build is about 10x bigger and 10x slower than a release build. Linking also takes about 10x as long with a debug build than it does for a release build.

With assertions on, linking takes virtually the same time as a release build, I would expect it to also be about the same speed as a release build: a WAG would be within 10%.

For the people that requested the optimized+assertions build, the big issue was link-time. Having a huge link time significantly impacted their productivity and they happened to not care about performance for most development. OTOH, not getting assertions was preventing them from finding bugs.

The more I think about it, the more I like a configuration that looks like this:

'llvm --enable-optimized' should always build a release build.

LLVM from CVS should always default to a debug build.

LLVM releases should default to 'release + assertions'.

Thoughts?

-Chris

I think using different settings is generally (and this this case too) a bad idea because it makes things more complicated. All developers know how to build LLVM. Most (new/casual) users expect a certain behaviour and they will judge LLVM on subjective grounds. If linking/performance suffers they will continue looking for whatever gives them that extra bit of performance. People like me that take the time to file bugreport are willing to invest time in LLVM and are most probably also willing to recompile a full-debug LLVM.

New users you want provide the best possible feeling, existing users / developers should type the additional option.
(hmm, are does that sound too much like Apple's philosophy) :slight_smile:

I think using different settings is generally (and this this case too) a bad idea because it makes things more complicated. All developers know how to build LLVM. Most (new/casual) users expect a certain behaviour and they will judge LLVM on subjective grounds. If linking/performance suffers they will continue looking for whatever gives them that extra bit of performance. People like me that take the time to file bugreport are willing to invest time in LLVM and are most probably also willing to recompile a full-debug LLVM.

I agree, but there is a balance here:

Users almost ALWAYS use releases.
Developers almost ALWAYS use CVS.

Also, developers configure a lot more often than users :wink:

-Chris

<snip>

Users almost ALWAYS use releases.
Developers almost ALWAYS use CVS.

Also, developers configure a lot more often than users :wink:

Indeed and maybe the picture is changing anyway. When starting to use LLVM in PyPy there were quiet a few bugs that we came across but it hardly ever happens these days that LLVM dies on me. I do however advice people to always use LLVM CVS because up until now performance made a big difference. That too might not be a big issue anymore after llvm 1.7 is out. (I am starting to rely features such as llvm-config being available).

My vote is optimized for users, Debug/assert for cvs. Performance is a major bullet point. LLVM has developed a broad audience. The standard set for binary distribution should be very very high, should have wide prerelease testing and be 99.9% stable.

As far as assert on for users - we tested/used Java Hotspot almost exclusively with -O2 + assert and saw only minor performance problems, but then again we didn't leave asserts in critical areas.

Cheers,

-- Jim