Thread: Handling f-write

  1. #16
    Registered User
    Join Date
    May 2012
    Location
    Arizona, USA
    Posts
    948
    Quote Originally Posted by kodax View Post
    From my observations, speed is reduced with large 8mb buffers, as compared to 256kb buffers..
    Without a doubt, large buffers decrease speed significantly.
    Exactly what is your program doing with the buffer? Are you reading from a file into a large buffer then writing it to another file? Many things could be going on that can cause a large buffer to slow you down vs a smaller buffer, depending on exactly what you're doing. Besides that, there's definitely a case of diminishing returns with buffer size for any given application.

    But again, what exactly is your question or issue? Your spewing of random dribbles of statements and theories and irrelevant links to forum posts or books makes it hard to see what your point is.

  2. #17
    Banned
    Join Date
    Jul 2022
    Posts
    112
    Mostly reading and writing..

  3. #18
    Banned
    Join Date
    Jul 2022
    Posts
    112
    in that case,
    all the files from the user's directory.

  4. #19
    Registered User
    Join Date
    Sep 2020
    Posts
    425
    Why not FAFO, and test it yourself? This is my laptop's HDD performance for reading a 56MB file with different block sizes:

    Code:
    0.5k  3.3 MB/s
    1k    6.8 MB/s
    4k    44.5 MB/s
    16k   157 MB/s
    32k   286 MB/s
    64k   502 MB/s
    128k  836 MB/s
    256k  581 MB/s
    512k  795 MB/s
    1024k 866 MB/s

  5. #20
    Registered User
    Join Date
    Feb 2019
    Posts
    1,078
    This contradicts the assumption.
    Best speeds in green.


    $ i=4096; while [ $i -le $(bc <<< '2^25') ]; do echo -ne "\e[1;33m$i\e[m: "; dd if=/dev/zero of=./file.bin bs=$i count=100 2>&1 | sed -nE '/B\/s/p'; i=$((i*2)); done
    4096: 409600 bytes (410 kB, 400 KiB) copied, 0,000410758 s, 997 MB/s
    8192: 819200 bytes (819 kB, 800 KiB) copied, 0,000500906 s, 1,6 GB/s
    16384: 1638400 bytes (1,6 MB, 1,6 MiB) copied, 0,000894711 s, 1,8 GB/s
    32768: 3276800 bytes (3,3 MB, 3,1 MiB) copied, 0,00154947 s, 2,1 GB/s
    65536: 6553600 bytes (6,6 MB, 6,2 MiB) copied, 0,002985 s, 2,2 GB/s

    131072: 13107200 bytes (13 MB, 12 MiB) copied, 0,0414716 s, 316 MB/s
    262144: 26214400 bytes (26 MB, 25 MiB) copied, 0,0672004 s, 390 MB/s
    524288: 52428800 bytes (52 MB, 50 MiB) copied, 0,131374 s, 399 MB/s
    1048576: 104857600 bytes (105 MB, 100 MiB) copied, 0,224383 s, 467 MB/s
    2097152: 209715200 bytes (210 MB, 200 MiB) copied, 0,480652 s, 436 MB/s
    4194304: 419430400 bytes (419 MB, 400 MiB) copied, 0,959415 s, 437 MB/s
    8388608: 838860800 bytes (839 MB, 800 MiB) copied, 2,00964 s, 417 MB/s
    16777216: 1677721600 bytes (1,7 GB, 1,6 GiB) copied, 9,57332 s, 175 MB/s
    33554432: 3355443200 bytes (3,4 GB, 3,1 GiB) copied, 23,2783 s, 144 MB/s
    Last edited by flp1969; 11-23-2022 at 06:38 PM.

  6. #21
    Registered User
    Join Date
    Sep 2020
    Posts
    425
    Quote Originally Posted by flp1969 View Post
    This contradicts the assumption.
    Best speeds in green.


    $ i=4096; while [ $i -le $(bc <<< '2^25') ]; do echo -ne "\e[1;33m$i\e[m: "; dd if=/dev/zero of=./file.bin bs=$i count=100 2>&1 | sed -nE '/B\/s/p'; i=$((i*2)); done
    4096: 409600 bytes (410 kB, 400 KiB) copied, 0,000410758 s, 997 MB/s
    8192: 819200 bytes (819 kB, 800 KiB) copied, 0,000500906 s, 1,6 GB/s
    16384: 1638400 bytes (1,6 MB, 1,6 MiB) copied, 0,000894711 s, 1,8 GB/s
    32768: 3276800 bytes (3,3 MB, 3,1 MiB) copied, 0,00154947 s, 2,1 GB/s
    65536: 6553600 bytes (6,6 MB, 6,2 MiB) copied, 0,002985 s, 2,2 GB/s

    131072: 13107200 bytes (13 MB, 12 MiB) copied, 0,0414716 s, 316 MB/s
    262144: 26214400 bytes (26 MB, 25 MiB) copied, 0,0672004 s, 390 MB/s
    524288: 52428800 bytes (52 MB, 50 MiB) copied, 0,131374 s, 399 MB/s
    1048576: 104857600 bytes (105 MB, 100 MiB) copied, 0,224383 s, 467 MB/s
    2097152: 209715200 bytes (210 MB, 200 MiB) copied, 0,480652 s, 436 MB/s
    4194304: 419430400 bytes (419 MB, 400 MiB) copied, 0,959415 s, 437 MB/s
    8388608: 838860800 bytes (839 MB, 800 MiB) copied, 2,00964 s, 417 MB/s
    16777216: 1677721600 bytes (1,7 GB, 1,6 GiB) copied, 9,57332 s, 175 MB/s
    33554432: 3355443200 bytes (3,4 GB, 3,1 GiB) copied, 23,2783 s, 144 MB/s
    Measuring anything over 0,000500906s seems to be a bit optimistic.

    It does also highlight that the performance of reads and writes is largely dependent on the what you are reading/writing from.

  7. #22
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    The OP better start posting code to backup their questions.
    Otherwise, it's looking like a repost bot just posting links to random sites.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Lot of WRITE calls in parallel in C WRITE test code
    By Bobby1995 in forum C Programming
    Replies: 2
    Last Post: 04-28-2020, 08:47 AM
  2. Replies: 9
    Last Post: 09-09-2014, 08:23 AM
  3. File Handling -Read write and edit a file
    By aprop in forum C Programming
    Replies: 3
    Last Post: 02-27-2010, 02:01 PM
  4. signal handling and exception handling
    By lehe in forum C++ Programming
    Replies: 2
    Last Post: 06-15-2009, 10:01 PM
  5. handling file rb+ (write back into self)
    By IsmAvatar2 in forum C Programming
    Replies: 5
    Last Post: 01-23-2007, 09:47 PM

Tags for this Thread