5 ms·
and even claimed to be faster than C for certain cases -a promise made for pretty much every language ever. Just need a couple of compiler tune ups. Not trying
by personZ 12y ago
and even claimed to be faster than C for certain cases
-a promise made for pretty much every language ever. Just need a couple of compiler tune ups. Not trying to be critical, that just gave me a chuckle.
On most architectures (including x86-64, ARM, and ARM64), the first few parameters to a function are passed in registers
To add to this, the Microsoft 64 calling convention is that the first four integer parameters (which includes pointers), and the first four floating point values, are passed in registers. The System V AMD64 ABI (used by Linux and others) passes the first 6 integer and the first 6 floating point parameters in registers.
ARMv8 convention is that the first 8 integer/pointer values, and the first 8 floating point values (so up to 16 values) are passed via registers.
This isn't all win, of course -- if your code was using those registers, to hold local variables for instance, it needs to save and restore them, or simply avoid them. In most cases it would be the latter given the abundance of registers.
The whole aliasing bit was just weird and detracts from the piece. Anyone who is doing pointer-based-operations in base C is using restrict as appropriate.
- mikeash 12y agoDid you look at the aliasing examples beyond the memcpy reimplementation? It can affect perfectly normal code where you'd never think to use restrict.
- corysama 12y agoExactly. Yes you can use restrict. And, you probably will when writing benchmarks. But, this isn't about speeding up benchmarks. This is about speeding up real world production code with real world production deadlines. Are you really going to intelligently and correctly apply restrict to every function you write where it could help in your next commercial product? Do you really expect everyone on your team to do the same and never screw up? Then there's the teeming masses of app developers who aren't quite as awesome as you. You don't care about them, but Apple does. Apple knows most of them couldn't restrict their way into a box ;) But, they still churned out a billion apps that are used by billions of users. Doing whatever we can to trick them into speeding up their code will literally save untold lifetimes of cumulative lag for the users.
- mikeash 12y agoI just want to say how much I enjoy the phrase "trick them into speeding up their code".
- cwzwarich 12y agoMost C/C++ compilers don't propagate `restrict` after inlining, so you lose a lot of optimization potential even if you use `restrict`.
- aktau 12y agoI had no idea about this, I had mostly assumed that a decent compiler would do this. There is no reason this can't be implemented in the future, right?
- cwzwarich 12y agoIt is difficult to implement correctly because the rules for `restrict` in the spec are quite nonintuitive; it doesn't simply mean that the two pointers don't alias each other. The guarantee provided by owned pointers in Rust is stronger than that of `restrict` in C, so we should be able to propagate the must-not-alias constraints better upon inlining.
- bluecalm 12y agoThis is very interesting! Do you have some code examples or deeper explanation of this by any chance ?
- cwzwarich 12y agoWell, I'm not a C language lawyer myself, so I'm merely going off of what I have heard from people who are, but consider the following C function: bool f(int *restrict a, int *b, bool should_modify) { if (should_modify) { *a = b; } return a == b; } Does this function have defined behavior? It turns out that the C spec says that the aliasing restrictions imposed by `restrict` only apply if the memory object pointed to by the restricted pointer has an intervening modification in the scope of the `restrict`; otherwise, the pointers are allowed to alias. Therefore, this function does not have defined behavior for all inputs. If a and b point to valid memory objects and a != b, then the behavior of f is defined regardless of the value of should_modify. If a == b, then f only has defined behavior if should_modify is false. Yes, this is arguably insane, but it's also the spec.
- DrJokepu 12y ago> a promise made for pretty much every language ever. Just need a couple of compiler tune ups. Not trying to be critical, that just gave me a chuckle. I was under the impression that C's qsort is often beaten by languages with support for templates / generics? I'm pretty sure they were talking about qsort.
- artificialidiot 12y agoIf you compare standard library approaches between languages, yes, ones which let you inline calls will beat callback through pointers in thight loops, which is comparison function in qsort. Most of the time it is inconsequential. You could have used C preprocessor if you really wanted.
- bluecalm 12y agoYeah, but you can easily get C implementations of qsort which beat standard library one on most inputs by 2x/3x. For example here: http://www.ucw.cz/libucw/ http://www.ucw.cz/libucw/. Speed of sorting on modern machines depends mainly on what is in cache so even if you have some very clever implementation (like 3way split in qsort in recent Java) it won't help you if elements are not close to each other in memory. If you are sorting structs vs objects which are somewhere on the heap you already lost the performance battle so the compiler needs to very smart to make up for this.
- erichocean 12y agoso the compiler needs to very smart to make up for this Since compilers don't control malloc, it's pretty hard for them to do any kind of optimization that relies on the physical locations of distinct objects in memory. Not impossible, but even a very smart compiler would find it difficult to do things that an above average programmer could easily do up front, by using a better architecture/approach to begin with.
- pjmlp 12y ago>and even claimed to be faster than C for certain cases -a promise made for pretty much every language ever. Just need a couple of compiler tune ups. Not trying to be critical, that just gave me a chuckle. I remember the days when C was just yet another systems programming language deemed too slow for any serious work. EDIT: Always nice to be downvoted by hipsters that lack coding experience from the days C was UNIX only.
- chton 12y agowhile true, that doesn't make it a bad comparison. Languages like Swift are one step up on the foodchain, they provide more abstraction. Comparing to a popular language one step down is a good way of showing the cost (or lack thereof). I'm sure 10 years from now we'll all be going "Language X is faster than Swift in certain cases!"
- csl 12y ago> I remember the days when C was just yet another systems programming language deemed too slow for any serious work. I've heard that remark several times. Which languages were faster than C back then, except assembly? Fortran? Algol? BCPL?
- pjmlp 12y agoAssembly of course. All higher level languages were still 2nd place to Assembly and had similar execution times across the board.
- josephlord 12y ago> and even claimed to be faster than C for certain cases -a promise made for pretty much every language ever. Just need a couple of compiler tune ups. Not trying to be critical, that just gave me a chuckle. It can be true although the "certain cases" may be quite a small set and there are likely to be many cases where C is faster than language X (where X includes Swift). The whole aliasing bit was just weird and detracts from the piece. Anyone who is doing pointer-based-operations in base C is using restrict as appropriate. Is that really true? Sure in highly optimised low level code it can be true. But in general code when can the compiler know that there is no aliasing. Isn't this the reason that Fortran can be faster than C in many cases?