By: Michael S (already5chosen.delete@this.yahoo.com), May 30, 2022 3:12 am
Room: Moderated Discussions
-.- (blarg.delete@this.mailinator.com) on May 30, 2022 2:44 am wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on May 30, 2022 1:32 am wrote:
> > I am old-fashioned. Never believed in principles of Doug McIlroy.
> > IMHO, if for your workload JSON parsing can be measurably sped up by SIMD and if this speed
> > up is noticeable in time profile of the whole app then it means one thing - you need something
> > better than JSON as your storage/COMM format. Start rearchitecting now and you will be
> > regarded in the future. That is, if you're not shown the door before that.
>
> Good luck convincing every third party service out there to adopt your "better than JSON" serialization.
> This also ignores the fact that JSON is efficient in certain environments (e.g. browser Javascript).
That is one of the cases where it should not be noticeable, at least when scalar JSON parser is written well. There is enough of other crap going on to make JSON parsing lost in noise.
>
> And why does it have to be a "noticeable" improvement? I like faster code, and I'm sure many others do as well.
> If it makes the application 1% faster, then why not? Across a large enough scale, 1% can mean a lot - for
> $100M in servers, 1% is ~$1M in potential savings. And if you consider how prevalent JSON is, it makes sense
> to eke out as much performance due to aggregate benefits, even if, individually, it doesn't matter much.
On 100M$ farm wouldn't you lose more in most typical short JSON cases than you gained in hopefully rare long JSON case?
And are there really so many 100M$ farms that consist completely of sort servers that do not clock themselves down when they see AVX512? I think, for majority of 1st and 2nd gen Xeon-SP SKUs it happend rather badly and this SKUs are still a majority of AVX512-capable server installed base.
> Michael S (already5chosen.delete@this.yahoo.com) on May 30, 2022 1:32 am wrote:
> > I am old-fashioned. Never believed in principles of Doug McIlroy.
> > IMHO, if for your workload JSON parsing can be measurably sped up by SIMD and if this speed
> > up is noticeable in time profile of the whole app then it means one thing - you need something
> > better than JSON as your storage/COMM format. Start rearchitecting now and you will be
> > regarded in the future. That is, if you're not shown the door before that.
>
> Good luck convincing every third party service out there to adopt your "better than JSON" serialization.
> This also ignores the fact that JSON is efficient in certain environments (e.g. browser Javascript).
That is one of the cases where it should not be noticeable, at least when scalar JSON parser is written well. There is enough of other crap going on to make JSON parsing lost in noise.
>
> And why does it have to be a "noticeable" improvement? I like faster code, and I'm sure many others do as well.
> If it makes the application 1% faster, then why not? Across a large enough scale, 1% can mean a lot - for
> $100M in servers, 1% is ~$1M in potential savings. And if you consider how prevalent JSON is, it makes sense
> to eke out as much performance due to aggregate benefits, even if, individually, it doesn't matter much.
On 100M$ farm wouldn't you lose more in most typical short JSON cases than you gained in hopefully rare long JSON case?
And are there really so many 100M$ farms that consist completely of sort servers that do not clock themselves down when they see AVX512? I think, for majority of 1st and 2nd gen Xeon-SP SKUs it happend rather badly and this SKUs are still a majority of AVX512-capable server installed base.
