Issues with Stdout

Linker Joined: 11/06/06 Posts: 9

Posted: 07/04/07 18:46:03 Hello everyone. I've coded a tiny raytracer today. It uses Phobos to output to stdout, and runs pretty fast for it's simplicity. Yesterday I did more or less the same raytracer, but it used Tango's Stdout object to print to console. In both cases, stdout is redirected to file. But I get really poor performance on Tango (I'm using v0.98). Two raytracers are essentially the same, but one that uses std.stdio.writef() runs about a magnitude faster. Also, do I have to flush Stdout manually? If I don't do it myself, I don't get any output at all. So I have to call the 'newline' method every time I choose to print anything. Is this right? I'm not quite sure where the bottleneck is right now (I haven't profiled nor debugged my code), but I suspect it's on Tango's side. I'll do more checks when I have the time and post the results here. I had similar issues with streaming buffers (Tango's iterators for files). It was reading file chunk by chunk in a streaming fashion -- and that was very, very slow. I replaced that with single file read into temporary buffer -- and it gave me 10-fold speed boost.

Author	Message
pragma Joined: 05/28/04 Posts: 52	Posted: 07/05/07 15:15:50 Linker wrote: Also, do I have to flush Stdout manually? If I don't do it myself, I don't get any output at all. So I have to call the 'newline' method every time I choose to print anything. Is this right? I think you can just call Stdout.flush() and forget about using .newline. As for the performance issues, I'm in the dark as well. -- EricAnderton at yahoo
kris Joined: 03/27/04 Posts: 581	Posted: 07/05/07 17:36:41 Linker wrote: Hello everyone. I've coded a tiny raytracer today. It uses Phobos to output to stdout, and runs pretty fast for it's simplicity. Yesterday I did more or less the same raytracer, but it used Tango's Stdout object to print to console. In both cases, stdout is redirected to file. But I get really poor performance on Tango (I'm using v0.98). Two raytracers are essentially the same, but one that uses std.stdio.writef() runs about a magnitude faster. Also, do I have to flush Stdout manually? If I don't do it myself, I don't get any output at all. So I have to call the 'newline' method every time I choose to print anything. Is this right? I'm not quite sure where the bottleneck is right now (I haven't profiled nor debugged my code), but I suspect it's on Tango's side. I'll do more checks when I have the time and post the results here. I had similar issues with streaming buffers (Tango's iterators for files). It was reading file chunk by chunk in a streaming fashion -- and that was very, very slow. I replaced that with single file read into temporary buffer -- and it gave me 10-fold speed boost. That's very odd. I would guess that this is on linux?
kris Joined: 03/27/04 Posts: 581	Posted: 07/08/07 20:53:04 Turns out that invoking flush() on linux can be expensive, which is why I was asking about your O/S. To make a long story short, tango.io.Console/Stdout tries to avoid the complexities of the clib model with respect to redirection ... eliminating basically all of the special cases. Cout.newline() currently always invokes Cout.flush() to ensure the console output is visible, and does this regardless of whether redirection is applied or not. I've added an experimental version(RedirectNoFlush) within tango.io.Console, which I'd like to ask you to try? It sidesteps an automatic call to Cout.flush() when the console output is redirected. This will obviously require a flush() at some point before the redirected process exits, which Console does within its module dtor. Please let us know what the impact is in terms of performance and utility? Thanks;
Linker Joined: 11/06/06 Posts: 9	Posted: 07/10/07 14:07:57 First of all, excuse me for not naming the OS. I am very sorry. :( The OS I did tests on was Windows Vista. I've added an experimental version(RedirectNoFlush?) within tango.io.Console, which I'd like to ask you to try? Okay, where do I get it?
kris Joined: 03/27/04 Posts: 581	Posted: 07/10/07 20:03:30 Via SVN trunk ... it will be in the forthcoming release also :)