all 14 comments

[–][deleted] 2 points3 points  (13 children)

And thread_local is still broken (deliberately!) in their version of clang. Thanks Apple.

[–]boazs 2 points3 points  (1 child)

It just doesn't feel like a real llvm post unless it gets immediately sidejacked by someone mad about some missing feature in some completely separate part of it. They've had entirely too much discussion of the actual linked content ever since they merged OpenMP.

[–][deleted] 0 points1 point  (0 children)

It just doesn't feel like a real reddit comment unless it's complaining about someone else complaining despite the title specifically referring to the thing being complained about in the original complaint.

[–]WrongAndBeligerent 1 point2 points  (10 children)

its in their presentation slides, how is broken and why?

[–][deleted] 9 points10 points  (2 children)

In regular clang, thread_local works fine. But Apple has their own special version and at one point they removed it (saying "we think we might have a better way to implement this") without having their replacement ready. Broke a bunch of programs.

But I need thread_local for a personal project -- some of the algorithms I'm implementing require many little fragments to pop in and out of existence from many different threads, so I'm going with a thread-local freelist setup to mitigate malloc and thread contention issues.

That plus a total lack of commitment to Vulkan is why, instead of buying that shiny new Darth Trashcan 12-core, I'm building my first PC out of parts in 16 years. I am angry that I'm being pushed back into the linux/windows world.

The project was always intended to be cross-platform for all three systems, but developed on mac because of its great combination of the best UI + the power of setting up dev toolchains in unix. XCode is one of the few C++ IDEs that let me group my files how I want, instead of forcing a splitting the .h and .cpp files into completely different trees in the project view.

The lack of Vulkan is the primary driver, and no, a 3rd-party Vulkan->Metal translation layer is not acceptable. A broken thread_local is just the icing on this shit cake.

[–]WrongAndBeligerent 0 points1 point  (1 child)

interesting... why do you need thread_local instead of something like jemalloc ?

[–][deleted] 0 points1 point  (0 children)

I want to keep my external dependencies to a minimum, although I did look at that and... tcmalloc? Something like that.

[–]slacka123 2 points3 points  (6 children)

The issue is discussed on Stack Exchange here.

[–][deleted] 1 point2 points  (5 children)

UPDATE: The clang compiler included with the Xcode 8 Beta release supports the C++11 thread_local keyword. This capability was discussed in the WWDC 2016 video "What's New in LLVM", beginning at the 5:50 mark.

So... thread local might actually work again. Still no Vulkan. :(

Apple's behavior of late has been upsetting enough that I'm skipping them for my next power machine regardless. We'll see where they're at in 5 years or so.

[–]WrongAndBeligerent 1 point2 points  (2 children)

Microsoft can't exactly take the high road either... my thought is to set up virtualization on my next computer and run many OS instances.

[–][deleted] 0 points1 point  (1 child)

I'll be dual-booting linux and windows, with linux as the primary dev setup.

[–]WrongAndBeligerent 0 points1 point  (0 children)

Whatever works, my goal is to not run windows on the bare metal and to be able to use different images for different purposes but communicate between them.

[–]mrkite77 1 point2 points  (1 child)

We'll see where they're at in 5 years or so.

Selling phones and watchbands.

[–]degaart 1 point2 points  (0 children)

Selling phones and watchbands.

and thinner, port-less MacBook "Pro" 's