| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Original HTTPS Page] |
Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.
You must be logged in to block users.
Contact GitHub support about this user’s behavior. Learn more about reporting abuse.
Report abuseSuper short summary: Using `ntohs` in code resulted in huge bloat with both `gcc` and `clang`. The preprocessor _must_ see it as a function call, `ntohs()`, to replace it with its built-in equivalent. So using `std::transform` on something that is normally a macro but has a library fallback will cause your code to slow down considerably (and in my case not be able to keep up with a real-time processing flow).
https://gcc.godbolt.org/z/dM2Ge4 is a MWE (also attached to this gist). As of 4 May 2020, both compilers' trunks with `-std=c++17 -Ofast` will `call` the `ntohs` from an internal library with the "naked" `std::transform` call. If your compiler supports lambdas, the second iteration works around the issue. If not, the hand-unrolled third version produces the exact same assembly as the second.
This is because if you dig deep enough, you will find in [`inet/netinet/in.h`](https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=inet/netinet/in.h;hb=HEAD) that `ntohs` is a macro pointing to `__bswap_16`. But without `()`, your preprocessor doesn't know this, so it has to use the library fallback.
Forked from AaronDMarasco-VSI/opencpi
Open Component Portability Infrastructure
C
Forked from stigok/sd-notify
sd_notify and sd_watchdog_enabled client functionality for writing Python daemons
Forked from dixudx/trac-docker
Trac(http://trac.edgewall.org/) Dockerfile
Dockerfile 1
| Back | FazBrowse Home | New Git URL |