241–250 of 509 posts
Earlier quoted context omitted.
Have you worked with Firefox? How does the build compare?
AFAIR, the full build was also around 30 minutes on a desktop i7. Unfortunately, incremental build (even for the most tiny changes) was around 2-3 minutes which was a real killer for me when I tried to do some open source work on it.
Earlier quoted context omitted.
> Damn, are we doing this wrong? Yes, and I mean "we" as in "this industry". I just recently talked to someone whose Swift framework(s) were compiling at roughly 16 lines per second. Spurred on by Jonathan Blow's musings on compile times for Jai[1], I started tinkering with tcc a little. It compiled a generated 200KLOC file (lots of small functions) in around 200 ms. Then there are Smalltalk and Lisp systems that are…
Bjarne's made the mistake of having C++ rely on C's linker model, so it meant no modules. Now we can see it as a big mistake, but on those days probably it was one of the reasons why C++'s adoption took off. Also while C lacked modules, most Algol and PL/I derived languages supported them since the late 60's. Swift's case has the issue of mixing type inference with subtyping, so lots of time is spent there. All in al…
> Now we can see it as a big mistake, but on those days probably it was one of the reasons why C++'s adoption took off.
No mistake, just no choice - the original (1986 or so) C++ cfront compiled C++ to C which it fed to the C compiler and linker chain.
Earlier quoted context omitted.
> Damn, are we doing this wrong? Yes, and I mean "we" as in "this industry". I just recently talked to someone whose Swift framework(s) were compiling at roughly 16 lines per second. Spurred on by Jonathan Blow's musings on compile times for Jai[1], I started tinkering with tcc a little. It compiled a generated 200KLOC file (lots of small functions) in around 200 ms. Then there are Smalltalk and Lisp systems that are…
Bjarne's made the mistake of having C++ rely on C's linker model, so it meant no modules. Now we can see it as a big mistake, but on those days probably it was one of the reasons why C++'s adoption took off. Also while C lacked modules, most Algol and PL/I derived languages supported them since the late 60's. Swift's case has the issue of mixing type inference with subtyping, so lots of time is spent there. All in al…
Earlier quoted context omitted.
Ah yes, I remember that rule, I think it's incredibly clever. I believe he had another rule, language updates can only /strip/ features, so the core language will always get smaller and smaller. Brilliant
Intuitively, that doesn't seem clever to me. (You're committing yourself to a less efficient, more clumsy language for the benefit of... what exactly?) How does that law improve the language without falling into the trap mentioned elsewhere in this thread? (Optimizing for a pleasant "compile experience" at the cost of everything else)
The justification, then, seems to be that if you legitimately need new features, then the language has failed and you should start over anyway. I think Python 3 is sort of an offshoot of this idea, except that many of the new features keep getting backported to 2.7 anyway.
This is great work. I hope MS can improve Windows 10 by fixing this. I just added a new Win10 laptop with much better specs than my 3 year old rMBP, and I'm shocked by how much apparently random latency I experience with the UI in Windows 10 compared to the Mac. That's not to mention the issues of sloppier track pad (which constantly detects my left hand while I type) or the ungodly slow unzip (via 7z). If only Apple…
I mean the trackpad issue is generally down to the manufacturer and the drivers they provide, but I take your point otherwise. A pro tip with 7z is to use the two pane interface to extract and not dragging files to Explorer. The latter option extracts the files to a temp directory before copying them whereas the former extracts directly to the destination. The Windows file systems are pretty cruddy in general though…
Was just wondering this myself. I tried a Surface Laptop this week, and its trackpad has everything I love from the 2012-era Mac trackpads. A satisfyingly snappy physical mouse click, gestures & acceleration, and a perfect size. (I can't stand Force Touch on the new MacBook Pro, and I don't like their new giant trackpads.)
Earlier quoted context omitted.
Have you worked with Firefox? How does the build compare?
Firefox is C and Rust, so I’m not sure there’s such a direct comparison.
Earlier quoted context omitted.
> Damn, are we doing this wrong? Yes, and I mean "we" as in "this industry". I just recently talked to someone whose Swift framework(s) were compiling at roughly 16 lines per second. Spurred on by Jonathan Blow's musings on compile times for Jai[1], I started tinkering with tcc a little. It compiled a generated 200KLOC file (lots of small functions) in around 200 ms. Then there are Smalltalk and Lisp systems that are…
Go is a good example of a language with fast compilation times. Of course, the optimizer needs improvements, but I believe they keep managing to make it faster as they improve the output rather than slower.
They're slowly improving it to return to pre-1.5 performance, but last I checked, it wasn't there yet. The impact is insignificant on small projects, of course, but easily felt on larger (100Kloc+) ones.
While the recent optimizer improvements are great, my wish is for Go to switch to an architecture that uses LLVM as the backend, in order to leverage that project's considerable optimizer and code generator work. I don't know if this would be possible while at the same time retaining the current compilation speed, however.
While the issue closing processes slowly is unique to Windows 10, I've found similar situations of not being able to control my OS on RHEL, Fedora, Ubuntu and MacOS. At this point I genuinely believe latency will be the death of general purpose computing. iOS and Android very rarely get out of control. Apple is already pushing iOS devices as laptop replacements. But we lose a lot on these devices with their locked do…
Full disclosure: I work for Google on Chrome. A Chrome build is truly a computational load to be reckoned with. Without the distributed build, a from-scratch build of Chrome will take at least 30 minutes on a Macbook Pro--maybe an hour(!). TBH I don't remember toughing out a full build without resorting to goma. Even on a hefty workstation, a full build is a go-for-lunch kind of interruption. It will absolutely own a…
I think the best summary of how to do this is to take a look at Herb Sutter's three article set on "Minimizing Compile-Time Dependencies". https://herbsutter.com/gotw/ "The Compilation Firewall", or pimpl idiom, is a clever mechanism for getting code out of the header: https://herbsutter.com/gotw/_100/
I use this liberally. Generally, it is a runtime performance issue only on repeated allocations for which you can optimize if needed. Once-only allocations can be ignored when using compiler firewalls.