[HN Gopher] Cinder: Instagram's performance-oriented fork of CPy...
___________________________________________________________________
Cinder: Instagram's performance-oriented fork of CPython
Author : yagizdegirmenci
Score : 121 points
Date : 2021-05-04 21:38 UTC (1 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ram_rar wrote:
| There is a lot of value in leveraging existing programming
| languages than rewriting in something else. My team rewrote large
| chunks of code from python -> Go and it wasn't a pleasant
| experience. We were able to justify it, since it _inadvertently_
| reduced our infra cost.
|
| But, if we could make python a lot faster at compiler level, it
| doesn't break the dev experience and lengthen dev on-boarding
| time. This helps the team productivity as a whole. I hope the
| CPython community is able to leverage few things from Cinder.
| This would benefit the entire python community.
| sergiomattei wrote:
| Yes, yes, yes! This is what I've been waiting for so long.
|
| Python has emphasized readability for the reference
| implementation vs. the practical benefits of better performance
| for everyone, and the community is really hurting for it.
|
| Please CPython, upstream this or something like it. There reaches
| a point where this whole zeal about readability becomes
| idealistic and hurts real-world pragmatic goals. It's hurting the
| language and we can do better.
|
| Python can be ahead in the performance race. We just need to get
| real.
| EmilStenstrom wrote:
| tldr: Static Python plus Cinder JIT achieves 7x the performance
| of stock CPython
| miohtama wrote:
| This is meaningful for some big web workloads. By cranking up
| your Python codebase performance you can avoid expensive
| rewrites in harder to maintain languages.
| nerdponx wrote:
| I wonder why Cinder and not building off of PyPy. Isn't there
| also a GraalVM implementation?
| _carljm wrote:
| We tried PyPy without much success (and we really tried, six
| month project just to get it to run our codebase.) Our
| workload is very heavy on the CPython C API, which makes life
| difficult for PyPy or any other alternative Python
| implementation. PyPy is great for a lot of uses, just not a
| great fit for us.
| varispeed wrote:
| > We don't have the capacity to support Cinder as an independent
| open-source project
|
| But they had capacity to appropriate CPython?
|
| Make billions out of open source software and then throw back a
| rag? "Here look we made this! How cool we are. See if you can
| find something for yourself and we might have _a conversation_"
| Man this is some next level entitlement.
|
| If they are making so much money out of it, the should have some
| decency and contribute stuff back to CPython and not just
| throwing things like this. This is offensive and disrespectful!
| kristjansson wrote:
| This seems unnecessarily cynical. The large block of caveats
| seems mainly designed set expectations for potential users
| about the level of (total lack of) support.
|
| Using (and modifying!) a piece of software in accordance with
| its license is not appropriation, it's the point of open
| source! Users - even corporate users - are free to make changes
| to suit their needs and aren't required to seek anyone's
| permission do so. All changes do not need be contributed back
| to the parent project, especially if (as the sibling comment
| notes) the changes don't align with the goals and values of
| parent.
|
| That this hacked-up internal fork is even seeing the light of
| day is a Good Thing.
| varispeed wrote:
| Open source was never meant for "corporate users". The spirit
| of open source was to create free alternative to expensive
| software so that disadvantaged people could also participate
| in a digital revolution. The whole movement was then
| appropriated by big corporations when they found out the
| developers will do the R&D work for free (so corporations
| don't have to pay salaries and taxes on the work done) and
| then if any of the projects become valuable they can just
| take it and use for their own purposes, make money and never
| pay original developers anything whatsoever. Of course some
| companies felt guilty and offered jobs to those developers -
| but when you compare how much money they made on the software
| vs what kind of salaries they pay, it's pure simple
| exploitation. The whole open source movement currently is
| designed to exploit developers and is a mean for companies to
| avoid paying for labour.
| rpolx wrote:
| Pity this is down-voted. Corporate devs earning > 250.000
| per year are purging this thread to keep the narrative and
| their salaries.
| tick_tock_tick wrote:
| CPython explicitly doesn't want these "improvements" CPython
| has explicitly declined performance boosting pull requests if
| they add too much complexity to the code base. The two project
| have very different goals.
| mgraczyk wrote:
| Instagram upstreams a lot of changes to cpython, and most of
| the IG backend runs on services outside of python/Django.
|
| I think you have the entitlement characterization backward
| though. It is entitled to think people should do work for free
| so that you can use the output of their work. IG is saying "we
| built this stuff, we're making it open source". They are not
| asking for or expecting anything from the open source community
| or you, but you are asking for a lot (millions of dollars worth
| of work) from them.
| whoknowswhat11 wrote:
| Exactly - totally pathetic. Seriously - what are you
| contributing in terms of engineering budget? Nothing? Then
| stop bothering contributors to open source.
| kbenson wrote:
| > I think you have the entitlement characterization backward
| though. It is entitled to think people should do work for
| free so that you can use the output of their work.
|
| That depends on the license, though. It's not entitlement to
| think that someone that builds on something open _must_
| release it back if the license requires it. That 's one of
| the main differences between the BSD license and some GPL
| variants.
| totoglazer wrote:
| It's not obvious CPython wants any or most of this stuff.
| deadmutex wrote:
| In these cases, I try to think "Don't let perfect be the enemy
| of the good".
| minhazm wrote:
| What a ridiculous conclusion you came to based on a single line
| from that page. The very next line says:
|
| > We've made Cinder publicly available in order to facilitate
| conversation about potentially upstreaming some of this work to
| CPython and to reduce duplication of effort among people
| working on CPython performance.
|
| > Our goal in making this code available is a unified faster
| CPython.
|
| Facebook is a Python Software Foundation sponsor[1], and they
| sponsor every PyCon. I don't know why you got the idea that
| they don't contribute back.
|
| https://www.python.org/psf/sponsorship/sponsors/
| 3v1n0 wrote:
| Yeah but also... "If you want to upstream it, take it" it's
| not really something where ehi forked is working hard to send
| it back upstream patch by patch...
| _carljm wrote:
| We've already upstreamed a lot of changes, including one
| that makes all coroutines faster in Python 3.10. The big-
| ticket items in Cinder would be big changes for CPython and
| need discussion about whether CPython even wants them. You
| don't just slap a C++ JIT into a bugs.python.org ticket.
| Opening Cinder is the first step in the conversation, and
| we're here for that work too. It's not just "if you want
| it, take it."
| bgfellows wrote:
| The PSF has not really sponsored CPython so far, and PyCons
| are for self promotion.
|
| Often in OSS foundations the entire sponsorship money goes to
| people who don't deserve it.
|
| Please do not attach any meaning to corporate sponsorship of
| foundations unless you can point to a specific project.
|
| 99% of CPython has been written by individuals without any
| compensation who don't get any credit. When a corporation
| gives money to non-productive bureaucrats everyone thinks
| they are helping open source. It is very sad.
| KptMarchewa wrote:
| Agreed with your comment. There are public reports of PSF,
| 75% of expenses go to US PyCon.
|
| https://www.python.org/psf/annual-report/2020/
| dmpayton wrote:
| This is typical of Facebook.
|
| Years ago, Facebook maintained a Python SDK for their API. One
| day, with no warning, Facebook announced they would no longer
| support it because they didn't have the resources, and the repo
| was removed from their Github org, which caused a huge
| headache. IIRC, the community settled around someones fork.
|
| A few months later, Facebook was a major sponsor of PyCon and
| they set up a recruitment booth. "We'll take your developers,
| but we won't support your ecosystem." Really rubbed me the
| wrong way.
| djstein wrote:
| not trying to throw sympathy here for Facebook, but the team
| that owned that Python SDK was probably not at all related to
| the PyCon recruitment booth. Big organization, at least
| someone was trying to do the right thing
| dang wrote:
| Please don't take HN threads into flamewar. We're trying to
| avoid that here.
|
| That goes 2x for generic tangent flamewar (which this is), and
| 10x for generic ideological flamewar (which this arguably is).
| Please avoid!
|
| Also, please avoid name-calling and fulmination generally. You
| can make your substantive points without any of the above!
|
| All this is in the site guidelines:
| https://news.ycombinator.com/newsguidelines.html
| savant_penguin wrote:
| Really freaking cool
|
| Did anyone find the benchmarks
| _carljm wrote:
| There'll be a talk on Cinder at (virtual) PyCon in a couple
| weeks, there are detailed benchmark numbers in the talk. We've
| talked about getting them into the repo too, might happen.
| latenightcoding wrote:
| I wonder how many other companies do something like this. most
| popular compilers/interpreters could be faster if backwards
| compatibility and portability was not important.
| deadmutex wrote:
| I wonder if they are in touch with kmod or tried pyston:
| https://blog.pyston.org/.
| _carljm wrote:
| Haven't tried Pyston, its revival as an active project happened
| well after Cinder was in production.
| smg wrote:
| Was Cinder influenced by hhvm (Facebook's vm for php/hack)? A
| project that maintains a list of different JIT implementations
| for programming languages and compares them would be a great way
| to see what are the different approaches to implementing JITs and
| which language features make it hard to implement performant
| JITs.
|
| As an aside it is great that the Cinder team is specifically
| calling out that Cinder is not intended to be used outside of FB.
| Many people have been burned by lack of community around hhvm.
| _carljm wrote:
| Definitely influenced. There are people on our team who also
| worked on hhvm.
| boomer918 wrote:
| This is awesome, a lot of knowledge shared in that code, and lots
| to learn from I'm sure.
| dukeofdoom wrote:
| My experience with Django was that the larger the project got,
| the more I wanted to bypass it and just work directly with the
| database.
| msoad wrote:
| I love how Facebook and Instagram never went the route of "full
| rewrite" for their apps as they scaled.
|
| I my experience "Language X is slow and we could save Y switching
| to Z" is always a false promise. You can pick parts of the system
| that are costing a lot and port them to other language/frameworks
| to capture the bulk of savings while keeping your developers
| happy working on familiar code. Or if you'e big enough like
| Facebook, you can go see why X is slow and if it is possible to
| improve at the compiler level. Never disrupt the developers flow
| (Twitter did this with their Scala craze back in the day)
| nemothekid wrote:
| I'm not sure many companies have the luxury of doing what FB
| did. I can't imagine a world where choosing to rewrite your
| app, or choosing to rewrite _the entire language_ , where
| rewriting the entire language would be the cheaper solution.
|
| Twitter did this with their Scala craze, but Twitter struggled
| to scale it's Ruby app. Twitter didn't have nearly as deep
| pockets to write a performant alternative Ruby VM.
| flakiness wrote:
| Yeah, it kind of reminded me the "python strict mode" they
| talked about before [1]. No designed to be cool but to be
| useful.
|
| [1] https://instagram-engineering.com/python-at-scale-strict-
| mod...
| halfmatthalfcat wrote:
| Did Twitter actually contribute to Scala core though? They
| definitely created and contributed to various Scala libraries
| but they didn't fork/augment the Scala compiler like Facebook
| did with HipHop.
| spullara wrote:
| They did contribute to the JVM but directly, not by forking
| it.
| neya wrote:
| I disagree, this logic doesn't work always unless you have
| investor money lying around. For a bootstrapped business, it
| could mean living or dying. As an example, a client of mine was
| paying close to $5000 per month in server costs simply because
| of the scale of traffic they had on their site. By re-writing
| Wordpress in Elixir, I was able to bring their costs down to
| $1000 odd per month. It's actually cheaper than what any of
| their competitors are paying for, in servers as well.
|
| This $4000 in savings actually allowed them to hire an
| additional full time developer to maintain their site. So, your
| logic only works for certain use cases, not all.
| aprdm wrote:
| Saying that you disagree and saying at the same time that you
| rewrote it in Elixir makes me think that wasn't a good use of
| the money. They will have problems hiring for it and it isn't
| even performant compared to other languages you could have
| written into if you really wanted to save money (i.e:
| golang).
|
| Of course I don't have all the context, but, I cannot imagine
| any circumstance when rewriting some server side logic in
| elixir would be useful from a PoV of cost savings..
| leesalminen wrote:
| How much did you charge to rewrite WordPress in elixir
| though?
| code-is-code wrote:
| And how big was the risk to have the invested time wasted?
| How long did you block new feature developement?
| spullara wrote:
| If Twitter's port to the JVM didn't result in 10x fewer servers
| with 10x lower latency vs an identical Ruby implementation we
| wouldn't have done it. Sadly not much progress has been made on
| the RubyVM though Twitter did try with improvements to GC and
| other changes. We even tried JRuby as part of the evaluation.
| cageface wrote:
| _" Language X is slow and we could save Y switching to Z" is
| always a false promise._
|
| The thing that keeps software interesting for me is that there
| are almost no absolute rules. So I'll agree that complete
| rewrites are usually a mistake and performance problems are
| often not in the language.
|
| But I can't agree that rewrites are _always_ a mistake. esbuild
| is a recent good example of how much difference switching to a
| faster language can make.
| mgraczyk wrote:
| Idk, I worked at IG for a year and wrote a lot of backend code
| in the Python webserver stack. I believe they would benefit
| massively by aggressively migrating services to the FB Hack
| stack.
|
| A ton of work goes into making sure the Python code isn't slow,
| and there are complicated C++ services built as workarounds for
| the slowness of python.
| re wrote:
| > keeping your developers happy working on familiar code
|
| That turns pretty quickly into "developers being unhappy that
| they have to maintain legacy code written for the old
| language/platform," though, especially with any sort of
| employee turnover.
| peterhunt wrote:
| It doesn't have to be this way. If you're going to go all-in
| on the monolith approach like FB and Instagram did for their
| product code (at least when I was there), you need to have a
| central team whose entire job is scaling the codebase. This
| means actively refactoring other teams' legacy code, making
| sure that tests are fast, etc.
| kevingadd wrote:
| I think while performance is not a proper justification, if you
| get other stuff in the bargain it can be really worth it. Rust,
| for example - the justification to switch is usually _not just_
| speed but safety and the safety enabling more optimizations,
| parallelism etc. If all you care about is speed you stay in C
| /C++.
|
| Sometimes the choice is also made when you already have to pay
| a transitional cost - at a previous employer we had to rewrite
| a bunch of code to move from an old version of PHP to a newer
| one, and a strong argument was made that at that point we
| should just adopt a better language since we already had to pay
| that cost. I think eventually a lot of stuff transitioned to
| Haskell as part of that process, even if other stuff stayed in
| PHP.
| qotgalaxy wrote:
| Instagram is prematurely releasing this only because they heard
| that Tinder was about to release their own CPython fork.
___________________________________________________________________
(page generated 2021-05-04 23:00 UTC)