Hacker News Reader

Comment by mishmash | Hacker News Reader

Oh man been waiting for this since WWDC. IB integration took way too long.

I do have a question for the compiler geeks, though: how was LLVM able to so quickly surpass GCC in both compiling source and binary performance, considering gcc had a two decade head start?

View on HN

Having been at WWDC and played with it for a few weeks, I'm not sure I'd call LLVM a hands-down winner.

While there's a lot of win in terms of code readibility and the great interfaces it exposes if you're going to write an IDE that understands the code, I'm not convinced it's there yet in terms of binary performance.

My apps run around 5%-15% slower, on average, than the GCC -march= setting.

It may not be a hands-down winner yet, but in the long run it's the way to be headed.

I'm more interested in using LLVM on FreeBSD or Linux than on OS X, but I'm happy to see Apple pushing its development.

Probably because the GCC architecture itself no longer allowed for more optimization. Or to put it another way, it had been optimized as much as economically possible. Trying to optimize it further would get us to the realm of diminishing returns. At this point it is easier and more cost effective to simply re-design the whole architecture which will inherently improve the performance. LLVM was designed from scratch with performance being a top priority.

It has 20 years less baggage and 20 years of lessons learned of what not to do. And 20 years of CPU development, remember that when GCC was started there were no superscalar CPUs.

GCC isn't a particularly high bar to hit ICC and MSVC have been killing it for years.

It's largely the same reason that the ZFS codebase is drastically smaller than the UFS codebase. You don't think of the fastest / shortest way to do X the first time.

Not all the code works with LLVM, for example if you use LLVM to compile the linux kernel it won't boot.

Linux and GCC(GNU) have had a special relationship for a long time. It might be a while until LLVM can handle that task.

FreeBSD however will actually compile and boot. http://wiki.freebsd.org/BuildingFreeBSDWithClang . It's not completely foolproof yet. I think the BSD community has welcomed LLVM a little more warmly than GNU/Linux.

Part of this is probably that philosophically the *BSDs don't really want to be reliant on GNU tools.

The OpenBSD folks have been searching for a replacement for quite some time now. IIRC, they even got their kernel building with the ancient PCC compiler, which is also BSD licensed.

interesting. is that only due to the different licenses used in the two projects?

Apple wants to use the actual compiler code in XCode and that wouldn't be possible with GPL and their current license. That is also why clang is structured as libraries.

It's one of the main ones, but two additional ones, depending on the person, are: 1) some people don't like GNU and/or Stallman having influence on their OS, either for political reasons or due to personality clashes; and 2) some people don't like GCC's design as a technical matter.

Thats what I was implying in my earlier comment. Though I wouldn't say its the only reason, in my view as an advocate of the BSD License, it's a major reason.

To be fair Linux has always been designed and written with GCC in mind. I don't think portability (between compilers) has ever been a goal.

This is really interesting, Fabrice Bellard's tcc is able to build and boot a Linux kernel.

http://bellard.org/tcc/

I'd say it's both better design from the ground-up (coming from a better understanding of compilers) and financial support.

It actually hasn't. LLVM is consistently slower in most benchmarks. Not by a large amount, but it doesn't beat GCC for speed.

The thing is that most compilers these days are limited by the performance of the CPU itself, as they're getting within a few percent of the best you can do.

I can't imagine anyone actualy using IB, at last for anything but the most basic app. It just frustrates me no end, and I am pretty sure most people just create all the elements programmatically.

Since Cocoa programming on the Mac, sometimes in the cocoa-dev list the question "how do I design interfaces in code instead of using IB?" popped up, and the general consensus was always: "why do you want to do that? You are fighting against the environment. Use IB".

I've tried designing UIs without IB. I went thorough years of mailing list archives, several questions on StackOverflow and I don't know how many blog posts. Trust me, writing an app without IB is a stupid, stupid idea. IB is central to Cocoa development.

I guess not.

Not seeing the problem with IB here. I use it extensively for generic UI elements, with custom views and windows, use it to target the FirstResponder, use it to hook up actions, connect controllers, and to bind objects together - all of things IB (and now Xcode 4) were made to handle.

I am curious as to what you don't like abou it?

Where should I begin?

- It's incredibly brittle. Good luck if you need to make significant changes to your hierarchy, or change that NSOutlineView of yours to an NSTableView. You'll have to rebuild and re-hook up all of the connections on an object. With no warnings or errors if anything is wrong. In HTML, you can just copy and paste, change some tags, and make some adjustments. Now HTML isn't ideal for application layout - but another markup language could be (MXML isn't bad).

- Doesn't play well with source control. Only one user can work on a .nib at once. Just yesterday another programmer and I both made changes to UI. Of course, it was completely unmergeable by machine or by hand - what do you expect when you have GUI generating a 7000-line file for relatively simple UI. So one of us had to re-do several hours of work. This isn't a problem with, say, HTML.

- Most significantly, it only solves a small part of the problem. It completely falls down when you're dealing with dynamic / variable UI - you'll have to resort to code anyway. And a lot of the layout you need to do is actually inside cells - say, trying to build a source list like iTunes, or a table view with icons inside of it. IB can't help here at all. Then, you end up laying out the actual UI in code. And what code it is:

NSDivideRect(cellFrame, &imageFrame, &textFrame, ICON_INSET_HORIZ + ICON_TEXT_SPACING + imageSize.width, NSMinXEdge); imageFrame.origin.x += ICON_INSET_HORIZ; imageFrame.size = imageSize;

		textFrame.size.width -= ([self sizeOfBadge].width + ROW_RIGHT_MARGIN);

Are you serious? This is 2010. You should not need to be manually calculating the positions of UI elements. There should be a layout language. HTML, MXML, whatever.

IB encourages you to use a very low level of abstraction. There's a lot of repetition, and the closed nature of the tool means it's very difficult to build up higher levels of abstraction. But then again, I guess Objective-C loves loves making programmers repeat themselves.

There's a reason most professionals don't use dreamweaver to make websites, either. And they are much the same.

Reply on news.ycombinator.com