home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 32,845 of 33,346   
   =?ISO-8859-1?Q?=D6=F6_Tiib?= to All   
   Re: iostream replacement   
   30 Jan 13 21:39:57   
   
   From: ootiib@hot.ee   
      
   { Reformatted; please limit your lines to 70 characters -mod }   
      
   On Tuesday, 29 January 2013 05:05:08 UTC+2, fmatthew5876  wrote:   
   > > On my system write(2) writes 10,000,000 floats in 0.7 seconds.   
   > > printf requires 6 seconds, and operator<< 9 seconds.   
   >   
   > You'll have to show how you performed this test first. If you just   
   > did   
   > cout << f;   
   > or   
   > printf("%f", f);   
   >   
   > 10,000,000 times then it doesn't invalidate my point about function   
   > calls and locks.   
      
   What point of locks?   
      
   When the recipient is made of meat then those can't handle even 1000   
   floats per second. That means printf, iostream or boost::format exceed   
   that speed by orders of magnitude. So for human readable   
   interface/trace it is fine.   
      
   The text formats work also fine between applications when the amount   
   communicated is low. Then it does not really matter if you first   
   boost::format and then << to stream. It is not bottle-neck so it does   
   not affect overall performance how efficient that operation is.   
      
   If it is desirable to communicate 10 millions of floats per second (on   
   his system) then neither printf nor iostream can deliver that. Also   
   you further mention doing really big, efficient and atomic data   
   forwarding. On such cases forget text i/o, use databases or binary   
   protocols.   
      
   Whenever you see ini, json or xml (or what not) text file that is   
   hundreds of megabytes large then that is trying take place of binary   
   formats and databases. Human, who opens it can't handle it anyway   
   unaided. Software that opens it is doomed to perform 10 times worse   
   than when using some structured binary format or database. So   
   lose-lose-lose situation.   
      
   Such nonsense can only work because our users are without choice and   
   so have to be patient.   
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca