快一个月没发布播放器了，其实我一直在研究怎么做一个至少自己能认同的播放器

thinkspace

交易区新帖推荐

不如我来问LZ吧
1.内核驱动和应用层时钟精度分别是多少？

2.Windows进程和线程的优先级各划分了多少？它们之间的关系是怎样的？Windows是如何调度它们，性能如何？

3.对于内存访问使用的是SMP还是NUMA？你明白SMP和NUMA之间的差异吗？

4.能清楚的明白堆栈(STACK)、堆(HEAP)、分页内存、AWE内存和NUMA内存之间的区别，并正确使用它们吗？

5.（暂时不说了）

clonne

原帖由 thinkspace 于 2012-5-22 23:05 发表
不如我来问LZ吧
1.内核驱动和应用层时钟精度分别是多少？

2.Windows进程和线程的优先级各划分了多少？它们之间的关系是怎样的？Windows是如何调度它们，性能如何？

3.对于内存访问使用的是SMP还是NUMA？你明白 ...

我都不懂，很少学Microsoft Winindow的那些东西，个人感觉Microsoft Winindow本身架构就太臃肿而且充斥着大量影响软件质量的细节。我个人感觉Microsoft Winindow和硬件的交互能力并不强，性能很差。当然比Linux还是好一些的。

1.内核这个应该是纳秒级别（好像是皮秒）

2.实时最高优先级、然后是比正常高2级、高1级、正常、低1级、低2级、然后还一个忘了。性能与调度方面，不清楚。

3.对于内存访问就是使用C++内置的new delete，这个应该是调用的系统API，没技术含量。

4.我还真没研究过这些，栈和堆了解、AWE是一个内存管理扩展，好像只是能让32位程序使用超过4GB的内存吧而已吧？NUME，是那个非一致性内存访问吗？这两个对音频而言到底有什么用？不明白。


5.请问使用AWE内存和NUME内存会对音频有影响吗？

thinkspace

如果我说的这些都不了解，那我觉得你的目标实现起来有困难。

chen0706

2~4操作系统上学过……1答案是多少啊

kyokyo

给大家介绍一下AWE。AWE是32位系统下的延伸产物。32位系统应用程序只能访问4G内存空间（2的32次方，别去算了，大家公认的）。
但是，现在计算机发展迅速，有些及其已经拥有超过4G的内存，8G/16G都很多。为了让32位系统访问到这些内存。AWE就应运而生了。
AWE就是允许不同的应用，申请到一段物理内存，然后映射到自己的4G空间内。不同的应用都有自己的4G空间（其实有部分内核空间是共享
的，这里忽略）。例如，你有4个应用，每个4G，映射到不同的物理内存段，正好用光16G内存。

这个跟音频播放有什么关系呢？ 大家都知道，播放器自称很NB的一种方式就是内存播放。 这里要从计算机内存管理讲起：
很久很久以前（大家都很熟悉的段子），计算机没有很多的内存，却有很多的应用，例如只有2G内存，但是却有4个应用，4个应用都有自己
的4G空间。2G内存哪里够用，操作系统就哪硬盘去冒充，那个应用要用，就把硬盘的东西复制到内存里，让应用用这块内存。应用切换，
内存里头的东西就复制到硬盘上，再把其他应用从硬盘里放到同样的内存中。这美其名曰交换(swap）。可以看出来，内存来来去去都是
那2G。交换也不是经常发生的，只有物理内存不足的时候才发生。

这就想银行账户，如果有十个客户，每人存款1千万，那就是1亿。但是银行现金可能只有2千万，谁用给谁，其他都那去放贷了。如果要取
大量现金，那好，请提前预约把。

大家可不想让你的WAV/APE在硬盘和内存中交换吧。 计算机有办法可以让应用锁定内存，禁止交换到硬盘上去。在32位XP时代，AWE刚好可以
做到这样的事情。从4G以外的物理内存中申请到一段，用来存放音频数据，而且这段物理内存是不会被交换到硬盘上的。所以，音频播放器标榜
支持真正的内存播放，支持AWE。

其实，操作系统一般都提供分配虚拟内存，同时锁定物理内存的系统调用。C函数库是没有的，C++的new也是没有这个作用的。Windows SDK中
就有这样的函数。 AWE刚好有这方面的功能，而且能利用4G以上，平时用不到的内存，既节省内存，又能保证锁定，一举两得。

64位操作系统下，AWE已经不需要了（因为64位可以访问4G以上的内存）。这时候制作播放器，就要研究操作系统的系统调用(大家也可以叫做API)，
是如何进行虚拟内存分配和物理内存 映射以及锁定的。只要能完成这样的功能，就可以支持真正的内存播放。

因为锁定内存，可能会让其他应用没有物理内存可用，所以系统要求锁定内存需要有特权，因此大家能看到i众多大神要求在Windows中开启用户的
内存锁定特权。 另外，如果机器物理内存很少，虽然音频数据被锁定，但是其他应用或者音频播放器自身的内存也可能会频繁交换到硬盘，这样
也会影响播放质量。

thinkspace

大部分的程序员只懂语法不懂系统。
#define a 0x100
//a在代码，编译时直接展开
char *b;
//b在堆，b的实际内容所在由程序决定
void foo(DWORD c, d);
//c、d在堆栈或寄存器，视编译器而定
{
  int e = 10;//e在堆栈
}
如果是面向对象语言，例如C++，内存要复杂很多，这里不多讲了
AWE允许直接访问物理内存，理论上可以获得最好的性能，但要注意的是由于NUMA架构的存在，不同CPU访问不同内存节点性能相差有50%之多，平衡不同线程内存访问性能难度大到让人发疯，我觉得大多数人不太可能做得比Windows内存管理器更NB，尝试几次后就放弃了AWE。

amex

吐个槽，极听给个类似简听的简易浏览器和regshell呗

thinkspace

我正在酝酿极听的新Shell，不过最近太忙没空搞了。

kyokyo

Think大，PC上应该没有用NUMA，一般NUMA都是应用在多CPU多总线系统上，一般单CPU多核系统应该不需要NUMA。
不过我说的这个不一定对。

thinkspace

有的，从迅驰开始Intel就使用NUMA架构了，Windows 7/Server 2008 R2开始支持NUMA

yyywww

原帖由 thinkspace 于 2012-5-22 23:05 发表
不如我来问LZ吧
1.内核驱动和应用层时钟精度分别是多少？

2.Windows进程和线程的优先级各划分了多少？它们之间的关系是怎样的？Windows是如何调度它们，性能如何？

3.对于内存访问使用的是SMP还是NUMA？你明白 ...

程序高手

kyokyo

NUMA是在没有共享内存总线的情况下使用。就是指一个CPU无法从总线直接访问到另一个CPU的内存，需要软件实现让另一个CPU帮忙分配管理该内存。NUMA是一套封装这种逻辑的接口，让上层软件可以忽略这种差异。

因为PC上内存总线是共享的，所以应该不需要NUMA。

Intel和AMD早就支持NUMA，这个技术被应用在多CPU的服务器上。也被应用于多服务器群集上。