jasonzemos

I asked you not to argue semantics, but you're doing it anyway. I didn't respond here to argue protobufs actually is bad, since all software is suited to something for somebody somewhere.

In fact, I can just do that now: Protobufs is bad. You seem to agree, because you haven't even advocated for it -- just flatbuffers and Cap'n Proto and the phonebook of alternatives. Listen, I don't care who you've worked for or what you've done. As a scientist and engineer I'm totally ready and able to entertain critiques of my prior works without being offended. I'm offended that this is the quality of your participation here.

Why is that absurd? Products used by billions of people may just as well not have serious requirements. I beg not to debate semantics, indeed my own fault, but in the world of network software requirements can start to get very serious, straight through to userspace protocol stacks on DMA'ed device buffers.

Would you go through all of the effort to rig an application with userspace networking only to return its results inside an `std::string` -- one of the few std containers where one can't even control the allocator if they wanted to? That's absurd, if anything.

> Avoiding memory allocation significantly increases the complexity of an API -- or worse, leads to shortcuts like using (thread-unsafe) globals or (overrun-prone) fixed buffers.

Allow me to unpack this, because the object interface that all of these serialization schemes present is what increases complexity. It makes sense that the simple implementation would tend toward dynamic memory and not further compound such complexity on their interface. This is a flawed architectural premise taken by these library implementations.

On the receiving side, there is little reason to ever deviate from zero-copy/zero-allocate. These libraries are far too pro-active in deserializing incoming data into native object structures. It's not necessary to present the user with this; they should pique through the results lazily -- query into the data at their own discretion. This is important because it bounds the minimum requisite cost of receiving messages at ... zero. It costs nothing to discard trash. Whereas with these proactive serialization layers, every single incoming attack becomes an exercise against the deserializer. In a zero-copy/zero-allocate -- let's even say, zero-parse mere lexing of the data, software has more flexibility. In practice, that means passing pointers around to parts of messages straight off the wire to application functionality further up the stack.

On the sending side, there is little reason to ever force whole native object representations to conduct a serialization. In other words, don't force the user to build an std::map first and serialize it later. All input is streaming input. Properties do not have to be pre-buffered, they can be streamed. One can model any network serialization this way, sans perhaps canonical representations (sorted JSON keys, etc), and far more efficiently than with requiring arbitrary native structures.

This is not really a rebuttal about the merits for or against dynamic memory in and of itself. I know the research, thread-aware allocators can be pretty good -- even darn good, and the state of the art in GC is nothing to shake a stick at. The problem is that with better design it's just not necessary, and in the end it does have a cost that one should want to eliminate if possible. I'm certain it's quite usually possible, at least more than I see in a list like https://en.wikipedia.org/wiki/Comparison_of_data-serializati... etc

> I suppose it depends what you are comparing it to. Almost every JSON library has the same limitations you mentioned, and yet many people find JSON useful for network applications.

JSON is a human-readable format which is hugely advantageous to develop and operate in many settings. Protobufs doesn't have that advantage. Yet we're paying all of the same costs to structure the data with both. That's enough to posit JSON as a net winner over protobufs.

> Unfortunately protobuf C++ can't live fully within this arena model while it uses std::string for accessors.

Forcing std::string as a container for core components of a networking API (specifically for an accessor) is an exemplary demonstration of a lack of seriousness in a library.

CBOR also delivers optimal wire sizes with its variable length encoding. Ceteris paribus, there's no technical advantage to using protobufs. The choice is almost always non-technical (business, platform, partnership, etc) or simple naivete. It's not harsh, it's just engineering.

Since all other comments appear to contradict you and make apologies from authority (after all, Google can't do anything wrong, right?) I'd like to just reassure you with my 20 years of experience developing C (and the last 10 with C++) in network and system software: that any library -- any library -- that forces internal dynamic memory upon its user smells bad. It's not a universal condemnation, but it begs the question, or rather the skepticism to ask why?

In the case of protobufs, there is no real answer. Protobufs is one of the few network libraries that doesn't operate with zero-copy. That steps over a tangible line in the sand.

No zero-copy for networking? Forced internal heap allocations with only this arena feature after a decade? Sorry no. Protobufs isn't useful for serious network applications.

I'd like to apologize for simply not using the phrase "non-consenting." Including the word "democratic" in my point is probably far too convoluted. The definition of a legitimate regime (going back to Locke's treatise on government) is one that has consent of the people. Democracy (as a whole system in its many diverse forms) and elections (as part of that system to sample the people directly), and self-government itself: where you and your ordinary civilian neighbors are physically involved in the governance of your locality, rather than cadres sent from the central government -- the confluence of all of this is legitimacy.

Reality appears to contain giant statues of a European Jewish Socialist heralded throughout Beijing. If the East was so proud of some original political system held as "superior to democracy" -- why does the ruling regime employ the same tactics to hold power over the affairs of men as documented by a 16th century Italian?

Politics might be flavored and seasoned by locale, race and culture, but the meat is all the same and always has been. To conclude otherwise, or make China a "special case" is probably racism. It also denudes the notion of universal human rights.

> Undemocratic political systems don't even always have power concentrated in one person

This is absolutely correct, which frames my point in an even worse light. The whims and power of the Leader are the whims of subordinates to the leader, who are superiors to further subordinates. Western continental philosophy, Heidegger, Arendt, Levinas, all framed this concept under the term "The Totality." It's fascinating.

I just want to make this political science point absolutely clear without ambiguity: when an illegitimate (non-democratic/non-consenting) regime engages in "anti-corruption" they are doing nothing more than purging disloyalty to the whim and power of the Leader. Nothing more, nothing less. Period.

There's no single confluence where every application's needs are provided by a single C/C++ implementation's default allocator. I'll just speak to one example off the top of my head: the default glibc malloc() stores an allocation size near or below the actual allocation data itself. In contrast, an alternative like jemalloc tracks the size in a separate control block. When freeing allocations with the former, that memory has to be touched; with the latter, the control block has to be touched instead. Similarly it can lead to less or more efficient packing of aligned data. All of this yields better or worse performance depending on the application.

The statement is a slippery-slope, but it's not a fallacy. The concept of a monopoly is one we can agree on, and the exposure to the risk being described is a real one. What is to stop a monopoly deciding 30% becomes 40%? Not much.

Yes, the latter escapes any legal accountability to its corruption.

> A late career MBA in most cases has vastly diminished signalling/credentialing value.

That anecdote seems to insinuate the essence of an MBA offers no substantive value, nor does even the achievement of the accreditation itself. It is the timing of the latter which projects the value.

Is that a really low or a really high bar?

Indeed the conceptual fork point mentioned is RocksDB 6.2.1 which came before those features. The problem with RocksDB is that one thread only makes one request at a time. I should've phrased my question more succinctly: Is Pebble/CockroachDB capable of saturating the backplane with requests in parallel? Does it multiplex a single query by dispatching smaller requests to a thread-pool?

Concurrency and multithreading are a major focus of both Go and RocksDB. This introduction makes little mention of those areas, and I'm curious if there's any more to be said on this. The article lists several features being reimplemented, including:

> Basic operations: Set, Get, Merge, Delete, Single Delete, Range Delete

It makes no mention of RocksDB's MultiGet/MultiRead -- is CockroachDB/Pebble limited to query-at-a-time per thread? I'm genuinely curious how this all translates into Go's M:N coroutine model currently and moving forward with Pebble.

Or bring back the Habilitation above PhD for serious academics. PhD is already sought after too much for professional reasons. Another 10 year commitment distills the lovers of wisdom from the lovers of cash.

From note #13:

> The silicon implementation of the lower eight bits of the ALU / registers is flipped compared to the upper eight bits. The motivation is to put the ALU signals next to the flag circuitry that needs these signals.

This caught me out because I was expecting some more obvious rotation or discernible mirroring of the upper half and lower half. Is the layout of bits 15:8 entirely different yet logically equivalent? Looking closely though I do see some similarities in the outer circuits at the very top and very bottom, yet there is a large gap across the lower bank.

I assume it followed an attempt by Google to influence how these funds are directed at Mozilla. Is Servo a threat to Google? Perhaps reinventing everything in Rust is just a detestable waste of resources?

> AVX2 had downclocking issues when it first appeared too - but these were rapidly mitigated and forgotten.

Speaking of Daniel Lemire, he recently published a paper https://arxiv.org/abs/1910.05109 mentioning downclocking in section 4:

> On some Intel processors, AVX-512 instructions are subject to downclocking: whenever AVX-512 instructions are executed, the processor lowers its frequency. We do not observe any downclocking on our processor, nor did we find any Intel documentation referencing downclocking for this processor. To test for downclocking, we used the avx-turbo benchmarking tool: it reports the processor frequency after issuing long sequences of expensive instructions of various types,including AVX-512 multiplication and floating-point instructions.

I'd like to commend the authors for embarking on this. Complex ISA's are an unfortunate reality for performance as advances in cycles-per-second on a single core are negligible. The divergence of these increasingly complex ISA's among platforms weigh heavily on competitive application developers.

As someone who is interested in writing cross-platform SIMD code the most valuable asset to me is a library or compiler that can generate the instructions dynamically from otherwise normal'ish looking C/C++. This is the most powerful mode of development in my experience. Clang already does this remarkably. I can write with standard C++ syntax (albeit awkwardly) and maybe using a few custom types with `__attribute__((vector_size(x)))` and not have to involve explicit intrinsics except perhaps for a very small number of leaf operations that cannot be expressed. At this time Clang has the upper-hand on GCC: the latter cannot generate code which scales between platforms utilizing different vector sizes. For example, if you try to perform an operation on a 256-bit vector using a 128-bit target: Clang will seamlessly generate two 128-bit operations; GCC will fall back entirely to scalar. My assumption is that developments in Clang for ARM's SVE have carried over to generating scalable code for other platforms, but nevertheless it is remarkable.

I don't believe that writing functions comprised of hand-crafted lists of intrinsics is the best way forward. Undoubtedly it's worked for projects, even quite well to ship stable software -- but it scales and adapts poorly in a fast-developing and diverse market of hardware. For example, years ago I wrote a simple `tolower(string)` implementation using an assemblage of 128-bit standard-Intel SSE2 statements and today the instructions it produces are exactly the same as the day that I wrote it. All I can hope for is that 256-bit capable architectures can execute two of my operations at once. That's not ideal.

> The OS-based implementation uses the “signal handler trick” that wasm VMs use. This technique reserves lots of memory around the valid range and relies on CPU hardware to give us a signal if an access is out of bounds (for more background see section 3.1.4 in Tan, 2017).

On Linux you can also make use of userfaultfd(2) rather than handling SIGSEGV.

AVX-512's richness to x86 is like what C++'s is to C. Linus makes a summary assessment for how he can leverage these technologies to his advantage and if the cost of learning the technology and all its intricacies outweighs the perceived advantage: that technology is garbage. This reaction from Linus appears to fit his conservative pattern. I think where Linus gets things wrong stems from his facts rather than his philosophy.

AVX-512's fantastic breadth is born out of an actual need to free compilers from constraints imposed by programs in virtually every mainstream language. All of these describe programs for an academic-machine rooted in a scalar instruction model. Without any further performance from increasing cycles over time the target has to become instructions-per-cycle and even operations-per-instruction. The limitations on ILP and the expense of powering circuitry to achieve it has been well studied for the past two decades. The failure to realize it is evident in the failure of Netburst. Linus believes that the frontend of CPU's have a lot more to give; perhaps best exhibited with his refutation of CMOV (https://yarchive.net/comp/linux/cmov.html).

Today's programming languages haven't evolved to make things easier on programmers to describe non-scalar code. On the other hand, power constraints, and now security constraints haven't made things easier for hardware to efficiently execute scalar code. Perhaps AVX-512 is as naive a bet as Itanium, if not it might be just the missing piece compilers need that they didn't have twenty years ago.

As a skeptic of Rust I really appreciate this. I was very pleased to find the ASM option in the drop-down menu specifically. Coming from C/C++ I've found it difficult to understand how and why Rust generates the code that it does. Rust appears slightly less direct in its description of programs than C++ as it's shed the hardware-driven abstraction of memory and physical layout. My comfort level with seriously considering Rust for a next project is proportional to my understanding of what it's doing under the hood.

Thanks! Looks great.

Rust only proves that promotion buys mindshare. Since money buys promotion, and because of endless unscrupulous capital investment to two of Rust's most evangelical promoters: Mozilla and Cloudflare; Rust indeed has its chance. Make no mistake that is all there is to this.

Fifteen years ago Apple underwent a similar endeavor to convert all of its C++ code to Objective-C or even C. Apple isn't a leader in this decision-space; they're just a victim of this meme.

It's cool to see Matrix work inside emacs but I think the spirit of the OP alludes to putting a little emacs in Matrix too. Composing messages in that band-aid at the bottom of Riot is a great example of a stress-inducing UX. Some venues around Matrix deserve high quality content and it's difficult to encourage that when people write and proof posts through the peephole.

Specifically, the Intel manual makes the following important points, one involving an `mfence;lfence` combo:

* If software requires RDTSC to be executed only after all previous instructions have executed and all previous loads are globally visible, it can execute LFENCE immediately before RDTSC.

* If software requires RDTSC to be executed only after all previous instructions have executed and all previous loads and stores are globally visible, it can execute the sequence MFENCE;LFENCE immediately before RDTSC.

* If software requires RDTSC to be executed prior to execution of any subsequent instruction (including any memory accesses), it can execute the sequence LFENCE immediately after RDTSC. This instruction was introduced by the Pentium processor.

rdtscp is usually a bit more disruptive, and cpuid is probably 100 or 1000 times more disruptive.

> the fact that 99% of the population basically just uses the minimal subset of features

The tendency is for people to invoke features situationally. If you are communicating with someone who is using rich-replies there is a tendency to also invoke that feature yourself. If people are using emojicons there is a tendency for others to play along rather than use plaintext characters. Feature invocation is situational and relative.

> Two services don't need to have identical feature sets to interoperate, because you don't need perfect, full interoperability, if you can send most of your messages across platforms, that's still pretty good.

This has proven to result in an unacceptable user experience throughout the history of messaging. When a system loses social information from the environment it is no longer an effective communication tool. Worse, it is dangerous. If you send me a message and I respond to your message with some thumbs-up emoji, and your platform doesn't support it (e.g. a text-based IRC client) that information gets lost. You believe I have disregarded your message. You may assume I have been rude when the opposite is true. This is absolutely unacceptable UX.

Thanks Neil. It's difficult to find alternative servers on that page so I will help by linking to The Construct which is the only other federating server. Though it is not yet stable, it is the only functioning third-party server and has more progress than your own reference implementation's rewrite!

Check out https://github.com/matrix-construct/construct and join us at #admins:matrix.org