Slashdot Mirror
Intel Develops Hardware To Enhance TCP/IP Stacks
RyuuzakiTetsuya writes "The Register is reporting that Intel is developing I/OAT, or I/O Acceleration Technology, which allows the CPU, the mobo chipset and the ethernet controller to help deal with TCP/IP overhead."
Yet another processor that requires liquid nitrogen.
I just heard some sad news on talk radio - author Hunter S. Thompson was found dead in his Colorado home this morning. There weren't any more details yet. I'm sure we'll all miss him, even if you weren't a fan of his work there's no denying his contribution to popular culture. Truly an American icon.
From what I've heard, nVidia's implementation is sucking major ass.
With the ever growing wishes by some to get first posts, I think the little time to write a post may yield that kind of quality.
Beware: In C++, your friends can see your privates!
there is TRULY nothing to fucking live for now.
FUCK me lightly with a chainsaw.
FUCK FUCK FUCK FUCK FUCK FUCK
be treatEd by your to its laid-back
Bonnie Raitt's pop passed on too. Broadway star John Raitt just bought the farm.
Reading that post made me stupider. Oh no! Look what you've done! My brain is coming out of my head!
when I was actively doing programming, I got into the bad habit of doing:
int x = 0;
Non impediti ratione cogitationus.
http://www.cnn.com/2005/SHOWBIZ/books/02/21/thomps on.obit/index.html
Wow, that's horrible. It's almost like you're defining it before using it? Crazy, how that works out just like I suggested.
Now all we need is a "zero-copy" network API.
/* all data in foo sent to remote host! */
/* set by the OS */
... */
In linux, for example, the send() system call copies all the data to kernel space. A waste of CPU cycles IMHO.
FreeBSD implements "zero-copy" networking by using copy-on-write pages. Ie. you allocate PAGE_SIZE amount of memory aligned to PAGE_SIZE and try not to touch it. This approach sucks donkey ballz, but i suppose it's better than nothing.
Something like this would be much better...
foo = malloc(1024);
/* TODO: put data in foo here */
sent = zc_send(socket, foo, 1024, 0);
/* don't touch the memory foo points to until the kernel tells you it's ok */
FD_SET(bar, &baz);
n = select(bar + 1, &baz, &baz, NULL, NULL);
if(n == 1)
{
foo = zc_memory_ptr_used();
if(foo != NULL) free(foo);
}
And while I'm at it... UNIX REALLY needs a system call that sends and receives data from multiple sockets.
struct network_vector
{
int socket;
void *data;
int len;
int flags;
int retval;
};
struct network_vector foo[200];
foo[0].socket = socket();
foo[0].data = malloc(1024);
foo[0].len = 1024;
foo[1].socket = socket();
foo[1].data = malloc(1024);
foo[1].len = 1024;
/*
/* voila, 200 system calls at the cost of 1 */
zc_sendv(&foo, 200);
The performance improvements would be truely ubar and amazing.
"Who-cares-just-get-a-faster-CPU" and Java lovers need not reply.
I say the last digit of pi is zero
Do your best, hope for the best, suspect the worst.
So it goes on and on...
x86 has gotten 32bit extensions, protected mode, MMX, 3DNow, MMX2, SSE, SSE2, 64bit extensions (+ some new registers), and now another special-purpose instruction set (?) enhancement.
PPC, on the other hand, has been a 64bit instruction set from the beginning (of the '90s, that is); has had one SIMD instruction set (Altivec) that many claim to be superior to all that SSE stuff; and it has lots of nice registers and cool instructions that are much more fun to use for any compiler than the Intel crap.
Oh, and PPC hasn't changed through all those years, so you don't have to learn new instruction sets all the time (and program that damn chip in assembly, because compilers don't know the extensions, yet!).
Ha! Typical male chauvinistic obsession with faster, faster - when everybody knows that when it comes to sex you actually strive for SLOWNESS and PROLONGING. We don't need no fucking porn accelerator :-)