GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
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.