331–340 of 509 posts
Saw the headline and thought "must be Windows". I'm not a Windows hater, but one of my long standing gripes about Windows is that it just seems to have terrible multitasking compared to OSX. I'm sure there are reasons but it just seems utterly symbolic of Microsoft that they never managed to get Windows to multitask in a rock solid, smooth and reliable way like OSX.
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…
Are you serious? You want to make a product: a Web browser. What technology are you going to choose? The one that makes your browser fast but gives you more work, or the one that makes your browser slower but makes compilation less of a nuisance to you ? It's mind boggling that some would openly say that, hey, who cares about performance that much, these compilation times bother me, the developer. On a browser of all…
Earlier quoted context omitted.
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.
Go's compilation times are fast, but it also took a significant dive in 1.5, when they rewrote the compiler in Go. 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 tha…
Go being bootstrapped is a good argument against people that don't belive it is suitable for systems programming.
Depending on C or C++ as implementation always gives arguments it could not have been done differently.
Also we should not turn our FOSS compilers into a LLVM monoculture.
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…
> How did we get here? Well, C++ and its stupid O(n^2) compilation complexity [...] Wasn't large compilation time a driving force behind coming up with Go? Is a garbage-collected language not suitable for a web browser? I am just curious because I absolutely love writing Go
yes, that was one of the tenants.
> Is a garbage-collected language not suitable for a web browser?
In theory its fine; but there's a lot of historical baggage that comes along with garbage collection and the majority of languages that support it (e.g. almost no value types).
Golang fairs pretty well latency wise for a GC'd language. I'd be curious for someone with more experience than me to talk through a deep dive of instances where go's latency/throughput characteristics are and are not good enough for specific applications.
Earlier quoted context omitted.
> "but on those days probably it was one of the reasons why C++'s adoption took off." I know "Design and Evolution of C++" quite well, and have been a C++ user since Turbo C++ 1.0 for MS-DOS.
Sure, but it wasn't a "mistake". Stroustrup absolutely wanted a C with classes, and that meant tight integration with C toolchains. Symbol mangling was the clever idea invented to implement that very deliberate choice, not a fortuitous happenstance.
Stroustrup made the decision on purpose and consciously, but it turned out to have disastrous effects.
Earlier quoted context omitted.
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)
Well, the rule is attributed to Niklaus Wirth, whose credits include Modula, Modula-2, Oberon, Oberon-2, and Oberon-7. The -* languages are extensions of their originals, so it seems his rule only applies within a single edition of the language. They can add new things, because they are new languages. The justification, then, seems to be that if you legitimately need new features, then the language has failed and you…
There is also Active Oberon and Component Pascal, but he wasn't directly involved.
Earlier quoted context omitted.
I've given up on C++ 5 years ago, after 10 years of getting paid to develop it. I find out the extra money that come from a C++ job doesn't cover the gray hairs of trying to tame the language so you don't shoot yourself in the foot a dozen times every time you call a method.
Do C++ developer have more salary?
Fintech, HPC, aeronautics, robotics, infotainment,....
The only industry where devs are badly paid is games industry, but that is common to all languages.
Earlier quoted context omitted.
Go's compilation times are fast, but it also took a significant dive in 1.5, when they rewrote the compiler in Go. 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 tha…
The important point about Go in this case is that it's fundamentally more efficient because it has real modules and can do incremental compilation. Sometimes people don't realize this because they always use `go build` which, as the result of a design flaw, discards the incremental objects. When you use `go install` (or `go build -i`) each subsequent build is super fast.
Can take the alternate approach - Run your builds in a hugely underpowered VM, and wait much longer.. your regular usage will be largely unimpacted, although the builds take longer. Source: Currently running a ~1000 package dpb(1)[1] build of my needed openbsd ports on a dual-core KVM machine hosted on a 8-9 year old amd64x2 2.2ghz. 3 Days and counting, will probably be done around next weekend. From there, increment…
Earlier quoted context omitted.
> Unfortunately that's not feasible for highly performance-sensitive projects like browsers or games. Bullshit. Code needs to be compiled, but it isn't required to build everything from scratch whenever someone touches a source file. Additionally, not all code is located in any hot path.
Code needs to be compiled, but it isn't required to build everything from scratch whenever someone touches a source file. Except for C++, where a tiny change in a single object will require recompiling every file that transitively includes that object's header.
PIMPL, forward declarations, pre-compiled headers, binary libraries are all tools to reduce such dependencies.