detrino

21 ms·

151.
by detrino 12y ago
> You might think that it is unfair to compare multithreaded Haskell against C++ that is not multithreaded. And you’re absolutely right! But let’s be honest, manually working with pthreads in C++ is quite the headache, but parallism in H
152.
by detrino 12y ago
I really don't think it matters if you call them "dots per inch" or "pixels per inch".
153.
by detrino 12y ago
> C++ is like mold. Yes it is ugly, and you don't want it, precisely because this is the most efficient form for it to be able to colonize your food. Why does any mention of C++ bring out these silly metaphors that contribute nothin
154.
by detrino 12y ago
Garbage collection does not offer better throughput than manual memory management, in fact it tends to need ~6x the memory to equal it[1]. [1] http://www.cs.umass.edu/~emery/pubs/04-17.pdf
155.
by detrino 12y ago
Fiction is not reality, this judge was almost certainly motivated primarily by money.
156.
by detrino 12y ago
People complain about Unity and Gnome3 because they don't offer workflows that work well for desktops. The Linux community is open to change and new ideas, but when the majority of users are unhappy with something for such a long time
157.
by detrino 12y ago
Here is a fun demonstration of undefined behaviour that someone showed me recently: http://ideone.com/LsEUPa
158.
by detrino 12y ago
> You have to admit, it's hilarious that the most natural swap implementation you could possibly write (and the one used in C++03) is now "standout terrible." It's not wrong to point that out, but it is wrong to assig
159.
by detrino 12y ago
Type erased closures are strictly less useful than subtype polymorphism + virtual functions (another form of type erasure) as the latter allows you to share data among an entire interface.
160.
by detrino 12y ago
Most programming languages implicitly type erase closures, C++ does not. Type erasure can come at the cost of heap allocation and indirect function calls. If you need type erasure in C++ you can put any callable type inside std::function.
161.
by detrino 12y ago
This is a contrived example. Not only is vector<bool> the real problem, but this is a standout terrible way to swap elements, especially in generic code.
162.
by detrino 12y ago
> * non templated tuples instead of struct: for example, 2 struct types are the same if the data types they hold is the same. Not sure if it's possible for statically typed language. C++ has std::tuple, but most people (myself inclu
163.
by detrino 12y ago
I really enjoyed this talk. The Q&A session was great as well, Scott is an entertaining story teller.
164.
by detrino 12y ago
Well, benchmarking without optimizations enabled isn't very useful :)
165.
by detrino 12y ago
Also make sure you are compiling with optimizations on.
166.
by detrino 12y ago
With your modified code I am now seeing #1 run about 3x faster than #2. I also still strongly suspect you weren't measuring anything at all before your modifications. Benchmarking is tricky and its hard to say if you are really measuri
167.
by detrino 12y ago
The compiler is entirely eliminating your loop because you never do anything with the sum variable. Also, signed integer overflow is UB so you should use unsigned integers or compile with the non-standard -fwrapv option.
168.
by detrino 12y ago
Then my results disagree with yours. Do you have the source code to your benchmark ?
169.
by detrino 12y ago
I'm not sure how you measured your programs, if you measured them as a whole, then the random generation and sorting probably dominated the run-time. On my machine #1 is 3x faster than #2 for just the summing part of 10M 32-bit integer
170.
by detrino 12y ago
Note that currying is not necessary for partial application, here is partial application implemented in C++14: http://coliru.stacked-crooked.com/a/bed4a4fdd6e856b0 However, I find lambdas with the extra parameters repe
171.
by detrino 12y ago
I think graydon is reaching here, while there may be some intersection of features in Rust and Swift, I don't really see any Rust influence at all.
172.
by detrino 12y ago
I think it's just the type of the accumulator[1] that influences this, GCC seems to vectorize it fine for any type other than signed char/signed short. [1] s in your code, result in the author's Edit: The reason for the failu
173.
by detrino 12y ago
I don't have gnome installed anymore, but a few things I remember: The window list extension doesn't allow you to change the order of windows with drag and drop and I'm not sure if its possible at all. You also have limited o
174.
by detrino 12y ago
Gnome3 classic mode is mostly just Gnome3 + some extensions. The user interface is only superficially similar to Gnome2. Most things feel crippled compared to what came before it and it loses functionality on every release. Mate is excellen
175.
by detrino 12y ago
I think there is a huge opportunity for a traditional, lightweight desktop that uses Qt. Both the Gnome and KDE camps have alienated large parts of their userbase during the KDE4/Gnome3 transition. I personally find both to be less usa
176.
by detrino 12y ago
That's a representation problem. C/C++ use half open ranges and have no problems with unsigned integers. This is also a non-issue in C++ as you have iterators and counting loops are easy to abstract away using counting iterators o
177.
by detrino 12y ago
It's a problem with C for loops. There is really no good way to write a counting down loop using a for loop. The fundamental problem is that a for loop is: test a condition, run a loop body, then run a step function. This is suited to
178.
by detrino 13y ago
A cleaner, more efficient version: http://ideone.com/B8p7m0 Edit: A better way to write the inner loop: http://ideone.com/wEfNyh Edit: When the values are initialized to 3, 4, 5 instead of 0, 0, 0, the prog
179.
by detrino 13y ago
What he was saying should be obvious, since there is actual code in the comment he was replying to, and its not what you wrote.
180.
by detrino 13y ago
Use after move by itself is not undefined behaviour.

More ›