From an ergonomics perspective big-endian is the little-endian of stack based machines. Register truncation is the big reason why from an ergonomics perspective we prefer little-endian, but in stack based machines the equivalent is pop truncation. But the behavior between these is reversed between the two machine types. Big endian is the layout by which pop-ing one byte off the stack gives you the truncated number.
Co-routines can be a nebulous sort of concept because it means different things in different places and not all of them have the same features. But some of the big points are:
- Heap allocated call frame. Instead of being pushed onto the stack, co-routines tend to have their call frame (local variables, arguments, etc.) placed into heap memory (or at least may be place-able into heap memory). This often enables the other features.
- Control can leave co-routines in more ways than standard function calls. Generally this means returning (often called "yield") to the caller without completing the whole function. It can then be later resumed, returning to where the function originally left off. Generators are a common pattern enabled by co-routines that rely on only this part (and so many systems can optimize out the heap usage, for example).
- A co-routine is usually an object with an interface that allows you to move it around and resume it in different places than it was originally called. This can include on different threads, or depending on the sophistication of the system, different processes or machines.
Those are the three big points in my mind. I'd recommend trying lua coroutines, personally (I like minmalist engines like defold to use it in) to really get a feel for how these are on the edge between "language feature" and "library feature".
I think you are misapplying that paper? This as a library is the "batteries" to C++'s no-batteries-included standard library which does not implement asynchronous coroutines at all.
The paper is much more on the side of application and system performance. But you couldn't even write such a system without a library like this providing you the tools to do so. This is much more in the domain of "basic tool for ecosystem" than "library for specific tasks". It's on the user of the tool to address the paper's question, not the builder of the tools.
You are not incorrect in stating that the primary focus of the paper is more on the application side. However, I think providers of a parallel computation infrastructure would benefit from profiling a wide range of potential use cases across several work load sizes. This could then lead to a section in a README where the baseline overhead was broken down per workload/worksize measurements and a back of the envelope estimate by an application developer would be more particularly motivated when deciding which infrastructure tool may be the best fit for their application's specific requirements.
"Concurrency != parallelism" is an important distinction in this context. The base C++ coroutines feature is not about threads or parallel processing, but rather is a generalization of the concept of "subroutine" with respect to control flow and stack usage. An example using coroutines to service many tasks (if not otherwise involving threading features) is not much different (at the level of what the CPU sees) from a single threaded implementation using a loop or continuation passing to process concurrent tasks. Performance should be identical between both the language-supported coroutines code and the manually implemented single threaded loop if the work is batched the same.
I would tend to agree with your open assertion that Concurrency != Parallelism. However, I'm not sure that it is really germane in this situation. I am aware that library in question here uses C++ coroutines for 'task encapsulation' according to the developer; however, this library is being compared directly to TBB and OpenMP which are two of the 'go-to' implementations for parallel computation. So I don't think the focus on parallelism in this comment chain is in any way inaccurate or misapplied.
I mean yea, I read this as an idiom for "went to do something wholly unrelated to programming". Not as "I literally am going to begin farming". Like I would read anything from "restaurant owner" and "artist" to "flight trainer" and "corporate DJ" as all fitting under that.
To be fair, I suspect they meant it in a more idiomatic sense. Not that they literally went farming. Sort of like when one says "water under the bridge" they aren't commenting on bridges, nor water.
Eh, calling on a company to do a thing is some mix between public fact finding and threat here.
It allows the public to comment and maybe the senator will like the public support they are getting. Alternatively a pharma lobbyist will show up and toss them a few hundred thousand in campaign contribution promises. And they'll weight the relative value of those things. Depending on how that goes they (or another senator seeing this play out) will actually make an issue of it and it will start the more formal processes.
Yeah, but you can equally ignore fgetc and friends in C. My only point here is that IO in the standard library is not very good in either language.
IMO a parser should be reading the entire file, and then parsing as a block of memory, by default, for most use cases these days. That way you don’t have to think about IO while you are parsing. Streaming parsers are niche these days for good reasons.
> Unity isn't close to profitable, and never has been
This isn't really true though, their core business is and was profitable if you exclude all the of acquisitions junk, stock shenanigans, and loans to pay for it they have been doing.
It just didn't have the margins expected of a public company and so they did all that other junk to pump those numbers.
> This isn't really true though, their core business is and was profitable if you exclude all the of acquisitions junk, stock shenanigans, and loans to pay for it they have been doing.
"We're profitable if you ignore all the things we're spending money on"
Not all the things, just their unprofitable side business attempts. It's like knowing a guy with a well paying job who always complains he is broke. But he conveniently never mentions that he's spending $4500 per month on a Lamborghini lease.
The claim here is that none of that spending is generating revenue. They could stop spending that money, their income would remain the same, and then they would be profitable.
