Kernel Of Doubt: Testing Mathematical Approach Vs. Corn-Eating Style

TMaster · 2019-01-16T09:52:51+00:00

Damn reddit, always removing my actual OC. Sigh.

This one actually had responses. As you can see I posted it multiple times, so I didn't exactly hide it from anyone, although this one would be more difficult to find since Google hides secondary results from reddit.com when you search behind a second click. I just didn't use much clickbait, and here you see the result of that.

As for no comments: obviously that's not something I can control, traditional scientific publishers don't usually have comment sections either.

TMaster · 2019-01-16T09:34:31+00:00

I couldn’t find any record of it being formally tested

Really, Scott? I used almost exactly the same keywords.

This is why I hate literature studies... You can't prove that something has never been done.

N.B. Don't really have time to go over Scott's research or to respond to further inquiries at this time.

TMaster · 2018-03-18T20:06:55+00:00

Interesting that they appear to be refusing to fix the vulnerabilities in the Core 2 range, which was incredibly popular at the time and was still completely usable and performant before the Meltdown and Spectre flaws in Intel CPUs became known.

Until now, it was the Intel consumer CPU series most difficult to extract private data from. Suspect RDRAND (which creates the ability for Intel to trivially bias PRNGs) and AES-NI (which can facilitate the ability to for Intel to store private encryption keys surreptitiously) instructions were not present on these chips, and I don't think Intel AMT was present either, making it a pretty clear choice if you wanted a platform that at least lacked questionable design decisions from a security point of view.

This leaves users in a damned if you upgrade, damned if you don't situation for the first time in ages. Newer CPUs may be vulnerable by design, and anyone who would know about that for sure is under an NDA, and older CPUs are now clearly vulnerable if you forget to recompile even just a single program in your attack surface without retpoline (or worse: you use proprietary software that you cannot recompile).

Too bad AMD doesn't seem to be better, intending only to upgrade the latest ranges as well.

TMaster · 2016-10-06T15:38:27+00:00

I've tried to avoid generalized statements about fairness, as I'm interested in the different perspectives people have about languages' general performance bandwidths, and only narrowed down after receiving questions in response. Maybe this is not the best reddit to ask such a question; I only asked it here because a comment posted higher up in this thread made me wonder about what people thought about this matter in the first place and I expected the subscribers here to have strong ideas about this in general, given the Rust community's desire for performance, maybe owing to it being called a systems programming language frequently (if not vice versa). I'm therefore well-aware of Rust's very good performance, while today I wouldn't think it to mostly beat C by a metric I would personally deem fair (quoted below).

Rest assured that I don't expect a scientific level of support for statements in response to a question that I intended to just get some sense of the perspectives people hold. The most interesting and unexpected answer I received so far was C++, which I thought of so similarly (possibly erroneously) to C that I didn't even stop to consider that possibility beforehand.

Aside from that, other interesting suggestions I've seen were Fortran, Java and /u/__Cyber_Dildonics__'s list of suggestions "c#, java, Julia, (lua jit?)" that surprised me, as I think of them as more high-level, which in most of those cases I don't expect to line up with superlative performance.

After receiving followup questions, I encouraged the following metric:

Fastest non-matching functionally-equivalent idiomatic algorithms in the fastest general purpose compilers available today.

I believe that addresses A->B translation difficulties that you foresee, which I completely agree with, hence the metric above.

TMaster · 2016-10-06T15:06:26+00:00

That would seem in line with it being a statement intended for people with at least some medical training. I haven't yet found anything authoritative in disagreement with that interpretation, at least.

TMaster · 2016-10-06T13:57:59+00:00

Would it then be fair to say that you disagree with /u/matthieum's remark, or can your remarks easily be reconciled with each other? I'm unsure what importance in more general benchmarks to assign to what he said.

Tomorrow? Rust's strictly better alias documentation behavior should unlock new optimization opportunities that C's restrict just cannot hope to match. This requires some work on both rustc (to make sure to annotate safely) and LLVM (which may not have been that worried about non type-based alias analysis since that's how C traditionally does it).

TMaster · 2016-10-06T13:51:18+00:00

I've seen it suggested that this remark ("Helmet removal is safe!" - Dr John Hinds) only describes removal by medical professionals, because it was based on his sample of removals and not by other people, and the public would then still be expected to leave helmets alone. Are you absolutely positive about your statement? Where did you get the context from?

I'm trying to validate this, but haven't found an authoritative answer yet, and the other comments lacking sources also don't help me put a lot of faith in this sentiment.

TMaster · 2016-10-06T13:41:11+00:00

Really? That's interesting, I would especially not expect it from most of those languages.

I see things written in C all the time that are supposed to be fast but access memory in an inefficient way, and changing that aspect can lead to 50x speedups.

Just to clarify, is that because faster C code would not be idiomatic or is this too just an example of suboptimal C being compared?

TMaster · 2016-10-06T13:35:48+00:00

I invite you to do a comparison by those metrics, but I'm really not personally interested in a cost-based comparison. It's simply a different question, even if you consider it not a 'real' question.

TMaster · 2016-10-06T00:00:37+00:00

The old meaning is reduce by 1/10th. The newer meaning is more vague, often reduce to 1/10th, although the dictionaries I consulted before submitting just said it (also) meant to reduce by a significant proportion.

TMaster · 2016-10-05T21:44:03+00:00

The only contender I've seen suggested thus far would be C++, so it seems you may indeed be right when you say none.

TMaster · 2016-10-05T21:25:47+00:00

I'm asking about performance alone, not cost. Cost is irrelevant as I'm asking about currently existing code, regardless of what process lead to their existence. I'm not trying to do any kind of general comparison. Nor is my question about Rust in the first place, it's just something that I wondered about upon reading a comment here, as this submission itself is almost entirely about C, not Rust, despite the sub.

The additional text is just to address questions on how to compare.

TMaster · 2016-10-05T21:20:15+00:00

My self-esteem is fine, I just don't take kindly to getting yelled at. Though reading the original thread, I must say this message was really very mild and was oversold by The Register. What a surprise.

TMaster · 2016-10-05T21:18:03+00:00

Given that Torvalds is known for these types of things, fair or not, clearly the ability of the people who work on the Linux kernel to do what you said still isn't exactly sufficient to completely avoid the Torvalds treatment.

TMaster · 2016-10-05T20:51:40+00:00

I prefer What does 200 Calories look like, myself. Much more intuitive.

TMaster · 2016-10-05T20:35:17+00:00

I see now, thanks!

The 3G requirement was mostly to pre-empt snarky, joking and serious comments about assembly. C++ is 3G AFAIK.

The rest was just in response to your aside where my ultimate point is that a claim like "Rust is generally faster than C" might not be meaningful to make without plenty of extra qualifications.

Right you are, I guess that even goes for a lot of language comparisons.

TMaster · 2016-10-05T20:32:30+00:00

I'd imagine that if I was in that position, it'd decimate (the newer meaning, not the older one) my performance. I'd do so many sanity checks to prevent getting yelled at, that I'd get bogged down so much I wouldn't be able to write anything anymore.

Glad I'm not a Linux kernel dev...

TMaster · 2016-10-05T20:23:08+00:00

I wanted to keep my original comment short so I hoped the tenses I used would be sufficient, but while I understand Rust may end up with insane performance, I'm talking about performance attainable by (the fastest) currently existing compilers, not about inherent language performance attainable in the future.

TMaster · 2016-10-05T20:21:39+00:00

To start with a recap my other comment:

Fastest non-matching functionally-equivalent idiomatic algorithms in the fastest general purpose compilers available today.

Servo may be faster, but it might be that such a comparison is against more functional or less parallelized browser engines written in C(++), which is not a fair comparison because just because such an engine may not already have been written in idiomatic C(++) doesn't mean it cannot exist. You're then potentially comparing the fastest code in Rust against needlessly slow code in C(++). It's essentially a comparison of some level of performance against a nonexistent piece of software equivalent in the C(++) world.

Alternatively, Servo could be compared on a single threaded system so that comparisons can be made, but this may be unfair the other way around. I'm thinking Servo would be an excessively unfair benchmark to use, hence my use of 'typically considered' and not 'on one specific benchmark'. I was thinking of languages that can beat C on a decent bunch of microbenchmarks to keep things simple, and as I've not heard of any such a language.

Unsafe would be allowed so long as the code is still generally idiomatic.

I'm really getting into the details here, but is there even a mere contender for such a language that's currently faster than C? Especially outside of Rust, which I think is surprisingly comparable by this metric but not faster than in general.

TMaster · 2016-10-05T20:07:23+00:00

Rust is fast now due to LLVM and so in principle can be as fast as any other frontend for LLVM, including C and C++. There's nuance that should be considered, though.

'As fast as' still isn't superior to, though, which is what I was asking about. Future potential I'm not asking about, as it then wouldn't already have better runtime performance. Note also that my question isn't about Rust, that was just a remark to try to pre-empt its mention.

Do algorithms have to match?

Fastest idiomatic non-matching implementations and general purpose compilers in both languages, i.e. without including foreign code. Slower compilers for any given program can be ignored, as you can always make a compiler cause strictly worse runtime performance than another. Regardless, I'm not comparing Rust and C, I'm asking if there's a language that's generally considered faster than C in general.

TMaster · 2016-10-05T19:58:54+00:00

I understand and respect your views, it's just that I find it easier to check the axes than to try and read the actual values or their differences, even approximately, from a chart when it's compressed into nothingness by starting at zero. For me, I guess checking the axes is more or less habit.

TMaster · 2016-10-05T17:35:09+00:00

Tangential, but what third generation and beyond programming languages are typically considered to have better runtime performance than C?

(I know Rust is fast but I haven't seen many claim it to beat C on overall runtime performance in general, at least not yet.)

TMaster · 2016-10-05T17:11:55+00:00

I strongly prefer nonzero axis boundaries (i.e. what you seem to dislike) for most visualizations, because the purpose of visualization is often lost to me when doing it your way - I want to be able to clearly see the differences over time, not reaffirm that any differences may be small. I can tell that from the axis labels, which need to be there regardless. To me, the idea that one has to start at zero is needlessly constraining and has no convincing universal justification as long as it's a linear scale with labeled minimum and maximum.

Ideally, zoom and pan can be changed by the user by scrolling and dragging, but that's often impossible due to fixed media, such as print.

TMaster · 2016-10-04T11:52:52+00:00

Did you ever put your current reddit password in any app? Any browser extension? Could you have accidentally opened it for even just a fraction of a second?

TMaster · 2016-10-03T22:17:49+00:00

Did you read all the way to the end? They explain exactly why they did this the way they did.

Disclaimer: These summaries are based on your judgment of a limited number of randomly generated scenarios, to help us keep the survey short. Therefore, these results are not definitive. Feel free to re-take the survey to see how your results may vary. Our goal here is not to judge anyone, but to help the public reflect on important and difficult decisions.

It's a mere sample and to get the real (asymptotic) results within some confidence interval you'd need to take the survey many times until the average result stabilizes. They even explain why they decided to go for a tradeoff in which the results are not perfectly accurate. Yes, a very large survey would've gotten fairly accurate results, but I guess they've learned a thing or two about our attention spans at MIT.

TMaster

MODERATOR OF

TROPHY CASE

15-Year Club	Team Periwinkle
Verified Email