小编cas*_*tan的帖子

我的文件夹结构是正确的,我可以go install从包文件夹内部和系统中的任何位置运行,然后添加包(文件夹)名称install.

例如,我的工作区如下:

Go\
  bin\
  pkg\
  src\
    name\
      file.go

那么,如果我跑

cd %GOPATH%\src\name
go install

要么

go install name

没有生成错误,我的工作区变为以下内容

Go\
  bin\
  pkg\
    windows_amd64\ <-- new!
      name.a       <-- new!
  src\
    name\
      file.go

正确创建包文件,但不创建bin文件.

我的环境如下:

C:\Users\...>go env
set GOARCH=amd64
set GOBIN=C:\Users\myname\Documents\Go\bin
set GOCHAR=6
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:\Users\myname\Documents\Go
set GORACE=
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++
set CGO_ENABLED=1

为什么会这样？我错过了什么,做错了什么？我希望bin文件与包文件一起创建.

乌尔里希·德雷珀（Ulrich Drepper）在他的出色著作中提出了一个测试基准，我无法完全确定。

他正在谈论缓存和预取。他首先展示了一个测试，其中他正在访问每个16字节的元素数组（一个指针和一个64位整数，每个元素都有一个指向下一个的指针，但实际上这并不重要），并且对于每个元素，他递增它的值加一。

然后，他继续显示另一个测试，其中他正在访问同一数组，但是这次他将每个元素的值与下一个元素的值之和存储。

然后比较了这两个测试的数据，他显示，工作集小于L2D $的总大小（但大于L1D $的总大小），第二个测试的性能要优于第一个测试，他的动机是从下一个元素读取的内容充当“强制预取”，从而提高了性能。

现在，我不明白的是，当我们不仅要预取该行，而且实际上是从该行读取并在之后立即使用该数据时，该读取如何充当预取？该读取停顿不应该像在第一次测试中访问新元素时发生的那样停顿吗？实际上，在我看来，我认为第二个示例与第一个示例非常相似，唯一的区别是我们存储在上一个元素中，而不是最近的一个元素中（并且我们将两个元素相加而不是递增） 。

为了更准确地参考实际文本，在第22页右第三段中讨论了所涉及的测试，其相对图形为下一页的图3.13。

最后，我将在此处报告相关图表，并进行裁剪。第一个测试对应于蓝色的“ Inc”行，第二个测试对应于绿色的“ Addnext0”行。作为参考，红色的“跟随”行不执行写操作，而仅执行顺序读操作。