Comments for Software Ramblings http://softwareramblings.com Stephen Doyle's Ramblings on Software Engineering Thu, 22 Mar 2012 19:33:43 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Comment on About Stephen Doyle by James A. McCombe http://softwareramblings.com/about-2/comment-page-1#comment-1299 James A. McCombe Thu, 22 Mar 2012 19:33:43 +0000 http://softwareramblings.com/?page_id=2#comment-1299 Hi Stephen, I have been trying to figure out how to allocate memory with the pages marked as USWC (uncacheable write combined) on Mac OS X. I am implementing a high performance DMA pipeline for a custom hardware device on the PCIe bus and am trying to avoid the DMA buffers from polluting the CPU cache hierarchy since they are written once by the CPU and then never read again by it. In order to use the streaming load/store instruction in SSE, it appears one must mark this memory region as USWC. I can see how to to do it on Windows and Linux, but not Mac OS X. If you happen to know of the top of your head, that would be great. No worries if you haven't had to deal with this before! Kind Regards, --James Hi Stephen,

I have been trying to figure out how to allocate memory with the pages marked as USWC (uncacheable write combined) on Mac OS X. I am implementing a high performance DMA pipeline for a custom hardware device on the PCIe bus and am trying to avoid the DMA buffers from polluting the CPU cache hierarchy since they are written once by the CPU and then never read again by it. In order to use the streaming load/store instruction in SSE, it appears one must mark this memory region as USWC. I can see how to to do it on Windows and Linux, but not Mac OS X.

If you happen to know of the top of your head, that would be great. No worries if you haven’t had to deal with this before!

Kind Regards,
–James

]]> Comment on Passing options in Ruby by Seanba http://softwareramblings.com/2010/12/passing-options-in-ruby.html/comment-page-1#comment-140 Seanba Thu, 30 Dec 2010 20:52:09 +0000 http://softwareramblings.com/?p=338#comment-140 Nice. The merge API on hashtables is a great feature. Nice. The merge API on hashtables is a great feature.

]]> Comment on Passing options in Ruby by matnotfat http://softwareramblings.com/2010/12/passing-options-in-ruby.html/comment-page-1#comment-134 matnotfat Fri, 17 Dec 2010 23:36:43 +0000 http://softwareramblings.com/?p=338#comment-134 As frequently seen in the jQuery plugins. It really does work nice. It lets you offer tons of options, and keep it transparent to the user for most cases. As frequently seen in the jQuery plugins. It really does work nice. It lets you offer tons of options, and keep it transparent to the user for most cases.

]]> Comment on Post-Increment vs Pre-Increment by Ofek http://softwareramblings.com/2010/01/post-increment-vs-pre-increment.html/comment-page-1#comment-122 Ofek Sat, 30 Jan 2010 21:57:16 +0000 http://softwareramblings.com/?p=317#comment-122 Huh?? some markup mix trashed my comment. Here goes again, with explicit URLs: Andrew Koenig probably sealed the pre/post increment argument permanently: http://dobbscodetalk.com/index.php?option=com_myblog&show=Efficiency-versus-intent.html&Itemid=29 . Or at least should have. The question still arises now and then, and there's a wide consensus that in regular uses (e.g. using integers to iterate in a loop) there's no performance difference for ~3 decades now: http://stackoverflow.com/questions/24886?tab=oldest#tab-top Huh?? some markup mix trashed my comment. Here goes again, with explicit URLs:
Andrew Koenig probably sealed the pre/post increment argument permanently: http://dobbscodetalk.com/index.php?option=com_myblog&show=Efficiency-versus-intent.html&Itemid=29 .
Or at least should have. The question still arises now and then, and there’s a wide consensus that in regular uses (e.g. using integers to iterate in a loop) there’s no performance difference for ~3 decades now: http://stackoverflow.com/questions/24886?tab=oldest#tab-top

]]> Comment on Post-Increment vs Pre-Increment by Ofek http://softwareramblings.com/2010/01/post-increment-vs-pre-increment.html/comment-page-1#comment-121 Ofek Sat, 30 Jan 2010 21:54:28 +0000 http://softwareramblings.com/?p=317#comment-121 <a href="http://dobbscodetalk.com/index.php?option=com_myblog&show=Efficiency-versus-intent.html&Itemid=29" rel="nofollow"> probably sealed the pre/post increment argument permanently. Or at least should have. The question <a href="http://stackoverflow.com/questions/24886?tab=oldest#tab-top" rel="nofollow">now and then, and there's a wide consensus that in regular uses (e.g. using integers to iterate in a loop) there's no performance difference for ~3 decades now. probably sealed the pre/post increment argument permanently. Or at least should have. The question now and then, and there’s a wide consensus that in regular uses (e.g. using integers to iterate in a loop) there’s no performance difference for ~3 decades now.

]]> Comment on Post-Increment vs Pre-Increment by ondra http://softwareramblings.com/2010/01/post-increment-vs-pre-increment.html/comment-page-1#comment-119 ondra Fri, 29 Jan 2010 16:07:42 +0000 http://softwareramblings.com/?p=317#comment-119 There isn't any reason for these two to differ if you don't use the result at all. There isn’t any reason for these two to differ if you don’t use the result at all.

]]> Comment on Post-Increment vs Pre-Increment by KristofU http://softwareramblings.com/2010/01/post-increment-vs-pre-increment.html/comment-page-1#comment-118 KristofU Fri, 29 Jan 2010 15:14:48 +0000 http://softwareramblings.com/?p=317#comment-118 The best reason for always using pre-increment/decrement is the genericity of the code. A certain algorithm may one day become a generic one, and the types passed into it may no longer be simple ints. The best reason for always using pre-increment/decrement is the genericity of the code.
A certain algorithm may one day become a generic one, and the types passed into it may no longer be simple ints.

]]> Comment on Update: STL vs Gnulib Performance by Stephen Doyle http://softwareramblings.com/2009/06/update-stl-vs-gnulib-performance.html/comment-page-1#comment-59 Stephen Doyle Mon, 29 Jun 2009 20:26:07 +0000 http://softwareramblings.com/?p=222#comment-59 yoco - compiler is gcc v4.0.1 and -O2 optimization yoco – compiler is gcc v4.0.1 and -O2 optimization

]]> Comment on Update: STL vs Gnulib Performance by yoco http://softwareramblings.com/2009/06/update-stl-vs-gnulib-performance.html/comment-page-1#comment-58 yoco Mon, 29 Jun 2009 19:19:41 +0000 http://softwareramblings.com/?p=222#comment-58 What's your compiler and compile option? Debug version or optimized release version? The result is dramatically different. What’s your compiler and compile option? Debug version or optimized release version? The result is dramatically different.

]]> Comment on Update: STL vs Gnulib Performance by Stephen Doyle http://softwareramblings.com/2009/06/update-stl-vs-gnulib-performance.html/comment-page-1#comment-56 Stephen Doyle Sun, 28 Jun 2009 20:46:38 +0000 http://softwareramblings.com/?p=222#comment-56 Hi ADL - See the reference to the previous post for details on methodology and source code. Insert is more correctly named push_back. Searching is using the stl::find algorithm for STL and its an unsorted search. A sorted search is another test. Hi ADL – See the reference to the previous post for details on methodology and source code. Insert is more correctly named push_back. Searching is using the stl::find algorithm for STL and its an unsorted search. A sorted search is another test.

]]>