Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beating the compiler

roguelazer.com

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Beating the compiler

#31

Post by yoklov »

blt wrote: post #29
yoklov wrote: post #17

Earlier quoted context omitted.

Again, inline ASM is pretty rare these days (when we do use it, it isn't for SIMD). Intrinsics are much more common. The big issue (aside from convincing MSVC to implement it ;) with your suggestion is that, unlike TCO, vectorization isn't really a boolean. There's a range of what vectorization might mean (you can vectorize code and do a bad job with it, only marginally beating out the scalar code), so you'd still ne…

Writing SSE code using compiler intrinsics is indeed a fun puzzle, but it has huge drawbacks: 1) it's Intel-specific, and 2) it's a maintenance risk unless everyone in the shop knows how to write and maintain SSE code. Unfortunately nobody else at my job knows how to do it, so I am not allowed to check any in :(

> it's Intel-specific

Most platforms offer intrinsics.

> it's a maintenance risk unless everyone in the shop knows how to write and maintain SSE code.

This is understandable, but not the case where I work. If you need to be writing SIMD code and this is the case, then you need to hire programmers who can do it. That or convince them to learn, as (again) it's not that hard.

Re: Beating the compiler

#33

Post by spiznnx »

Why stop at -O3? If you're going to compare with vectorized asm, you can get the compiler to use avx vector instructions in its optimizations. Add -mavx to your flags and the vector instructions will show up there as well.

Re: Beating the compiler

#34

Post by frozenport »

Dewie wrote: post #21
angersock wrote: post #8

On the general topic of how much we can rely on compilers, even using old and well-understood languages (C++), consult Mike Acton: http://www.slideshare.net/cellperformance/gdc15-code-clinic https://www.youtube.com/watch?v=rX0ItVEVjHc

C++ is well-understood? I don't get that impression from people who know it.

Indeed, the language is well understood but code often isn't because its easy to write UB.

Re: Beating the compiler

#35

Post by lumpypua »

haberman wrote: post #20
rogerbinns wrote: post #18

Earlier quoted context omitted.

The Python code was trivial to write and immediately correct and robust. Trying to get C code to do the right thing is considerably more difficult - for example even trying to detect overflow can result in code the compiler then removes - http://lwn.net/Articles/278137/ Robust, correct and fast are a hard combination to do. I do acknowledge the article is about the latter.

It's not hard if you use GMP.

The fancy library you're using in that other part of your project doesn't use GMP.

Re: Beating the compiler

#36

Post by haberman »

lumpypua wrote: post #35
haberman wrote: post #20

Earlier quoted context omitted.

It's not hard if you use GMP.

The fancy library you're using in that other part of your project doesn't use GMP.

It likely doesn't need arbitrary precision arithmetic either. A lot of algorithms truly want modular arithmetic (hashes, checksums), many are dealing in domains that can't practically exceed a machine integer size (length of a string, number of vertices in a graph, etc). There is no reason that every library needs to deal in arbitrary precision.

Re: Beating the compiler

#37

Post by _delirium »

haberman wrote: post #36
lumpypua wrote: post #35

Earlier quoted context omitted.

The fancy library you're using in that other part of your project doesn't use GMP.

It likely doesn't need arbitrary precision arithmetic either. A lot of algorithms truly want modular arithmetic (hashes, checksums), many are dealing in domains that can't practically exceed a machine integer size (length of a string, number of vertices in a graph, etc). There is no reason that every library needs to deal in arbitrary precision.

> domains that can't practically exceed a machine integer size

This assumption is common among authors of C code, but is sometimes also exploitably incorrect. Even if you really don't care about supporting things larger than a certain size, you do still have to correctly account for overflow, not just ignore it.

Re: Beating the compiler

#39

Post by haberman »

_delirium wrote: post #37
haberman wrote: post #36

Earlier quoted context omitted.

It likely doesn't need arbitrary precision arithmetic either. A lot of algorithms truly want modular arithmetic (hashes, checksums), many are dealing in domains that can't practically exceed a machine integer size (length of a string, number of vertices in a graph, etc). There is no reason that every library needs to deal in arbitrary precision.

> domains that can't practically exceed a machine integer size This assumption is common among authors of C code, but is sometimes also exploitably incorrect. Even if you really don't care about supporting things larger than a certain size, you do still have to correctly account for overflow, not just ignore it.

Yes, overflow checks are critical, and tricky in the absence of language support. Yes, testing them is tricky, and often exploitably buggy in the absence of such tests. No, this does not mean that (for example) the Linux kernel should use arbitrary precision to represent pids (for example). Yes, this does mean that better approaches for more systematically dealing with overflow are a good idea.

Re: Beating the compiler

#40

Post by panic »

im2w1l wrote: post #38

Is there a library with "optimal" implementations of functions such as these?

OS X and iOS have Accelerate.framework: https://developer.apple.com/library/mac/documentation/Accele...

In particular, see vDSP_sve and vDSP_sveD which compute single-precision and double-precision vector sums respectively.

Post reply on HN