我只知道对齐内存分配的基本思路.但我并不关心对齐问题,因为我不是汇编程序员,也没有MMX/SIMD的经验.而且我认为这是过早优化之一.
这些天人们越来越多地谈论缓存命中,缓存一致性,大小优化等.一些源代码甚至分配在CPU缓存行上显式对齐的内存.
坦率地说,我不知道我的i7 CPU的缓存行大小是多少.我知道大尺寸对齐没有坏处.但是没有SIMD会真的得到回报吗？
假设程序中有100000项100字节数据.访问这些数据是该计划最密集的工作.
如果我们改变数据结构并使所有100字节大小的数据按16字节对齐,是否可以获得显着的性能增益？10%？5%？
(我搜索了SO的答案,发现这个问题没有明确的解决方案.)
我正在研究MFC GUI程序.该程序运行各种子程序,包括控制台程序和shell命令脚本(.cmd).
最初它显示了一个GUI窗口和一个控制台窗口(由其创建AllocConsole),因为子进程有许多控制台输出.但是很多用户抱怨控制台窗口所以我们决定隐藏控制台窗口.
首先尝试如下:
if (AllocConsole())
{
::ShowWindow(::GetConsoleWindow(), SW_HIDE);
}
好的,没有控制台窗口,但在控制台创建时有可见的闪烁.我已经尝试了几个CreateProcess子进程创建选项,以防止完全显示控制台窗口,但总之失败,我认为这几乎是不可能的.
这不是什么大不了的事.我们可以在启动时忽略临时窗口闪烁.
但完全隐藏儿童游戏机窗口真的不可能吗？
如果有英特尔VTune放大器经验丰富的人告诉我这个问题,我将非常感激.
最近我收到了其他使用英特尔VTune放大器的人的性能分析报告.它告诉我,线程并发区域的开销时间很长.
开销时间的含义是什么？他们不知道(问我),我没有访问英特尔VTune Amplifier.
我有一些模糊的想法.这个程序有许多线程睡眠调用,因为pthread condition在目标平台上不稳定(或者我做得很糟糕)所以我改变了很多例程来在循环中做的工作如下所示:
while (true)
{
mutex.lock();
if (event changed)
{
mutex.unlock();
// do something
break;
}
else
{
mutex.unlock();
usleep(3 * 1000);
}
}
这可以标记为开销时间？
有什么建议？
我从英特尔网站上找到了有关开销时间的帮助文档. http://software.intel.com/sites/products/documentation/hpc/amplifierxe/en-us/win/ug_docs/olh/common/overhead_time.html#overhead_time
摘抄:
开销时间是从共享资源的发布开始并以收到该资源结束的持续时间.理想情况下,开销时间的持续时间非常短,因为它减少了线程必须等待获取资源的时间.但是,并行应用程序中的所有CPU时间可能不会用于执行实际的工资负载工作.在并行运行时(英特尔®线程构建模块,OpenMP*)使用效率低的情况下,可能会在并行运行时内花费大量时间在高并发级别上浪费CPU时间.例如,这可能是由于递归并行算法中的低粒度工作分割造成的:当工作负载大小变得太低时,分割工作和执行内务工作的开销变得很大.
仍然令人困惑..这是否意味着"你做了不必要/太频繁的锁定"？
最近注意到MSDN中FILE_FLAG_NO_BUFFERING标志的详细描述,并阅读了几个关于Windows中无缓冲I/O的Google搜索结果.
http://msdn.microsoft.com/en-us/library/aa363858(v=vs.85).aspx
我现在想知道,在文件I/O编程中考虑无缓冲选项是否真的很重要？因为许多程序使用普通的旧C流I/O或C++ iostream,所以我之前没有注意过FILE_FLAG_NO_BUFFERING标志.
假设我们正在开发像Picasa这样的照片浏览器程序.如果我们实现无缓冲的I/O,缩略图显示速度是否会在普通用户中显示出明显的差异？
我计时了一个使用多个StretchBlt和StretchDIBits调用的DDB绘图操作.
我发现,完成时间与目标窗口大小成比例地增加/减少.
使用900x600窗口需要大约5ms,但是对于1920x1080,它需要大约55ms(源图像是1280x640).
看来Stretch .. API不使用任何硬件加速功能.
创建源图像(实际上这是临时绘图画布)CreateDIBSection因为我需要为绘制的每个帧生成(拉伸和合并)位图的像素数据.
让我们假设,Windows GDI是没有希望的.那么有希望的替代方案是什么？
我考虑使用WIC方法的D3D,D2D(写入WIC位图并使用D2D绘制它然后从WIC位图读回像素数据).
我计划用WIC方法尝试D2D,因为我需要很快使用大量的文本绘图功能.
但似乎WIC并不那么有希望:WIC位图处理最有效的像素格式是什么？
我正在尝试使用Direct2D和WIC Bitmap制作一个简单的视频播放器.
它需要YUV像素格式帧数据的快速和CPU经济绘制(具有拉伸).
我已经用GDI测试了.我希望切换到Direct2D可以获得至少10倍的性能提升(较小的CPU开销).
我要做的基本上如下:
对于1,2步,我必须选择像素格式.
WIC Native Pixel格式
有一个MSDN页面推荐WICPixelFormat32bppPBGRA.
http://msdn.microsoft.com/en-us/library/windows/desktop/hh780393(v=vs.85).aspx
有什么区别WICPixelFormat32bppPBGRA和WICPixelFormat32bppBGRA？(前者有额外的P)
如果WICPixelFormat32bppPBGRA是要走的路,总是这样吗？无论硬件和/或配置？
实际上WIC位图处理最有效的像素格式是什么？
我现在重读"过渡到ARC发行说明".
一开始,它说
Xcode 4.2支持OS for OS X v10.6和v10.7(64位应用程序)以及iOS 4和iOS 5.OS X v10.6和iOS 4不支持弱引用.
为什么是这样？实施弱引用是否需要深入平台/ OS支持？
我想,弱引用并不那么特别(考虑到C++原始指针的用法).
这可能不是技术原因吗？(弱参考支持被删除,因为它失败了几个测试用例并且没有足够的时间？)
我有一个内存损坏错误(我怀疑),这导致程序在特定UI操作后崩溃.这是一个Cocoa Objective-C应用程序,不使用GC.
经过几个小时的调试,我发现了崩溃的可能原因:
DiscSelectPopup *popupSelect = [[DiscSelectPopup alloc] initWithDataList:dataList count:count];
NSInteger result = [NSApp runModalForWindow:popupSelect.window];
上面的弹出例程是从辅助线程执行的.每次用户单击按钮时,都会创建并启动此线程.因此,我们可以同时显示几个模态弹出窗口.
当我使用MallocStackLogging=1和在调试模式下运行程序时MallocStackLoggingNoCompact=1,它会在runModalForWindow:调用时打印malloc错误日志消息(但并非总是如此).
malloc: *** error for object 0xbc65840: double free
.....
malloc: *** error for object 0xbc547e0: pointer being freed was not allocated
runModalForWindow:从辅助线程使用真的很糟糕吗？
这可能是坠机的原因吗？