查看完整版本: [-- 64位win7+32位vs2003的debug的问题…… --]

-> 同人游戏创作/Doujin Games Workshop -> 64位win7+32位vs2003的debug的问题…… [打印本页] 登录 -> 注册 -> 回复主题 -> 发表主题

h5nc 2010-03-04 12:37

64位win7+32位vs2003的debug的问题……

今天调试了一天……………………………………………………………………………………
=AAAAAAAAAAAAAA=什么东西啊!

64位win7,devnev是32位的,2003,F5调试的时候会严重影响效率,在外面直接运行编译的exe效率完全正常……编译器是icl,貌似是32+64位的都装了,不知道会调用哪个……
我感觉主要是IDE的问题,不过不知道怎么办,超级不想用2008,VC助手和Inter编译器忘了哪个不能在2008用了……
而且有个现象,F5之后不方块停止调试而是程序自己退出的话devnev会锁住pdb文件……
有什么解决方法么?还是2003还能更新么?

顺便再求随便谁做个命令行的unlocker吧……命令行解锁所有相关进程……

PS我是正版home的米虚拟机可用嗯……

littlewater 2010-03-04 19:04
2010 即将出了^^

ryuka 2010-03-04 19:12
h5大在美国过的滋润吗? win7 还没怎么用过..不过vc2003我感觉不爽哎..

h5nc 2010-03-05 05:30
嗯,网速十分滋润……
顺便我有在用2010,beta2,编译后调试速度依旧非常泪目,拿出来单独运行没问题
难道64位系统调试32位程序就是这样么……

另外不知道为啥fscanf类似物用%s%d后后面的%d不会出正常数字……icl下米问题……

貘良了 2010-03-05 13:26
64位windows7都不是平常电脑会接触的东,我也还是用XP。

鸡蛋灌饼 2010-03-05 20:51
引用第3楼h5nc于2010-03-05 05:30发表的  :
嗯,网速十分滋润……
顺便我有在用2010,beta2,编译后调试速度依旧非常泪目,拿出来单独运行没问题
难道64位系统调试32位程序就是这样么……
另外不知道为啥fscanf类似物用%s%d后后面的%d不会出正常数字……icl下米问题……

准确点说,调试都这样……
x64明显点而已……

另外,可能的话Toolchain还是用新的好,ICC那东西我觉得不到Release的时候没必要拿出来……

h5nc 2010-03-06 08:06
不过偶觉得偶的机器调试这种游戏再会卡的话就米啥机器能调试大型游戏了啊……………………
i7 2.8G+8G+5770,跑生化5全效果都没卡过……

我主要是在考虑SVN结构问题,如果把2010的相关文件传上去的话就丧失了原来Intel和VS2003兼容编译的条件了……
而且……从2003到2010改了好多……………………就算直接丢到Intel那里也不能编译通过了……

Advance 2010-03-06 15:05
编译输出PDB,用WINDBG调试

鸡蛋灌饼 2010-03-07 01:18
引用第7楼Advance于2010-03-06 15:05发表的  :
编译输出PDB,用WINDBG调试

我觉得大点的工程都要TDD+Log才玩的起来
特别是网络相关的……
很不幸我正在写一个这样的东西……

Advance 2010-03-07 01:38
LINUX工作者会告诉你再大的工程都是用printk和printf调出来的,当然这也是一种LOG啦

h5nc 2010-03-07 09:02
唔……设置了2008之后没有特别费劲的问题了……
debug速度依旧诡异,但还可以忍受……最关键的索那啥,过一会就降成30FPS,然后切换焦距后回来就ok……
WINDBG看看去……

sjmind 2010-03-07 11:23
我记得貌似是因为32位程序进行内存对齐后对于64位是不对齐的,根据实际对齐的结果,有些位置的读取会相当慢,比如两个64为的字在32位下对齐为XXAABBBBBBBBCCCC,X为填充,读取B,此时其读取速度比在32位机上还要慢很多.并且VS的DEBUG本身就慢,两个碰在一起就泪目了.

所以最好用64位编译器,或者把内存对齐调到64位的字大小.至于VS的DEBUG直接扔了就行,我前阶段做的引擎Release之后可以保证60FPS,但是用VS的DEBUG的话至多也就10FPS = =

Advance 2010-03-07 12:15
当然不是内存的问题,纯粹VS渣啊,你看OD不一样很好用

IDE什么的最无聊了

sjmind 2010-03-07 12:31
32位编64位没对齐是有损耗的,多少不知道,貌似在windows核心编程里应该提到过
#pragma pack(16)
能够搞掉对齐问题

摘一段别的地方的:
"
在'Data alignment: Straighten up and fly right'这篇文章中作者还得出一个结论那就是:"如果访问的地址是unaligned的,那么采用大粒度访问内存有可能比小粒度访问内存还要慢"。
"

Advance 2010-03-07 12:38
233MAX

有损耗不代表它就是慢的罪魁祸首,而且跟调试慢一点关系都没有,拜托你仔细看一下顶楼的内容呀不要答非所问囧

h5nc 2010-03-07 12:38
偶滴debug丢出来用64位win7直接运行Ctrl加速3倍也60米问题啊……………………
偶用VS只因为有VAX……我用Intel编译器,也不用基本任何别的功能,现在就调试这一块还依赖着呢……
其实转向leah之后有lua报错已经不怎么用调试了,但怕有未知问题会偶遇,所以还依赖着……
特别不爽……
有扩展VS的调试的软件么 内嵌型

sjmind 2010-03-07 12:56
传说vshost能够提高调试性能,但是具体怎样我不清楚

sjmind 2010-03-07 13:05
话说,VS貌似自己有64位的特别优化

另外不知道这个是不是对你有用
http://msdn.microsoft.com/zh-cn/library/h2k70f3s(VS.80).aspx

鸡蛋灌饼 2010-03-07 14:41
引用第13楼sjmind于2010-03-07 12:31发表的 回 12楼(Advance) 的帖子 :
32位编64位没对齐是有损耗的,多少不知道,貌似在windows核心编程里应该提到过
#pragma pack(16)
能够搞掉对齐问题
摘一段别的地方的:
.......

233
现在编译器默认都按double(fp64)对齐的
引用第15楼h5nc于2010-03-07 12:38发表的  :
偶滴debug丢出来用64位win7直接运行Ctrl加速3倍也60米问题啊……………………
偶用VS只因为有VAX……我用Intel编译器,也不用基本任何别的功能,现在就调试这一块还依赖着呢……
其实转向leah之后有lua报错已经不怎么用调试了,但怕有未知问题会偶遇,所以还依赖着……
特别不爽……
有扩展VS的调试的软件么 [表情] 内嵌型

VS的调试能力已经很强了,还能怎么扩展啊
Windows下VS是最强IDE,其他的一个能打的都没有

sjmind 2010-03-08 10:49

现在编译器默认都按double(fp64)对齐的

不是按照8字节对齐的
至少我在32-bit VS2008下面是默认4字节对齐的

VS的调试能力已经很强了,还能怎么扩展啊
Windows下VS是最强IDE,其他的一个能打的都没有


能力!=性能,

鸡蛋灌饼 2010-03-08 22:42
引用第7楼Advance于2010-03-06 15:05发表的  :
编译输出PDB,用WINDBG调试

一个很讨厌的事情就是如果进入系统代码,windbg就给你提示没symbol文件——除非自己去下……

Advance 2010-03-09 16:45
是的,下好SYMBOL,然后像这样建个LNK
"C:\Program Files\Debugging Tools for Windows (x86)\windbg.exe" -y d:\win7symbols

用WINDBG最好都先这么干


查看完整版本: [-- 64位win7+32位vs2003的debug的问题…… --] [-- top --]


Powered by phpwind v8.7 Code ©2003-2011 phpwind
Time 0.022661 second(s),query:2 Gzip enabled