Hacker News new | ask | show | jobs
by HALtheWise 2618 days ago
I don't see any claims about performance, but I would be very surprised if it was anything better than abysmal. In a modern neural network pipeline, just sending data to the CPU memory is treated as a ridiculously expensive operation, let alone serializing to a delimited text string.

Come to think of it, this is also a problem with the Unix philosophy in general, in that it requires trading off performance (user productivity) for flexibility (developer productivity), and that trade-off isn't always worth it. I would love to see a low overhead version of this that can keep data as packed arrays on a GPU during intermediate steps, but I'm not sure it's possible with Unix interfaces available today.

Maybe there's a use case with very small networks and CPU evaluation, but so much of the power of modern neural networks comes from scale and performance that I'm skeptical it is very large.

6 comments

> I don't see any claims about performance, but I would be very surprised if it was anything better than abysmal. In a modern neural network pipeline, just sending data to the CPU memory

Notice that the bulk of data does not necessarily go through the pipeline (and thus by the cpu). You may only send a "token", than the program downstream uses to connect to and deal with the actual data that never left the gpu.

This is similar to the Tcl approach. “Everything is a string”, but the string may be something like “the network socket at address 0x12345678”.
Would be nice if Unixes provided better support for pipelines of this sort...
Pretty sure you can't do this since the GPU's memory is per-process isolated as well.
Unless you share it between processes.
> Come to think of it, this is also a problem with the Unix philosophy in general, in that it requires trading off performance (user productivity) for flexibility (developer productivity)

“Sure, Unix is a user-friendly operating system. It's just picky with whom it chooses to be friends.” ~ Ken Thompson on Unix

But seriously, I would argue that Unix is "superuser" friendly - very friendly to advanced users who like their power tools, and is only unfriendly to those who want to have a more casual relationship with their computer (which admittedly is probably 98% of users).

I am not really a developer anymore, but any system that expects me to use a mouse over a keyboard makes me feel less productive.

It's not even friendly to superusers, it's a horrifically complicated mess of cobbled together archaicness.
Arguably a "complicated mess of cobbled together archaicness" describes most old software, Windows included. I think that's just the nature of how software evolves.
We might be in the middle ages of software development. Think of the way European cities grew naturally versus the grid structures of American cities. Perhaps in the future the art of software development will have progressed to the point where creating a new application results in nice, square lines of code that are perfectly navigable.

I wonder if, at that point, we'll wax nostalgic about the way software used to grow organically. Ahhh, to lose myself once more in the meandering spaghetti of yesteryear...

> trading off performance (user productivity) for flexibility (developer productivity)

Flexibility can often be "user productivity" as well.

This is only for inference, which is very cheap already, cheap enough for most applications (real-time video processing an exception). Training is the slow part which is worth putting on a GPU.
I mean, some people I know achieve developer flexibility and performance by just writing their own implementation in FORTRAN. Unfortunately this is inadvisable for many people and seen as undesirable by even more people
note that this uses BLAS that is largely implemented in FORTRAN
> trading off performance (user productivity) for flexibility (developer productivity)

Is this not something that can be helped with more advanced compilers?