HN Gopher Feed (2017-09-07) - page 1 of 10 ___________________________________________________________________
LLVM 5.0.0 Release
144 points by zmodem
http://lists.llvm.org/pipermail/llvm-announce/2017-September/000...___________________________________________________________________
kccqzy - 24 minutes ago
> Added heuristics to convert CMOV into branches when it may be
profitableDoes anyone know why this is the case? I thought CMOVs
are a straight win over branches but I guess modern CPUs might be
more complicated than that.
kraghen - 7 minutes ago
CMOV introduces a data dependency. Predictable branches, on the
other hand, are basically free.
matt_d - 1 minutes ago
"We have seen periodically performance problems with cmov where
one operand comes from memory. On modern x86 processors with
strong branch predictors and speculative execution, this tends to
be much better done with a branch than cmov. We routinely see
cmov stalling while the load is completed rather than continuing,
and if there are subsequent branches, they cannot be speculated
in turn."https://reviews.llvm.org/D36858
0x0 - 3 hours ago
Just in time for Xcode 9? :)
santaclaus - 2 hours ago
Now if only Apple would quit mysteriously stripping out features
from the full LLVM release...
bluejekyll - 2 hours ago
What are they stripping out?
gcp - 1 hours ago
OpenMP, for one. They at least used to strip thread_local
too.
rleigh - 16 minutes ago
Working in scientific software development, I've seen quite
a few people developing on Macs who would really appreciate
OpenMP support. They end up having to use GCC or a vanilla
Clang, but it's extra work and it comes with its own
caveats.
Karliss - 2 hours ago
It seems more likely that they simply don't use upstream
release tags and put their changes and maybe backport some
changes on top of randomly chosen revision. The same way as
Google released Android ndk r15 few months ago with clang
"5.0".The sad part is that their version is neither older or
newer than official release as it doesn't contain everything
from upstream release and upstream doesn't contain all of their
changes yet.
0x0 - moments ago
It can't possibly be pure coincidence that a major llvm
release is timed about one week off from the annual major
apple macOS/iOS/iPhone release?
mhh__ - 3 hours ago
Those LLD benchmarks are looking very impressive! Well done to all
involved.
pc2g4d - 1 hours ago
Better AVR support for Rust? Can anyone comment on this?
hawski - 1 hours ago
Does anyone know the state of the project to compile Linux Kernel
with clang? Does this release help with such a goal?
mirekrusin - 2 hours ago
This is the first time I can see Zig lang [1]. (Self-proclaimed?) C
successor with manual memory management, ironed out edge cases, new
take on error handling (that resembles well written error handling
in C), generics, compile time reflection/execution (macros?),
import .h works directly, exporting to C works directly, nullable
types etc... all sound quite interesting actually. Anybody has
experience/comments on the Zig lang, please?[1] http://ziglang.org/
[deleted]
chubot - 2 hours ago
Previous threads:https://news.ycombinator.com/item?id=12378922htt
ps://news.ycombinator.com/item?id=11060282Actually I'm surprised
that Zig didn't come up on the "Some Were Meant for C" thread,
because this strategy is exactly what I wished something like
Rust had support for (importing header files directly, more
direct support for unit-by-unit translation,
etc.):https://news.ycombinator.com/item?id=15179941
bluejekyll - 1 hours ago
Are you familiar with this?https://github.com/rust-lang-nursery
/rust-bindgenIt will translate a C header into Rust for all
your bindings. Something could probably be built to do this
more on the fly. If it doesn't already exist.edit: docs link
https://docs.rs/bindgen/0.30.0/bindgen/edit2: and I should
mention the inverse, Rust to C bindings,https://github.com/eqri
on/cbindgenhttps://docs.rs/cbindgen/0.1.23/cbindgen/
johncolanduoni - 48 minutes ago
Bindgen is excellent with C APIs but what I've found really
impressive is that it can handle C++ pretty well too. Most of
my issues with using C++ code via bindgen are due to
deviations in calling conventions that are hard to solve at
that level.
kbenson - 2 hours ago
Zig competes with C instead of depending on it. The Zig Standard
Library does not depend on libc.That's an interesting choice.
I'm sure there are other semi-recent languages that have made the
same choice, it would be interesting to hear the benefits and
problems of that approach.I say semi-recent, because there are of
course many from before C or that competed with C and Unix
initially, but unless they are still used much (Lisp?) it's not
necessarily the best for a comparison of modern issues.
anonymousDan - 1 hours ago
Go
kbenson - 1 hours ago
Are you sure? I'm seeing reports that go sometimes wouldn't
run with musl instead of GNU libc, with a runtime
segfault[1]. That seems to depend on libc. Are you saying
that Go's standard library primitives are not shims (or more
complex structures) built on top of libc?1:
https://github.com/golang/go/issues/14476
Matthias247 - 1 hours ago
Go uses libc optionally (for some things like DNS
resolving). You can build Go programs which do not utilize
libc by disabling cgo and building static binaries. By
default the biggest part of Gos stdlib isn't based on libc,
but some small parts are.
badsectoracula - 2 hours ago
Free Pascal has its own standard library that talks directly
with the underlying OS too.
minxomat - 2 hours ago
Wow, that looks awesome. The syntax is pretty much what I look
for in a language, much more approachable to me than Rust. Will
tinker with it.
Rusky - 2 hours ago
The syntax actually looks fairly similar to Rust, just with
generics replaced with `comptime`. What do you find more
approachable about it?
jandrese - 2 hours ago
Interesting. I've been somewhat disappointed with Rust thus far
and this looks a lot more like what I was hoping for.
kbenson - 2 hours ago
What did you find disappointing? What were you hoping for (so
I can compare it to my own hopes)?Rust is the one (out of Rust,
Nim and D) that looks most promising to me from the outside for
my goals[1], but I haven't really settled on one to devote my
very limited free time to.1: If I'm going to drop down from a
high level dynamic interpreted language to a low level strongly
typed compiled one, I might as well got the extra distance Rust
is asking for the gains it promises.
jandrese - 32 minutes ago
Mostly I ran into a lot of friction with shared data
structures that are being accessed by multiple threads.
Stuff like ring buffers, flow state databases, and similar
systems.There's probably Rust ways to do that stuff, but it
was not obvious to me.
littlestymaar - 5 minutes ago
If you're able to write a robust shared ring buffer in C,
you should be able to do the exact same implementation in
unsafe Rust using raw pointers, declare it as Sync and use
it from safe Rust with no issue. Or am I missing something
?Or, if you're like me and not confident enough to do this,
you could check on crates.io[1] to see if no available lib
already does what you need. In which case you basically
have it for free.[1] https://crates.io/keywords/ring-buffer
KenoFischer - 2 hours ago
One feature I'm excited about in this release is proper support for
non-integral address spaces. Allows us to do significantly more
optimization in the presence of GC roots in Julia.
rui314 - 2 hours ago
> ./configure scripts generated by GNU autoconf determines whether
a linker supports modern GNU-compatible features or not by
searching for "GNU" in the --help message. To be compatible with
the scripts, we decided to add a string "(compatible with GNU
linkers)" to our --help message. This is a hack, but just like the
web browser's User-Agent string (which everyone still claim they
are "Mozilla/5.0"), we had no choice other than doing this to claim
that we accept GNU-compatible options.http://releases.llvm.org/5.0.
0/tools/lld/docs/ReleaseNotes.h...Even though I wrote it, I found
this part a bit funny. Configure scripts are hacky by their nature,
and we needed another hack to make their hack work. I'm not happy
about that though.
chubot - 2 hours ago
Yup, this is why feature detection is better than version
detection.jQuery changed their strategy in 2009:
http://blog.jquery.com/2009/01/14/jquery-1-3-released/"No More
Browser Sniffing"Also, autoconf has a lot of faults, but as far
as I recall it's firmly based on the philosophy of feature
detectino vs. version detection.Maintainers of packages can write
bad custom checks that test for features, but if you use the
built-in autoconf checks, they're all about features.CMake on the
other hand seems to use version detection more, which I don't
like.
wvenable - 2 hours ago
It helps when you have a platform that supports feature
detection reliably. Most platforms don't have that lucky
accident.
chubot - 2 hours ago
What's an example where of a feature of cc or ld that you
can't detect with feature detection?Shell scripts are turing
complete and can do arbitrary I/O. In theory you can write a
feature detection for any feature by compiling, linking, and
running a test program. If the feature couldn't be detected
this way, then it would be useless.Likewise, JavaScript and
DOM features should always be detectable by eval(). I guess
one instance where it's impossible is if the API changes the
pixels on the screen and does nothing else.Although you can
actually detect this in some cases with JavaScript!
JavaScript can leak information through the colors of
attributes on the screen, e.g. you can tell if a user visited
a site by looking if the link is purple!
derefr - 1 hours ago
> In theory you can write a feature detection for any
feature by compiling, linking, and running a test program.
If the feature couldn't be detected this way, then it would
be useless.It's hard to do feature-detection against cross-
compilation toolchains, since "toolchain" doesn't imply a
standardized emulator/debugger component for the resulting
executables. Under cross-compilation, you can detect that
your test programs compile and link, but you can't run
them!This, if you're wondering, is why SDKs for embedded
architectures always seem stuck in the time before
autoconf/cmake were invented: without feature-detection
support, such toolchains (and the projects developed for
them) have to get by with manually-written Makefiles.This
is also why the more modern game console SDKs (such as the
Wii U SDK, my own most recent experience) are delivered as
components that slide into an IDE like Visual Studio,
rather than as standalone CLI toolchains for an IDE to
drive. This way, they do have a (proprietary) standard way
to add an emulator/debugger component, which can then serve
as a core for the IDE's build system.
chubot - 34 minutes ago
Yes good point. Though I think most features can be
tested without running a program -- e.g. testing if a
library function exists or has a certain signature.I
think embedded toolchains use plain makefiles because
they tend to fork code rather than upstream changes. And
that is due to the ship-it-and-forget-it mindset of
embedded companies that is well known among open source
maintainers.
0x0 - 1 hours ago
No modern browser lets you know the state of a:visited and
will lie to you if you query for colors etc. In fact if you
can find a way for js to determine if a link has been
visited you are likely qualified for $$$ bug rewards (which
has happened)
chubot - 39 minutes ago
Ok thanks for the info, that makes sense!
vosper - 1 hours ago
That's not really feature detection, though.