undefined | Better HN

0 pointsgoggles9913y ago0 comments

You are not seeing my point. If the JIT compiler can be made better - than so can the C compiler right? Until some point where neither can be made better. Then C would win because it does not carry the extra overhead of the other.

0 comments

4 comments · 2 top-level

CJefferson13y ago· 2 in thread

OK, here is an example. Let's consider 'memcpy'. There are various problems with implementing memcpy in C:

1) You can't assume that pointers are aligned. 2) (related) If the user asks for you to copy n bytes, you better not read byte n+1, even if you don't need it, because maybe it is on a different page which is not available for reading.

So, an optimised memcpy usually first has to do a bit of work to find the 'aligned segment', do that, topped and tailed with some special cases.

A JIT compiler for Javascript (for example) takes issues of alignment out of the hands of the user, so can make any assumptions it wants by keeping such choices away from users.

Of course, we could write a memcpy_aligned (and some systems have such a method), but we can't ever optimise simple memcpy as much as the equivalent in javascript.

ori_b13y ago

1) Loop versioning. You can check if the pointers are aligned, and then decide whether you want to take the fast path or the slow path. (A better example would be aliasing. Because pointers don't carry the size of the region they point to, we can't check if two pointers alas. Restrict solves this problem with programmer intervention.). I believe that GCC's vectorization code already does this sort of versioning.

Example:

     testl $0xf,%ptr
     jz aligned_path // in reality, fast path would be inlined here for cache locality reasons.
     jnz aligned_slow_path

2) If your reads are naturally aligned, you will never be able to read a word that starts on one page and ends on another, so working in naturally the largest naturally aligned chunks you can is valid. This is a non-problem. (In fact, glibc takes advantage of this in it's assembly implementations of various SSE string functions.)

CJefferson13y ago

This is true, but a high-level language can avoid having to even make that check, making it "faster than C", in at least some sense of the phrase.

1 more reply

homeomorphic13y ago

No, not neccessarily. There could be optimization opportunities in the more abstract language that perhaps cannot ever arise in the less abstract.

j / k navigate · click thread line to collapse