galacticpony

You haven't actually verified SROA. The scalar replacement didn't kick in for the non-inlined method, so this could be a result of loop-specific optimizations. The code is also far from optimal, but that's besides your point of course.

Also note that you're testing an RC of the latest version. There's a feature request for SROA from 2013, so it may be implemented by now: https://connect.microsoft.com/VisualStudio/feedback/details/...

MSVC compiler doesn't do SROA, as far as I know.

> What do you think http://www.agner.org/optimize/#vectorclass is then?

Have you actually looked at that thing? It's not a Point struct, I can tell you that. There's nothing abstract about it.

If you want to take advantage of SIMD fully, you need to lay out your data in a very specific way. A Point {x,y,z} struct doesn't naturally fit a SIMD register.

Now, if you're willing to make a lot of assumptions on your compiler, you can do something like this: http://www.codersnotes.com/notes/maths-lib-2016/

Still, you need to put in the work and the research. No magic.

> Yes, it is! It makes your code more readable, and if you're compiling on any production-quality C compiler anywhere your Point class will have the same performance as the raw version. Lower maintenance cost, fewer bugs, same performance.

If performance really matters then your abstract solution is almost certainly suboptimal and it's not good engineering practice to use it for the sake of readability.

If you really care about performance to the point of register occupancy, you need to look at the context. The "abstraction" of having a Point type with methods is almost certainly far from optimal, because it doesn't fit SIMD well. It's then also not "good engineering practice" to use it.

I also don't think it's the lack of language features that makes it bad. This is something that is getting addressed.

What really does cause problems is the basic types, the type "system" and the way numbers are treated/represented.

GHC also happens to be one of the slowest compilers you could possibly use. It all goes together.

You, too, believe in the magic compiler that doesn't exist. You don't get good code from a high-level specification. You really have to understand what the compiler actually can do for you and write your code accordingly, either way - except the predictable case is more straightforward (though maybe not as pleasing).

Regarding the second statement: These "smart" optimizations happen before architecture specialization, so that's wrong too. But even if it was true, you now shift the burden to understanding every compiler in order to get the optimization you need.

If people expect that pow(x,2) transforms to x * x, then every compiler would have to implement that. This is a trivial example, but you in reality you always have to structure your code appropriately for some optimization to kick in, what if one of your target compilers needs a different structure?

There is no way to "fix" Javascript without breaking compatibility. It will always suffer from its poor initial design decisions, or it will stop actually being Javascript.

Anybody who uses a pow call to square a number must believe compilers are magic. Worse yet, some compilers might actually optimize for that case, reinforcing that belief.

Compilers should be dumb, fast and predictable instead. That way, everyone gets what they deserve.

Why the hell would that realization change your mind? For society at large, that "huge spectrum" includes copious amounts of superstition and ignorance, which (one would hope) should be significantly lower in those people subjected to scientific scrutiny on a regular basis. You're gambling on something being in that spectrum that will positively offset this negative, but you don't know (or mention) what it is.

"But do I want educated and principled jurors on any jury that judges me, ones with enough fortitude to mis-trial a jury or nullify a law if that's what is required? Damn straight."

So you actually want a different kind of elite to be jurors, but not just physicists. You don't actually want citizens as a whole.

"If the notion that your citizen-peers might not be informed troubles you, take time to help others form informed opinions."

Have you ever tried that? What makes you believe that your citizen-peers are even interested in spending their valuable time to listen to someone else trying to change their opinion? Lots of people are quite fond of their uninformed opinions.

It still seems intellectually dishonest to leave it out. Clearly, what Dijkstra in 1972 considers too "clever" may in fact be tools that are now basic building blocks of everyday software. We can all agree that "too clever" is bad. We can't agree on what "too clever" is.

"But, lets discuss the 'for clause' and 'do loop': these constructs were made specifically for one kind of simple loop. It is not a systematic solution for an iterative process."

I'm fairly sure (from what I remember him writing) that he doesn't like it because you can do the same thing with existing constructs, so you'd be adding complexity to the language that isn't strictly necessary. History has shown that actual programmers prefer having for loops like Algol.

"To me it seems Dijkstra specifically aims for languages such as LISP (which, with the renewed interest from Clojure is one of the most oldest successful (semi-) functional programming languages)."

Probably not, or else he would've talked about LISP in a different manner (he does talk about it in an earlier paragraph).

I didn't say Dijkstra was talking out of his ass in this case. I'm saying you often can't tell when people like him are talking out of their ass, as they sometimes do. Who would think the inventor of all these algorithms would ever utter a half-formed thought, on a whim? Unthinkable! Yeah... no.

Another distinction you fail to see is that somebody who is great at finding the best or optimal algorithms (i.e. a great theorist) isn't necessarily a productive programmer. To the contrary, perfectionism and productivity are at great odds.

Dijkstra was heavily at odds with real-world programming as it was done, to the point of isolating himself with his work. If we followed his opinions on how to program, we wouldn't get much of anything done.

"I see a great future for very systematic and very modest programming languages. When I say “modest”, I mean that, for instance, not only ALGOL 60’s “for clause”, but even FORTRAN’s “DO loop” may find themselves thrown out as being too baroque."

While I agree with the general sentiment, it's very important to take anything Dijkstra says with a huge grain of salt. He was a mathematician first and foremost. He obsessed about things like a mathematician. Such people, while very smart, make for very unproductive software engineers. They also have a way of sounding deceptively smart and thoughtful, when really they're just talking out of their ass. Beware.

This design (even though it doesn't work in reality) is about creating something that is functionally like the earlier Mac Pros. That means commodity off-the-shelf hardware can be used, not just specialized or outlandish components that are going to be very expensive, if anybody bothered to produce them at all. The current Mac Pro still ships with the outdated GPUs it originally was introduced with, with no upgrade path foreseeable.

Which is ironic, considering the premise is that the module system is "too confusing". Having never used Rust, the current rules - as explained by the author himself - seemed straightforward. For the proposed new rules, I'm confronted with two long paragraphs.

I didn't bother to read them. If the intent is to make the system less confusing, there should be a way to explain the new rules as tersely as the old ones.

Here's some of the problems:

- You can accidentally "select" the text of the buttons

- changing the style of the text causes selection to flicker

- clicking outside a paragraph area causes the selection to flicker (instead of moving the cursor)

- many of the menus don't collapse automatically and they overlap each other

- the site layout just breaks when the page width is too narrow (may be more of a website problem)

All of these are very common problems with web technology, working around them makes the difference between "good" and "acceptable".

You point at some facts that happen to be similar (when adjusted) for the US and Switzerland, but it's rather arbitrary. What the hell does gun ownership have to do with healthcare? And of course, like most industrialized countries, there are "lots of cars"...

The absolute difference in wealth doesn't affect just medical equipment, it affects practically everything besides labor. One of the reasons why labor is so expensive is the high taxes (VAT etc). When the government subsidizes that expensive labor, it'll get a big part right back.

You also edited your post to agree more with mine (i.e. Obamacare), when the original point was more like "private insurance can work look at Switzerland!".

Yes, it can work, if you're wealthy Switzerland and you regulate the fuck out of everything. Touche...

The nominal GDP in Switzerland is actually much higher than in the US, it's just that the country is way more expensive to live in. Therefore, when adjusted for cost-of-living (PPP), the GDP are about equal.

Of course, the absolute amount of money per capita is still much higher, which lowers the relative cost of, say, medical equipment.

The private healthcare in Switzerland is also compulsory and insurers are forced to offer a basic, non-profit plan. Furthermore, individual payments may be subsidized by the government. It's therefore not that different from Obamacare, nor are private insurers left to the devices of the "free market".

You pay nothing on the first 9700€

You pay 14% on the money you make above that, that is 14% of ~17k€

You then pay 30% on the money above that, that is 30% of the extra 5k.

That sounds like something a bad tech hire would say.

That's why I'm suspicious as to which name he actually entered.

Again, it's unclear under whose name the account really was registered, but if he went through the trouble of sending in photo ID, Kapeli would probably mention that as to further exonerate him of any mistakes.

"You can choose from the payment methods presented during your membership purchase. If you are paying by credit card and enrolling as an individual, you must use your own credit card to complete your purchase. If you do not, your enrollment will be delayed and you will be asked for a copy of your government-issued photo identification."

https://developer.apple.com/support/purchase-activation/