| ▲ | nvme0n1p1 a day ago |
| Grep (or ripgrep at least) is i/o bottlenecked at this point. It's impossible to process data at faster than i/o speeds, since you have to get the data to the processor somehow. That doesn't change whether that processing is grep on a CPU, or LLM on an ASIC. |
|
| ▲ | serbuvlad a day ago | parent | next [-] |
| ripgrep may be. I did a toy project once implementing a limited version of grep on an FPGA and was able to get some speedup over GNU grep at the time, though marginal. In any case, LLMs aren't IO bound :)) |
| |
| ▲ | cobbal a day ago | parent | next [-] | | I am now imagining a future where developers buy fancy "grep cards" for their machines. I don't hate it. | | |
| ▲ | alexshendi 6 hours ago | parent | next [-] | | These are properly called "GPUs", as in "Grep Processing Units"! | |
| ▲ | bee_rider a day ago | parent | prev | next [-] | | It would be cool if they could be daisy-chained, so you can have a hardware implementation of | | | |
| ▲ | mpweiher 10 hours ago | parent | next [-] | | The return of the Transputer. Put a Transputer in a Lego brick. Not "like a Lego brick", an actual Lego brick. Turn the notches into connectors for the serial link. Plug'n'play. | |
| ▲ | benterix a day ago | parent | prev [-] | | The next logical step would be to have a separate card for each Unix utility. | | |
| ▲ | QuantumNomad_ a day ago | parent | next [-] | | And a patch panel and a bunch of patch cables that you plug in and out to construct your pipelines. And eventually hire people whose job it is to patch pipelines on demand for everyone in the office. “Hey Jim, I’m gonna output the systemd logs of nginx on line five, can you assemble a grep pipeline for me to match all HTTP 500 status codes from /api/cart POST request log lines? Connect the filtered output to Tim’s desk, line 7. He’s there now, we are trying to figure something out.” “Sure thing Bob, give me a moment.” | | |
| ▲ | bartread a day ago | parent | next [-] | | It’s OK: you can just tell us you have a financially and relationally crippling Eurorack addiction. You’re amongst friends here. | |
| ▲ | serbuvlad 18 hours ago | parent | prev | next [-] | | I'm sure this is how some bellheads (in the phone tradition, not in the Unix tradition) envisioned computing. | |
| ▲ | justsid 15 hours ago | parent | prev | next [-] | | Now if that isn’t a great Zachlike game mechanic. Playing as the patch pipeline builder. | |
| ▲ | kgwgk a day ago | parent | prev | next [-] | | Patching cables is so primitive... Use punched cards to define the connection patterns or something! | |
| ▲ | xigoi 10 hours ago | parent | prev | next [-] | | Somehow we’ve reinvented punch cards, but worse. | | | |
| ▲ | nxobject 20 hours ago | parent | prev | next [-] | | Bring back IBM accounting machine plugboards! | |
| ▲ | formerly_proven 20 hours ago | parent | prev [-] | | Transputerpunk. |
| |
| ▲ | Retro_Dev 13 hours ago | parent | prev | next [-] | | I cannot wait for my cowsay coprocessor. | |
| ▲ | Scarblac 6 hours ago | parent | prev [-] | | And a datacenter for Emacs. |
|
| |
| ▲ | swiftcoder 8 hours ago | parent | prev | next [-] | | I wonder how close you can get with Nvidia's GPUDirect. Hook the fast NVME directly up to the GPU (well, it gets direct DMA to GPU at any rate), then implement parallel grep in CUDA... profit? | |
| ▲ | nxobject 20 hours ago | parent | prev | next [-] | | I look forward to GPGrepPU -- someone'll find a way to abuse them for scientific workloads or something. | | | |
| ▲ | sanderjd a day ago | parent | prev | next [-] | | Universal Basic ASICs | | | |
| ▲ | lou1306 21 hours ago | parent | prev [-] | | At some point Intel was experimenting a Xeon with built-in FPGA, maybe they were just a bit too early to the game :) | | |
| ▲ | mhast 18 hours ago | parent [-] | | Almost 30 years ago there was a project about making a computer which used FPGAs for all "software". It was called RAW. Baring it all to software: Raw machines | IEEE Journals & Magazine | IEEE Xplore https://share.google/nI9GyFJu4HvbYFrBf (If you Google the name you will find free PDFs as well, the IEEE page is more useful as a summary and such.) |
|
| |
| ▲ | dgacmu a day ago | parent | prev | next [-] | | I've evaluated some of these and in almost all cases they failed to outperform Intel's ridiculously optimized CPU regex library, hyperscan. | |
| ▲ | sanderjd a day ago | parent | prev [-] | | Right, but I read the comment's point as: being i/o bound is the eventual limit of the asymptote and it's the same one grep has. |
|
|
| ▲ | readams 21 hours ago | parent | prev | next [-] |
| GPUs and inference ASICS also have large amounts of high bandwidth memory, plus lots of high speed storage cache, and dedicated very high bandwidth scale-out and scale-up networks. Because they are also often bound by I/O bandwidth. If your problem is grepping crazy amounts of data, the infrastructure for LLMs isn't a bad place to look for an example. |
| |
| ▲ | nxobject 20 hours ago | parent [-] | | > plus lots of high speed storage cache I wouldn't be surprised if that's what Apple is focused on for their next generation platforms – I wonder if more layers of caching between their SSDs and unified memory are on the cards. |
|
|
| ▲ | sanderjd a day ago | parent | prev [-] |
| i/o could still be sped up though? And I dunno, maybe this actually is an argument for how the llm version could end up being faster, because there is lots of investment in crazy fast i/o hardware and protocols to get the data into the chips. |