Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

RMS Matthew Stallman's magic library

Name: Anonymous 2011-01-06 12:33

Why is glibc's fwrite_unlocked faster than the write syscall?

Name: Anonymous 2011-01-06 12:35

It's the power of free software.

Name: Anonymous 2011-01-06 12:42

It's the Power of GNUFreedom.

Name: Anonymous 2011-01-06 13:03

>>1
Because it does not lock the global mutex on the file object. Locking a global resource has overhead. However, you should probably not use the unlocked versions of those functions. It is not thread/process-safe.

Name: Anonymous 2011-01-06 13:44

>>4

Thank you for answering, do you know what kind of magic puts uses to outrun the write syscall?

Name: Anonymous 2011-01-06 13:49

>>5
If you don't know how something works, you find out, which usually means:
1) Is source available? Read it!
2) Is source not available? Disassemble it, use symbols if any are available, otherwise, make sense of it without them.

Name: Anonymous 2011-01-06 13:59

>>4
No.
>>5
It's called not doing a fucking syscall.  Christ are you dense.

Name: Anonymous 2011-01-06 14:03

>>7
Source code to glibc and the linux kernel is available. I suggest you peruse it.

Name: Anonymous 2011-01-06 14:20

>>8
Fuck you.  Learn to unix.

Name: Anonymous 2011-01-06 14:32

>>9
I think our point here was that if you want to understand how something works, you read the implementation (be it source or compiled code). Reading the specification is just meant to show you how an interface is supposed to work, not how it actually works or what its implementation details are. When someone asks a question like "Why is x faster than y?", you usually look at implementation details to find the answer, not at the specification.

Name: Anonymous 2011-01-06 14:45

You also need to understand that fwrite is double-buffered. If you use write, it's only single buffered unless you created the file handle with buffering disabled. puts is probably single-buffered too.

Try using write instead of fwrite.

Name: Anonymous 2011-01-06 15:10

>>10
And our point is that you don't have a clue what you're talking about.  write doesn't lock anything, and the FILE mutex doesn't interact with other processes.  Furthermore, locking a mutex is insignificant compared to the overhead of a syscall.

>>11
Oh come on this is ridiculous

Name: Anonymous 2011-01-06 15:14

>>12
I was never talking about the specifics of write, puts, fwrite and so on. I was just talking about it in general. The same way you tell someone to google something or read SICP.

Name: Anonymous 2011-01-06 22:57

OP here, and I must confess that I had trouble discerning how puts works as I only found macro after macro, running it through the preprocessor didn't help much either.

If any of you could tell me the gist of what's going on I'd appreciate it,

int
_IO_puts (str)
     const char *str;
{
  int result = (-1);
  size_t len = strlen (str);
  _IO_acquire_lock (((_IO_FILE*)(&_IO_2_1_stdout_)));

  if (((((_IO_FILE*)(&_IO_2_1_stdout_)))->_vtable_offset != 0
       || _IO_fwide (((_IO_FILE*)(&_IO_2_1_stdout_)), -1) == -1)
      && ((*(struct _IO_jump_t **) ((void *) &((struct _IO_FILE_plus *) (((_IO_FILE*)(&_IO_2_1_stdout_))))->vtable + (((_IO_FILE*)(&_IO_2_1_stdout_)))->_vtable_offset))->__xsputn) (((_IO_FILE*)(&_IO_2_1_stdout_)), str, len) == len
      && (__builtin_expect (((((_IO_FILE*)(&_IO_2_1_stdout_)))->_IO_write_ptr >= (((_IO_FILE*)(&_IO_2_1_stdout_)))->_IO_write_end), 0) ? __overflow (((_IO_FILE*)(&_IO_2_1_stdout_)), (unsigned char) ('\n')) : (unsigned char) (*(((_IO_FILE*)(&_IO_2_1_stdout_)))->_IO_write_ptr++ = ('\n'))) != (-1))
    result = (((2147483647)<(len + 1))?(2147483647):(len + 1));

  _IO_release_lock (((_IO_FILE*)(&_IO_2_1_stdout_)));
  return result;
}

.

What I'd rather like know now is why syscalls are so expensive, I thought they'd be rather cheap. All I'm looking for the least expensive way to write a character to the stdout file and I'm happy.

Name: Anonymous 2011-01-07 4:38

>>14
you should be buffering instead.

Name: Anonymous 2011-01-07 10:41

>>15

All right, so I should start a different thread and write to a buffer in memory and then return control to the program while letting the thread write the buffer to stdout?

Name: Anonymous 2011-01-07 10:44

>>16
Try and stick to single threads, please. 999 posts is plenty for anyone.

Name: Anonymous 2011-01-07 10:48

>>17
I lol'd because I thought the same.

Name: Anonymous 2011-01-07 10:58

>>17
>>18

All right, which one of you will take responsibility of writing the bytes posted to stdout?

Name: Anonymous 2011-01-07 10:58

>>16
If the only I/O you're doing is writing on stdout, that seems pretty wasteful.

Name: Anonymous 2011-01-07 11:03

>>20

I just want my program to write as fast as RMS Matthew Stallman's puts (3) :-(

Name: Anonymous 2011-01-07 11:06

Lee Jin-gyu kisses his new bride, a pillow with a picture of anime character Fate Testarossa on it

Name: Anonymous 2011-01-07 11:08

>>21
Try setting stdout to unbuffered setvbuf(stdout, 0)

Name: Anonymous 2011-01-07 11:16

>>23

Now all my programs outperform puts!

Name: Anonymous 2011-01-07 11:26

>>14
syscalls are ``cheap''. context-switches aren't.

Name: Anonymous 2011-01-07 17:29

I ended up giving my program a 16 megabyte buffer, and just did one syscall.

Scalable, don't you think?

Now let us celebrate with some cinnamon rolls.

Name: Anonymous 2011-02-03 0:06


Don't change these.
Name: Email:
Entire Thread Thread List