Man, I loved Neuromancer when I read it as a kid. Yes, it's a tough book to read, especially today where there are too many distractions as well as too many works of art built on the sci-fi ideas of that era.
Neuromancer is the first installment of the Sprawl trilogy, followed by Count Zero and Mona Lisa Overdrive.
So trying not to spoil too much: Count Zero asks questions about / describes how AI could have influence over religious/spiritual life of humans.
Will we see AI preachers having a real influence on human religious life? ChatGPT the prophet? Maybe this is the real danger of today's nascent AI tech?
I don't see the point of standardizing name mangling. Imagine there is a standard, now you need to standardize the memory layout of every single class found in the standard library. Without that, instead of failing at link-time, your hypothetical program would break in ugly ways while running because eg two functions that invoke one other have differing opinions about where exactly the length of a std::string can be found in the memory.
The naive way wouldn't be any different than what it's like to dynamically load sepples binaries right now.
The real way, and the way befitting the role of the standards committee is actually putting effort into standardizing a way to talk to and understand the interfaces and structure of a C++ binary at load-time. That's exactly what linking is for. It should be the responsibility of the software using the FFI to move it's own code around and adjust it to conform with information provided by the main program as part of the dynamic linking/loading process... which is already what it's doing. You can mitigate a lot of the edge cases by making interaction outside of this standard interface as undefined behavior.
The canonical way to do your example is to get the address of std::string::length() and ask how to appropriately call it (to pass "this, for example.)
This standard already exists, it's called the ABI and the reason the STL can't evolve past 90s standards in data structures is because breaking it would cause immeasurable (read: quite measurable) harm
Like, for fuck's sake, we're using red/black trees for hash maps, in std - just because thou shalt not break thy ABI
We're using self-balancing trees for std::map because the specification for std::map effectively demands that given all the requirements (ordering, iterator and pointer stability, algorithmic complexity of various operations, and the basic fact that std::map has to implement everything in terms of std::less - it's emphatically not a hash map). It has nothing to do with ABI.
Are you rather thinking of std::unordered_map? That's the hash map of standard C++, and it's the one where people (rightfully) complain that it's woefully out of date compared to SOTA hashmap implementations. But even there an ABI break wouldn't be enough, because, again, the API guarantees in the Standard (specifically, pointer stability) prevent a truly efficient implementation.
Are there open source libraries that provide a better hash map? I have an application which I've optimized by implementing a key data structure a bunch of ways, and found boost::unordered_map to be slightly faster than std::unordered_map (which is faster than std::map and some other things), but I'd love something faster. All I need to store are ~1e6 things like std::array<int8_t, 20>.
You should probably use either boost::unordered_flat_map or absl::flat_hash_map if you don't need ordering. Especially with 20-byte values. (Though you didn't mention the key type). If you're dealing with building against Boost already, I'd just switch and measure it.
This line is part of the code that creates an AST-like structure that is then fed into the compiler. The actual multiplication is done by calling the function handle returned from the Compile method.
I think what GP was referring to that there is nothing stopping the code from being designed so that:
AST<float> p1 = exp.GetP1();
AST<float> rsqr = p1 * p1; // AST<float> implements an operator* overload that produces an AST<float> object
Even if many frown upon operator overloading due to the annoying magical-ness of the standard-librarys appropriation of the shift operators for "piping" (<< and >>), it's still what makes many people prefer C++ for vector-math,etc tasks.
So whilst the result isn't a direct multiplication it should still be an acceptable use since the resulting code will actually be doing multiplications.
Considering what goes on under the hood however, I guess there might be some compiler optimization reasons to keep everything in the expression object in the example as the holder of data instead of spread out in an allocation tree with lots of pointer-chasing.
> So whilst the result isn't a direct multiplication it should still be an acceptable use since the resulting code will actually be doing multiplications.
First, nope, if it's not multiplication it should not be using the * operator, period. Operator overloading is already overused and it leads to so much problematic code that looks fine to the untrained eye (string concat using operator+ being a famous example).
That said, you may also want to pass more options to the Mul node in the future and operator*() can only accept two arguments.
As another example, run the following Python code to see how python represents its own AST:
So basically you're saying that if I want to add mathematical expressions to my JIT'ed code I should obfuscate the purpose by writing multi-line operations to build them instead of having the ability to plonk it in more or less verbatim?
As I said, I fully agree that operator overloading is horribly overused but the purpose of this JIT is to quickly create JIT code with customized expressions then those expressions should be possible to write fairly verbatim instead of following something with a religious zeal (is even matrix multiplication allowed to overload?).
And yes, AST's usually contain a lot more information such as source-location,etc for debugging (here it'd be interesting if an operator overload is able to take C++20 source_location as default parameters), but again this is for a specialized jit.
As for passing more options to mul nodes, a mul node is just that and nothing more (only extra interesting data in a restricted scenario as this would possibly be source_location as noted above).
Yes, but what I suspect the commenter was saying is that you can build the expression usung operator overloading as well, so you can type ”a + b”, not ”a.Add(b)”.
I love it when libraries like this do that. z3 in python is similar, you just build your constraints using normal syntax and it all just works. Great use of operator overloading.
Except that's not what's happening. expression.Mul isnt multiplying itself against something, it's adding a Mul instruction to its list. Maybe it would have been more obvious if the method name was insertMul instead.
When implementing the lock-free stuff, was portability (across processors) a goal? If yes, did you have to deal with anything specific? Do you notice any difference in behavior of correct implementations when ran on different processors? How do you test for correctness of lock-free stuff?
EDIT: Oh and did you implement from scratch? Why not use eg. the RCU implementation from folly?
We never targeted weakly-ordered architectures like ARM, only x86. We never used a wide variety of different processors. We are not developing the Linux kernel and are not into control dependencies, just relying on the fences and the memory model. There may be some CPU-dependent performance differences, like discrepancy because of NUMA or false sharing being noticeable on one processor, but not on another. RCU and hazard pointers are nothing new. For the disjoint sets we don't need them. For the forest patches and the tries we do. We are using TBB and OpenMP whenever possible and trying to keep things simple.
Check for vulnerabilities in dependencies and do the same thing they described in this post, just with... meaningful feedback.
I'm more an infra guy, and such scans are actually absolutely awesome. I see everything in my k8s clusters, all java/python dependencies that need attention.
I'm more surprised how anyone can run an app for more than 2 weeks with no high severity vulnerabilities. I guess mobile doesn't have the same attack vectors, but still
Mobile has unbelievably smaller attack vectors due to the hefty sandboxing, as long as you're doing normal things and not including a bunch of janky ad libraries. You're largely just contacting APIs you control and not running arbitrary code, and there's no outside connections coming in at all - lots of extremely bad CVEs are completely irrelevant in that context.
Sure, you can bend your scope to make them relevant... but if you've got someone who can control your system in ways you didn't build by bypassing the OS protections, they already have control of the device and can do darn near anything. If you haven't protected from that, and it's frequently not possible, many other protections are meaningless.
Your backend though has to handle this kind of malicious-modified-client scenario, as well as random connections from code you don't control at all.
(This is not true for all apps of course, but for B2B stuff? Most small companies? Frequently valid)
If you're not an app that's intentionally risking your users' safety though, you probably have some reason to trust the ad vendor to do their part. It's calculated risk for most non-malicious apps, and the major vendors are broadly fine in that respect. Ignoring privacy anyway.
And we can ignore the shovelware, which probably is actually a majority of apps. Those won't care about security patches, and will probably go out of their way to hide them so they don't appear vulnerable and don't have to do maintenance releases. They wouldn't be affected by forced updates.
So as a conclusion, it seems we agree that those that are the ones creating most risk for users will not be impacted.
I am sticking to android ecosystem as best one I know, because I still have choices + I can use fdroid for a lot of my apps.
But when my mom uses a tablet or phone
... I have absolutely no smart advise to give her. All apps are hostile and annoying. The play game subscription is fine (apps/games cannot have apps and are fully unlocked) but other that that play store is a minefield.
> It can be added in theory, but there would be certain problems. Like said earlier codec frame access is very problematic (I, P and B frames), because in worst case scenario you have to decode about 248 sequential Full HD H.264 frames before you can get previous image (so there will be major LAG).
Having used the 'previous frame' feature in mpv, I suspect this is exactly how it's implemented.
it's more about the tech it uses... it's oriented toward docker based deploy and is made in rust so maybe it can be ported to iOS, I'd have to spend time forking the packaging. looks like it's geared toward server environments
Neuromancer is the first installment of the Sprawl trilogy, followed by Count Zero and Mona Lisa Overdrive.
So trying not to spoil too much: Count Zero asks questions about / describes how AI could have influence over religious/spiritual life of humans.
Will we see AI preachers having a real influence on human religious life? ChatGPT the prophet? Maybe this is the real danger of today's nascent AI tech?