civility

22 ms·

211.
by civility 9y ago
If you can reduce everything to _one_ mutex, that's simple. As soon as you have two mutexes, you need to start worrying whether one thread grabs A then B and another grabs B then A. In larger projects with multiple people contributin
212.
by civility 9y ago
> But hey, I'm guessing you actually don't know what the words I'm using even mean I can't believe this comment wasn't reprimanded. This is one of the least civil things I've seen someone here say in the la
213.
by civility 9y ago
I'm not going to dive into your points about constraint solvers, type classes, or "monomorphization". Unless those things take more than a few percent of the compile time, they're just more red herrings. > Incrementa
214.
by civility 9y ago
> I'm simply pushing back on the idea that there's some obvious low-hanging fruit that clang did that rustc didn't. [...] magic bullet I didn't suggest low hanging fruit or a magic bullet. If anything, incremental co
215.
by civility 9y ago
My criticisms are meant to point out areas for actual improvement. Try to be scientific. If you've got a conjecture, test it and see if it holds water. One excuse was that C++ is only faster because people build C++ projects with sep
216.
by civility 9y ago
It's not ironic. I see this kind of thing all the time. Rather than cleanup and speedup an implementation, engineers will make it multi-threaded or send it off to a GPU, generally achieving limited improvements and greater complexity
217.
by civility 9y ago
> I think this gets at Wirth's law a bit. I think Proebsting's law is also relevant. Compilers did an impressive job of optimization in the 90s, and while yes there have been advancements in the last 18 years, it's foolis
218.
by civility 9y ago
> how many of those lines did the compiler actually generate code for? Not many. How many lines would a comparable Rust program have to instantiate? (should be the same) All I was trying to do was make an apples to apples comparison by
219.
by civility 9y ago
Below, steveklabnik claims these things are miniscule. Are you really sure you know what is actually slow?
220.
by civility 9y ago
No idea, maybe a lot from the system headers. However, it was 20,000 lines of code that survived the preprocessor, 11,000 of which were inline or template from the project itself.
221.
by civility 9y ago
It means things don't usually get better until you admit they're not as good as they can be.
222.
by civility 9y ago
> Don't forget the differences in compilation model; C/C++'s compilation units are much smaller Not everyone compiles C++ the same way. I prefer header-only libraries and a single compilation unit. Counting lines of code
223.
by civility 9y ago
Not going to budge an inch, eh? It must be as good as it will ever get.
224.
by civility 9y ago
Oberon certainly compiles quickly, and I believe Delphi (Pascal-ish) was fast too, but I was thinking of Microsoft's Java compiler before they got spanked.
225.
by civility 9y ago
> Incremental compilation! Is there some algorithm in Rust which has a necessary big-O? There were compilers in the 90s which ran a million lines per second (on much slower computers). Incremental compilation feels like working around
226.
by civility 9y ago
If you neglect some of the metaclass stuff, which I believe most people do, then Python is nearly isomorphic to JavaScript. I think the comparison is very fair. I also believe the reason Python is unlikely to ever catch up to JavaScript is
227.
by civility 9y ago
> I see a 4x speedup on most of my slowest pure python workloads Heh, only 25..250 X to go. We did a direct line for line translation of some numerically intensive code from Python to C++ and saw a literal 1000X speedup. On other proje
228.
by civility 9y ago
Why are they "genuine successes", but only "alleged problems"? I think you're giving them credit for alleged successes and ignoring the genuine problems.
229.
by civility 9y ago
> The other name for big-endian is "network order", after all. I wonder where this started... I always suspected it was Sun with their "The Network is the Computer" motto, and of course they would define "networ
230.
by civility 9y ago
Heh, so does yours. I can say this without even knowing what language you use to write your software, much less looking at it... All software has bugs, and most of those are security vulnerabilities waiting to happen.
231.
by civility 9y ago
Armchair preaching? Who is this "we" in "we are to do anything"? Unless you're contributing to a replacement, your proclamation simply doesn't matter.
232.
by civility 9y ago
There are lots of people who do elaborate things in Excel. I'm sure they could learn Python, but they don't and won't. Instead of changing the people, consider that maybe what they want/need is something like Excel but
233.
by civility 9y ago
Nim has become so good that no one else should develop languages as pet projects? If that's what you're saying (which is how I read it), it's a very obnoxious sentiment.
234.
by civility 9y ago
Yep, Clojure made some nice improvements (still 4 parens, however), but I just can't get excited about the JVM.
235.
by civility 9y ago
I happen to like Lisp (well, Scheme at least), but I think a better comparison would be: let a = 123, b = 456, c = 789; # more code vs: (let ((a 123) (b 456) (c 789)) ; more code ) In
236.
by civility 9y ago
I don't agree they are useless - they don't stop you from accessing nullptrs, but they do help manage the lifetimes of your dynamically created objects. And I haven't seen anything indicating unique_ptr is to be deprecated -
237.
by civility 9y ago
You can easily ignore null by accident while using smart pointers: struct foo { int bar; }; std::unique_ptr<foo> bug; bug->bar = 123;
238.
by civility 9y ago
How about the chip in any recent model iPad or iPhone?
239.
by civility 9y ago
How about on ARM? Is its branch prediction keeping pace? I'm curious because you can't JIT to native on iOS, so finding the best way to build a VM there is interesting.
240.
by civility 10y ago
"Generally these people bring cash"

More ›