the output of the second example is "obvious" so i don't see the problem.
678 karma · joined May 1, 2024
cute pun but compared to busybodies it really hides the implication (i thought you were talking about people with adhd at first).
Edit: someone downvoted me because they don't understand there is no walrus operator here
print(f"{a:=10}")70% of these "wtfs" aren't about string interpolation but just python's syntax for string.format
https://docs.python.org/3/library/string.html#format-string-...
It is... it's in GPUs lol
> first class in torch
It is
> costing a fraction of GPUs
Why would anyone give you this for cheaper than GPUs lol?
Congrats - I have no idea what this means lol.
There you go you've hit basically two of 3 completely (AMD and Vulkan) and are close enough to CUDA that people would get it.
I have no idea what a plane connotes and a cube literally gives a distinct enough picture from block that I will be continuously reminding myself of the mapping.
What you did was pointless - you assigned new words to objects that you don't own and now your conceptual framework is askew from the actual underlying (true) conceptual framework.
> CubeCL to CPU
There is zero affinity between GPU programing models and multicore CPU programing models. If you don't believe me go ask the OpenMP people how they're doing supporting GPUs.
> Unit (thread in CUDA, invocation in Vulkan/Wgpu): the smallest execution entity performing computations.
> Plane (warp in CUDA, subgroup in Vulkan/Wgpu): a group of (typically 32) units executing in lockstep and able to share data efficiently through registers.
> Cube (thread block in CUDA, workgroup in Vulkan/Wgpu): a group of units that execute on the same SM, sharing memory and able to synchronize
It's already bad enough that the vendors themselves insisted on different names but why in the bejesus would you rename these concepts and diverge from literally all existing naming conventions when you're providing middleware. Ie when using your tool I'm still going to reference NVIDIA's or AMD's docs to understand how the hardware actually works. Like do you really think otherwise - that your thing is gonna be end of the line???
FYI the word warp isn't random techno babble but is actually a very clever pun that actually fits very well conceptually:
this only goes so far - if you try to eg bind O(10k) methods using nanobind (or pybind ofc) you will be compiling for a very long time. for example, i have a threadripper and with a single large TU (translation unit) it took about 60 minutes (because single TU <-> single thread). i had to "shard" my nanobind source to get down to a "reasonable" ~10 minutes.
> AFAICT this does not quite produce true binaries, but rather interprets C++ via Cling, is that right?
yes but to be very clear: it's not designed to interpret arbitrary cpp but calls and ctors and field accesses. the point is binding. also it can use cling or clang-repl.
https://www.investors.com/news/technology/apple-stock-apple-...
backend
so the central idea of dependency injection, a concept with a wiki of like 5000 words [1], is just pass parameters to functions...?
i guess i'm happy to accept that (i personally DGAF about DI or whatever) but it certainly means that all the people discussing DI (like yourself) are peddling snake oil...?
Ie the link I posted above
It's much easier conceptually to implement this using recursion instead of a while loop and a token stack (it's basically DFS). So I disagree with you there.
> The other reason I dislike this kind of stuffs is that I have someone in the team who really likes to use patterns for every piece of code. It's kinda difficult to tell whether it is over-engineering or not, but my principle is that intuition always beats less lines of code (or DRY), unless it is absurdly more lines of code or repetition. And to test that principle you just grab a newbie and see which one makes more sense to him
I'm with you - I really don't give a shit about patterns (which was my whole original point - who cares). But that last part I don't agree with - systems code (like a parser) doesn't need to be legible to a noob. Of course we're talking about a textbook so your probably right but like I said most production parsers and AST traversals are written exactly this same way. So anyone learning this stuff hoping to get a job doing it should just get used to it.
You're overindexing on maximally generic visitor pattern. If you have one type of visitor but nonetheless dispatch based on type that's still visitor pattern.
EDIT: to be honest who even cares. My initial point was why in the hell would you stop reading a book because a particular "pattern" offends you. And I'll reassert it here: who cares whether a recursive descent parser fits the exact definition of visitor pattern or not - you have members of a class that do stuff (construct AST nodes) and possibly track other data and then call other members. I usually call that a visitor class even if it's the only one that ever exists <shrug>
I'll repeat myself: this is not possible because you need to recursively construct the nodes (how else would you get a tree...).
My guy... Do you think that parsers just like... concat tokens into tuples or something....??? Do you not understand that after lexing you have tokens (which are a "type") and AST node construction (an "operation") and that the grammar of a language is naturally a graph.... Like where else would you get the "recursion" from....
If that doesn't make sense I invite you to read some literature:
> makeAST():
> asks the tokenizer for the next token t, and then asks t to call the appropriate factory method the int token and the id token call makeLeaf(), the left parenthesis token calls makeBinOp() all other tokens should flag an error! does the above "smell" like the visitor pattern to you or not? Who are the hosts and who are the visitors?
this (lexing) is the only use of the codec hack - if you want to manipulate the AST you do not need this and can just to `ast.parse` and then recompile the function.
You can't land a language feature that only sometimes works - that's absolutely horrid UX.
> can't we just copy whatever JS does?
I wasn't aware that js does this and I don't know it's implemented. So maybe I should retract my claim about compiler assistance.
lol people really say whatever comes to their mind around here don't they? I'm pretty sure all of the companies associated with these targets would strongly disagree with you
https://github.com/llvm/llvm-project/tree/main/llvm/lib/Targ...