[HN Gopher] Trip C++Now 2024 - think-cell
___________________________________________________________________
Trip C++Now 2024 - think-cell
Author : coffeeaddict1
Score : 75 points
Date : 2024-05-10 09:06 UTC (1 days ago)
(HTM) web link (www.think-cell.com)
(TXT) w3m dump (www.think-cell.com)
| gpderetta wrote:
| > Google does not use std::ranges for many reasons, including
| performance, the ability to create dangling references, and a
| cubic stack blowup when deeply nesting some range adapters like
| std::views::filter
|
| I remember discussing this exact problem for boost range in the
| boost mailing list almost 20 years ago. My proposal was to make
| ranges be their own thing and generate the iterators on the fly
| when begin/end was requested, instead of always storing them
| internally. But I think it was not considered a big issue in
| practice.
|
| Today we have sentinel end-iterators that can be stateless, so it
| should be possible to avoid blowout without fundamentally
| rethinking ranges.
| menaerus wrote:
| My, admittedly, not so big experience with std::ranges is that
| they generate an abnormal binary bloat in comparison to the
| traditional code, so, I also tried to argue against their usage
| in one my ex-teams who, paradoxically, wanted to achieve tight
| execution on platforms with tight resources.
|
| Another paradox was that the exceptions were disabled because
| of reasons while at the same time std::ranges (range-v3)
| implementation did not support this. I wonder how Google solved
| this problem since AFAIK they also disallow exceptions.
| tialaramex wrote:
| > cubic stack blowup when deeply nesting some range adapters
| like std::views::filter
|
| I have no doubt this observation is true, but I haven't been
| able to picture it, can somebody explain? I don't think ELI5
| (let alone an explanation suitable for a Golden Retriever) will
| work here, but in terms that say a C programmer would grasp.
| What exactly gets shoved onto the stack when we're using a
| std::views::filter ?
| menaerus wrote:
| https://schedule.cppnow.org/wp-
| content/uploads/2024/02/Rappe...
|
| Slide nr. 21 (nr. 26 in PDF).
| tialaramex wrote:
| Thanks but I saw the numbers, however to me the numbers
| just say "It's terrible" and leave me with the same
| question I had before, what's actually on the stack ? It's
| not going to just be empty space left there as a joke, are
| there... cached values? Pointers to something (what?). I
| suspect it's supposed to be obvious but I don't get it.
| menaerus wrote:
| According to
| https://en.cppreference.com/w/cpp/ranges/filter_view
| return value of views::filter is either a new
| ranges::view or some sort of range adaptor that seems to
| be equivalent to a ranges::filter_view.
|
| I can only guess that it is those return values that are
| temporarily put on stack so that the consequent |
| operations could be chained. My hypothesis, without
| knowing much about this stuff, is that since the compiler
| cannot elide them (according to the godbolt link from the
| presentation), stack usage, as found by Google, has cubic
| growth. I don't quite understand why since I guess it's
| expected to grow linearly, e.g. 48 bytes at a time.
| quuxplusone wrote:
| My "Eric's Famous Pythagorean Triples" blog post is 5+
| years old and possibly not addressing _exactly_ the same
| issue as think-cell /Google cares about, but, you might
| still be interested to read it: https://quuxplusone.githu
| b.io/blog/2019/03/06/pythagorean-tr...
|
| In my case, the blowup happens mainly because the Ranges
| style tends to turn easily fungible code like `if x < y`
| into relatively non-fungible data like the capture-list
| of `[y]() { return x < y; }`. The former is easily
| subjected to optimizations like the hoisting of loop
| invariants; the latter is not. Another way to put this
| is: The compiler is happy to mess with the layout of the
| function stack frame up until the very last minute; and
| to mess with the coroutine frame almost as long; but the
| layout of a lambda (or std::bind) capture frame is set-
| in-stone very early, by the front-end. And Ranges loves
| lambdas.
| gpderetta wrote:
| The naive implementation of range would have a range
| represented of a pairs of iterators, with every iterator
| containing a copy of each upstream range, which blows up
| quadratically; libstdc++ implementation is not
| implemented this way though: each range has one copy of
| the upstream range plus the predicate, while this could
| be optimized further for stateless predicates, the range
| growth should still be linear.
|
| Yet, when I print the final size of the chained filter
| ranges and I saw it increasing superlinearly with the
| number of stages, so I must be missing something.
|
| There is also additional wasted stack space for each
| temporary range. In theory the compiler should be able to
| optimize them away, but it probably doesn't always.
| panstromek wrote:
| Since C++ ranges kinda look like Rust iterators, but I believe
| Rust doesn't have this problem, can somebody explain why?
| What's the difference? Or maybe it also has that problem?
| tialaramex wrote:
| I expect (but I'm not sure) it's because Rust iterators are a
| deliberately thinner, less powerful idea. Suppose I give you
| a Rust iterator A and a C++ range B.
|
| You can ask A for the next() item and get back an
| Option<Item>, this literally iterates as an inherent part of
| getting your answer, there's no current() or previous() and
| there's no separate finished() if you ran out of items you
| got None instead of Some(item). A can be asked for a hint
| about how much is left, but it's allowed to say it has no
| useful idea: between zero and more than you can count,
| inclusive.
|
| B is expected to provide a richer, albeit unsafe, API.
|
| I believe somehow this means it's only reasonable for B to
| cache answers, as it can be asked to give the same answer
| again and it'd be inefficient to re-calculate it, whereas
| there is no way to ask A to repeat an answer so it makes no
| sense for it to cache (obviously there are special purpose
| Rust iterators which can have any feature, but the Iterator
| trait itself doesn't need to cache).
| panstromek wrote:
| hm, so I tried this on the playground and it seems like Rust
| iterators also scale super-linearly in debug mode (which is
| expected, because every adaptor creates a new local that
| contains the previous one plus something extra), but this
| seems to go away in release mode (as everything is inlined).
| Is the problem in C++ something different?
| jcelerier wrote:
| it's exactly the same behaviour in C++. but people are used
| to this behaviour in Rust while in C++ they're used to
| writing traditional for-loops which do not have such an
| overhead at -O0 over -O3
| pornel wrote:
| Rust's iterators are single-use streams of items, and nothing
| more.
|
| A Rust iterator can be fully implemented by a closure that
| either returns the next element or signals it's done. This
| minimalist interface composes well, especially that it always
| uses single ownership, so there's always only one copy of the
| state accessed only from one place.
|
| They can't describe collections. They don't remember their
| beginning. They don't need to know their end until they reach
| it. They can't be sorted. They don't need to support
| splitting or iterating in reverse.
| thom wrote:
| Rappel sounds very similar to Clojure's transducers in spirit and
| implementation.
| ho_schi wrote:
| Regarding the addition to libxx: I'm not fond of adding an
| increasing number of specific compiler options which need to be
| turned on for memory-safety. It should be default whenever
| possible. What do you think?
|
| I love _-faddress=sanitizer_ or _-fsanitize_. The historically
| growing number of warnings which should be turned on are an
| issue. For example the options -Wconversion, -Wsign-conversion
| and -Warith-conversion shall be default with _C++XX_. And if your
| code doesn't compile, fix it, use and older revision or turn it
| deliberately off (saying: I'm aware, read the handbook, I take
| the risk). Doing such changes with language revisions allows
| people to take notice about it without surprise.
|
| I want some ideas of CPP2/cppfront[1] in C++XX. Finally using
| _#unsafe_ when needed, like Rust. C++ does evolve over decades,
| more like other languages.
|
| [1] https://github.com/hsutter/cppfront
|
| BTW. Use the AddressSanitizer. Please! The toolchain improved the
| usage and safety of the language so much. It wasn't available
| twenty years ago but it is now.
| repelsteeltje wrote:
| I think what you're looking for are _profiles_.
|
| - https://github.com/BjarneStroustrup/profiles
|
| Ie. rather than a bunch of tools helping you find undefined
| behaviour (or left-and-right improvements of what the behaviour
| should be) you'd like to be able to make high level claims
| about your code and have the compiler validate those
| guarantees.
|
| C++ having a huge C++ legacy, things of course are never easy.
| So for the time being this is just work-in-progress.
| pjmlp wrote:
| First of all they have to be designed and voted in.
|
| If WG21 is actually open to having them, ISO C++29 is
| probably when they might land, then given the compiler
| velocity with previous standards, expect at least 5 years to
| mature, on the top three, let alone everyone else.
|
| If I am not dead by then, I will certainly be retired.
|
| How long will the industry be willing to wait for profiles?
| tialaramex wrote:
| I _think_ the compilers would be allowed to just make your
| default warning changes as non-fatal diagnostics aren 't a
| conformance matter. So you probably need to lobby GCC, Clang
| and MSVC.
|
| Herb's discussion of "unsafe" for Cpp2 is... misleading. Rust's
| unsafe _does not turn off checking_. If you take some safe Rust
| which compiles (even if it panics) and you just wrap that in a
| block with the unsafe keyword, _all you get_ for your trouble
| is a new diagnostic (by default a warning) saying not to do
| that because it 's futile to use an unsafe block here. No
| checks are switched off, no "performance" shortcuts are added,
| if it would panic before it still does now - it's just the same
| code with a frivolous "unsafe" sign on it.
| jonhohle wrote:
| Swift does this, but their release cycle is currently more
| frequent and the roadmap is (possibly) more clear.
| Paraphrasing: Warning: <Certain undesirable
| behavior> will be an error in Swift <Version
| + 1>.
|
| I'm not sure if it's an huge improvement, but it's easy to
| block all forward warnings with `-Werror` to clean up right
| away.
| vlovich123 wrote:
| both c++ and Rust emit these kind of warnings to deprecate
| previously allowed constructs that are deemed undesirable,
| but I don't follow how it relates to this particular topic
| planede wrote:
| > BTW. Use the AddressSanitizer. Please! The toolchain improved
| the usage and safety of the language so much.
|
| In general I agree with the sentiment, use AddressSanitizer in
| testing/debugging. However it's not meant to be a hardening
| option, AFAIK, so I advise against using it in production
| (along with other sanitizers), even if you can live with the
| performance hit.
| ho_schi wrote:
| Yep.
|
| Theoretically it is possible but _libasan_ is not intended
| for linking or shipping in production. Also stuff like
| LeakSanitizer[1] actually cannot [1] be used with GDB.
|
| While shipping debug symbols is something I recommend and has
| no side-effects aside from mere file-size (debug symbols are
| only loaded when used).
|
| Usual exceptions apply as you encounter them.
|
| [1] https://github.com/google/sanitizers/issues/857
| jokoon wrote:
| Think cell is the company the creator of lexy works at
| quuxplusone wrote:
| If you mean https://github.com/foonathan/lexy , then yes,
| foonathan (Jonathan Muller) is literally the "I" in the first
| sentence of TFA.
| jokoon wrote:
| oh indeed, I had not scrolled enough!
| AnonSixOneTh wrote:
| I'll say this because it needs to be said. Recently it seems like
| every developer on LinkedIn who has "C++" in their profile, and
| their cat, is spammed every couple of weeks by some recruiter
| with a "great opportunity, 130,000 euros FULLY REMOTE", turning
| out eventually to be recruiting for think-cell.
|
| I got it, my friends got it, my work mates got it, everyone gets
| spammed periodically, it has become the laughingstock of job ads.
|
| Why? Read the Glassdoor reviews. The CTO is a terrorist obsessed
| with complexity, they overengineered themselves into a corner by
| using every freaking C++ feature that ever existed, making sure
| that there's only 3 or 4 people in this world who can understand
| their code. Of course the usual pattern goes: guy learns #feature
| on-the-fly appearing both incredibly smart and embelishing his
| resume, until of course reality hits and the complexity of the
| crap he wrote outclasses his "genius" intellectual capacity so
| then he leaves, leaving the mess for future hires to deal with.
|
| Consequently there's maybe 3 people left in this world capable to
| understand the atrocity that's running there, not saying fix it.
| So good luck finding them. These people, if they exist, already
| work for more that $130k.
|
| Also, why do they need the absolute raging brinking edge of C++
| features? What does this company do? Trillion dollar ultra low
| latency / high throughput high frequency trading? AAA+ games
| running on 4 x 4k monitors at 200+ fps?
|
| No. They do some farty charts.
|
| Again. Good luck with the recruitment! :)
| lbhdc wrote:
| That kind of sounds like a lot of code bases I have worked in.
| Once you get some many people on a project things can get
| messy. Perhaps its a sign they have some DX and tech debt they
| should address.
|
| As for why the latest version of c++? Personally I have found
| the dx improvements of some of them to be worth the upgrade. I
| really like constexpr and the build time errors it gives
| (opposed to runtime). The newer standards let you use constexpr
| in more places with more stl types.
| CoastalCoder wrote:
| It does make "C with classes" sound pretty appealing.
|
| Well, maybe also with some very limited template facilities.
|
| Shoot... Did I just describe Ada95 somewhat?
| pixelpoet wrote:
| As a C++ dev in Germany, experienced this firsthand. They make
| you do some truly ridiculous tests, and in the end 130k isn't
| that far off from somewhere like Maxon where you actually do
| interesting work. Having spoken to others who applied, both in
| person and via easily found reddit thread on r/cpp, 100%
| certain I would have been absolutely miserable there, and
| everyone mentions the CTO.
| Rinzler89 wrote:
| _> 100% certain I would have been absolutely miserable there,
| and everyone mentions the CTO_
|
| But..but.. think-cell says that:
|
| _" Our CTO Arno maintains a close working relationship with
| all of our developers. Together, they review code,
| troubleshoot, and brainstorm. Most likely due to Arno's and
| Markus' academic roots, think-cell is flourishing without
| program managers and lengthy meetings."_
|
| Those are all the traits of a good manager and pleasant work
| environment. And you get to work in Berlin!
| intelVISA wrote:
| > flourishing without program managers and lengthy meetings
|
| EUR130k for a good C++ dev is a steal in most markets, but
| I can see this 'perk' as a huge draw for people tired of
| shops where "bringing key stakeholders into conversations
| at the appropriate time" is valued over simply building
| product.
| Rinzler89 wrote:
| _> EUR130k for a good C++ dev is a steal in most
| markets,_
|
| In most markets? Definitely not.
| chipdart wrote:
| > EUR130k for a good C++ dev is a steal in most markets
| (...)
|
| To reign you back to reality, in Europe not even FANGs
| pay that kind of salaries. They only pay that kind of
| cash to senior and staff-level engineers.
| f1shy wrote:
| This is the description of at least 50% of the C++ projects
| where I was involved with. Only missing the language lawyers
| citing paragraphs of the standard at least once a meeting.
| Scubabear68 wrote:
| Oh how I miss the language lawyers in C++. Some really
| elevated it to a high calling. </s>
| TeMPOraL wrote:
| They got obsoleted by clang-tidy.
| nuancebydefault wrote:
| Finally somebody on HN getting attention for mentioning this
| sad truth.
|
| Usually even the least criticism on this 'holy' language [that
| emphasizes 'intent' and glorifies people who truly understand
| 'const correctness!' and the correct usage of dynamic_cast]
| gets immediately downvoted.
|
| The sad truth being, tons of impossible to understand code
| bases exist in the wild, due to, for example, the mix of old,
| less old and new memory handling strategies having been
| applied.
| SassyBird wrote:
| Same. I and a couple of my colleagues got offers.
|
| Regarding love of complexity and C++, they're sitting on the
| C++ committee. Complexity is their bread and butter. :)
|
| I also kinda doubt "Trillion dollar ultra low latency / high
| throughput high frequency trading/AAA+ games running on 4 x 4k
| monitors at 200+ fps" people are such enthusiasts of the
| bleeding-edge of C++. The standard library and the style of
| programming popular in the committee isn't very concerned with
| high performance it seems.
| chipdart wrote:
| > Regarding love of complexity and C++, they're sitting on
| the C++ committee. Complexity is their bread and butter. :)
|
| To me the think-cell guys sound like they are gung-ho on
| clout-chasing, to the point that this side of theirs even
| eclipses their own products and services.
|
| It sounds they got the whole point of software engineering
| entirely backwards: their goal is to pile complex tech
| showcases in their product line and presentations as a proxy
| to being competent in their field,and instead they
| unwittingly put together unmaintainable and convoluted code
| that requires a high cognitive load just to troubleshoot the
| simplest issues.
| nxobject wrote:
| Truly, it's far from reassuring that the rest of think-cell's
| developer blog is more about "modern C++" debates on style and
| pitfalls ("Should we stop declaring functions and use global
| constexpr lambdas instead? Consider argument-dependent
| lookup...") than about developing their product.
| ano-ther wrote:
| The yelling CTO and the Glassdor reviews are certainly a red
| flag for potential employees.
|
| But the company itself is interesting.
|
| They built an add-on for PowerPoint for which they charge more
| than MS charges for the entire Office Suite (my company pays
| around EUR130 per year and user).
|
| With a million users served by approximately 20 devs they are
| very profitable, which they highlight in their job ads.
|
| As a small company with a relatively boring product, they need
| to do something to attract new people. And they can afford to
| approach every c++ programmer individually, support community
| efforts (standards committee) and sending people to Aspen for a
| conference. They might be a little clumsy so their recruiting
| comes across as spam.
|
| As for latest c++ features not being appropriate: as a user, I
| don't care as long as the product works as intended, which it
| has been doing for me since over 10 years now.
| htoweasdf wrote:
| I created a similar sum type during high school detention but
| type order didn't seem possible at the time. I'm glad someone
| else has eyes on it.
|
| I unfortunately don't write C++ anymore because the TC is too
| low. It's sad that Python and JS pay more.
| lionkor wrote:
| Did their 4-9 hour(!) mandatory take home coding test. Never done
| such a terrible test in my life; in every way they made a test
| akin to basically locking a c++ dev in a room for anywhere
| between 4-9 hours and afterwards rolling a die.
|
| Its underspecified, but then has automated tests, that, after
| failing twice, automatically reject you as a candidate. Of course
| it doesnt give examples or example test cases or real test cases,
| so you're shit outta luck trying to solve it. The challenge
| itself would be fun and solvable in 4 hours, but around the 2
| hour mark you start having questions and from there its just bad.
|
| You can google this coding test ("think-cell interval_map") and
| youll get a lot more info.
|
| I complained to them just in case they cared, and they did seem
| to care, but failing to specify an automatically tested coding
| challenge is the kind of psycho shit you do if you think youre
| the smartest guy in the room (but arent).
|
| ETA: To be clear, I stopped the second I realized it was an
| underspecified test. I'm not that mad, just mad I fell for
| spending a whole saturday morning doing it, without ever talking
| to anyone there in a call or anything.
|
| That and the fact that theyre just building a powerpoint plugin
| and seem to overcomplicate it to such a massive degree: Yeah no
| thanks.
___________________________________________________________________
(page generated 2024-05-11 23:02 UTC)