难民心态

大概是上周的这个时候吧,发微博的时候出现了未曾见的异常.

登录web端看了下,原来炸号了.

也尝试看了下解决方案,无非投诉再身份认证之类的.

想了想,还是放过彼此好了.

毕竟有时候你也不知道哪些能发哪些不能发.

或者说什么时候能发,什么时候不能发.

再者,从审核人员的角度来说,一定的自由裁量权一方面也算主宰了一个人的cyborg生存权.

一方面对它个人来说,也是一种达摩克利斯/负担.

毕竟,所谓的宁错杀不放过.

基层执行的点滴过错,其实可能是未来一个不是它能承受的一个事情的结束点.

就像地铁的安检一样.

尽责各自遵循大概是当前语境下一个较优的解.

毕竟当真出事的时候,前线人员失职追责是在所难免的.

所以,某种程度上来说,躺平是各种层面意义上的一个最优解.

当然,说完全看的看也是说不上的.

毕竟,也算事十几年的账号,差不多就是微博内测第一天开始.

碎碎念也有几万条.

说没有一丝的惆怅感叹,也是不真实的.

想想,上一次类似的事情就是中二时期的QQ空间.

大概也是十几年前大学的时候,某天几十篇千字文的空间说不能访问就不能访问了.

某种程度上来说,两件事都算是一种关键节点的缩影了.

 

至少从个人层面的经历来说是这样的了.

放弃幻想,直面当下.

有些事情就不是自以为的长袖善舞能辗转腾挪回避的了.

就像前面说的.

很多事,并不是一个人的决策活或者说能动性能解决的.

每个人无非只是一个庞大系统里的一环.

当然,这也不是说某个单独的现象.

互联网发展到今天,其实审查基本上是一个必须活着说必然的东西了.

每个平台都有着自己的立场和尺度在.

之所以早期互联网有一度的乌托邦式氛围.

就像最典型的Google的don`t be evil信条.

每个个体,或者说每个存在都有着自己的底线,和恪守标准.

而能不能坚持,更多的是一种自我尺度/掌控的东西.

怎么理解这句话呢.

其实就是所谓的能力越大责任越大.

而相对的,greater power和greater responsibility的同时,并不是保证始终是rightful的.

至少这个从不论是个人,还是受众,还是一般围观群众来说,对错和界限这种事情都是游移不变的.

就像社区管理的悖论一样.

你可能不希望有不友善/有害的信息伤害社区的发展,但同时这种想法带来的界限的consensus的达不成本身就是一种破坏.

所以现在谈的web3.0/去中心化,也不过是某种逃避主义而已.

形式上跟拉黑屏蔽做echo chamber是一个道理.

这个还只是平台向善的一个层面的东西.

而作为平台这种influencer中的influencer,即使是从商业角度来说,利益驱动导致的垄断和刻意的引导也不是什么新知识了.

像现在的反垄断抛去一些因素,本质上就是一种趋向明显的objective执行的结果.

也就是算法层面所谓的converge.

而更广义地来说,社交媒体造成的复杂性和声音的多样性也早就了一种管理上的under scale的问题.

不管明里暗里还是形态上的差异,各国的一致的点其实都在于如何能够保持层级结构的执行效率甚至于说执行可能性.

区别只是手段和实现思路的关注点差异而已.

可能用个稍微远古点的流行此来说,就是失控下的各种自救和self healing尝试.

至于能不能成功回到过去,就是另外一回事了.

再回头谈谈Web本身.

封号活着说更泛化的来说,平台追求系统稳定性的手段.

也就是The matrix里Agent smith和Neo的关系一样.

各自不过是by design的角色和命运而已.

从个人或者说从非平台的角度来说,当前Web的风险点在于digital asset的虚无性.

大白话来说,就是实际上你并不能控制你的虚拟身份的存活性.

平台理论上可以完全抹杀掉所有痕迹.

即使是一国总统也是如是.

越是大和基础的平台应用设施,越是被依赖的应用.

就越是本质上持有者一个人的数字存在意义.

这也是为什么说国民应用和大平台渐渐需要被反垄断和强调数据安全与管控的一个点.

形式上来说,这个就是数字时代的暴力机器/机关.

所以,民用即使不是不行,也是有一个更好层次的前置需求在的.

如果真的要有一个Web 3.0来解决这个问题或者说,出于个人角度的困境的话.

去中心化多多少少只是一种形式上的概念或者说思想.

去中心化并不代表着没有平台的存在.

也自然不能保证平台不会走着如今的权力与边界的管控困境之中.

而且可能更重要的一点是,即使是去中心化这个概念,隐含的还是没有脱离掉数字身份/digital identity这个概念的存在.

无论实现形式是如何,一个ID也总是有办法是不可达到/reachable的.

所以回过头来看.

会发觉,这里其实还是Web 2.0.

还是social network的思维.

还是一个以可标识的人或者身份的思路.

无论目的是交友聊天还是其他.

需要的都是唯一标识某个活跃实体.

也就自然的不能回避掉如何鉴定这个实体的问题.

以及如何拒绝resolve这个实体的问题.

所以当想逃离web现状的时候,真正需要的是什么.

如果说无论Web 1.0还是Web 2.0以及可能的Web X.0都一致的原教旨/初始理念的话.

就像两个时代都显著的Google曾经的愿景一样,让一切变得可检索.

换句话说,无论哪个时代.

Web给人的实质需求其实都是信息的流动和获取.

而在经历了凡此种种之后,回头看.

信息的获取和digest需要有标识这种东西么?

或许需要.

因为你可能需要authority或者credit.

或者只是为了减少fact check的负担等等.

但是仔细想想,这是必须的么.

也并不是.

每个人应该有每个人自己的判断方式.

可以是Web 1.0的,也可是Web 2.0的.

也可以是其他的.

比如untitled,anonymous等等.

重要的还是自己对自己负责.

所以可能来说,跟准确的来说是选择的权力.

或者说不依附特定形式的能力.

这么想的话,可能更合适Web 3.0的概念其实是一个更简单的概念.

难民心态.

关于SQL的几件事

前两天内部confluence上看到有人在做一个go sql sharding的东西.

瞄了眼讨论大致思路是打算在客户端做.

对于这个方案不置可否.

一来毕竟谈了也没什么意义.

二来各人高兴就好.

主要是看到个举例pushdown优化的一个例子插了几句.

大致是类似一个select * from table_a where filed_a in (select * from table_b where field_b = x)这种嵌套的情况.

看讨论大致是觉得不太可能push down,只能做client side的gather + secondary filter.

但实际上是有可能的是有可能的.

因为本质上从logical plan的角度来说,就是一个各自带filter的两级scan.

类似于

scan table_a

  filter op in field_a

    shuffle/exchange

      gather 

        scan table_b

          filter op = filed_b x

之类的形态.

从各个shard filter出来之后,再在这个结果集做exchange/shuffle回对应的shard再做二次filter.

甚至是如果用client side方案的话,直接在client端做二次filter,直接gather回来做引擎执行.

而理论上是存在可能改写为

scan

  gather

    scan table_a

      filter op in filed_a

        scan table_b

          filter op = field_b x

这种形式.

即把整个过程pushdown到对应的shard直接执行再gather.

这个问题的麻烦点在于不是所有的filter都可以pushdown.

只有符合某些特性的才可以.

以这个例子来说,如果要允许push down的话,需要满足:

则对于任意可能的值m,n.

如果shard_of_a(m) == shard_of_a(n).

那么shard_of_b(m) == shard_of_b(n).

即same_shard_of_a(m,n) -> same_shard_of_b(m,n).

如果m n在table_a中是同一个shard,那么table_b里也是同一个shard.

这样的话,逻辑上应该就是类似于并行存在的独立库表,不存在overlay的情况.

自然也就不怕直接pushdown了.

所以某种程度上来说,写planer/optimizer之类的,也挺有意思的.

虽然从商业角度来说,没什么价值.

或者说很难看到直接的利益冲突.

本质上来说都是compiler,只不过是不同form的transform如何选择的问题.

前段时间因为某些原因需要写个PromQL/MetricQL到Cliekhouse SQL的transpiler.

看了一些实现都是相对比较粗暴的只是做了scan和filter一层,剩下的聚合都是在拉取结果集过来再计算的.

而这个恰恰是需要解决的问题的一个因素.

原本的问题是某个metric的label是个高cardinality的东西.

导致的一个问题是,Prometheus本身的execution engine也是简单scan加filter,然后全量汇聚到内存当中算的.

所以在本身数据比较大的情况下,基本上要么算不出来要么直接内存不足整个进程oom/pod被evict了.

更不用说一个附带的数量多带来的存储空间也比较大的问题.

后来尝试用VictoriaMetric.

它相较于Prometheus在这个场景的优势在于,它的execution engine是增量的,或者说是streaming风格的.

即不像Prometheus需要把整个数据集load进内存之后再计算,而是一边读取一边计算.

并且采用了类似sharding/portioning的方式,可以多个goroutine并行地计算不同存储区域.

所以从计算效率上来说,会比前者有优势.

但是它的问题同样一个是存储.

另外一个也可以说是存储.

它的一个存储优化是对每个不同label value的time serial做个了id,这样减少了label存储的开销.

但因为这样需要一个id到lable到结构.

这样对于这个high cardinality的场景来说,id膨胀会非常快.

而每个time serial又非常稀疏,所以对索引等会有性能上的压力.

再一个就是本身设计上有对id生成速率的一些保护机制.

虽然是一个可配置参数,但是理论上总是有可能被拒绝的.

而且关键的问题是,即使有着前述的一些优势,它的计算时效性在几分钟级别.

是不太实际/可用的.

另外一个考虑过的是timescaledb.

它的优势是本身支持PronQL/MetricQL,所以如果可用的话,差不多也是开箱即用.

问题主要在于可能作为商业开源产品多少会有些小心思.

比如它的chunk机制,尤其关于ttl/retire和size等相关的配置.

本身的一些调度比如compact/compress等是利用了postgresql的job scheduler做的.

存储是自己写的一个类似于前两者的针对time serial优化的一些压缩结构.

这个问题在于比如你要设置限定每个chunk/block大小的话,并不是document上写某个参数就能实现的.

去翻它对应实现的plsql的话会发现依赖于其他一些参数的设定.

有些还是从名字上根本关联/完全想不到有联系的参数.

而这个又基本上属于一个必要的tuning部分.

因为它稍微上层一点的实现其实是把某个时间段的数据作为一个独立表来处理的.

所以如果设置的大小太大或者关联的触发条件参数使得触发得很晚或者根本触发不了的话,会导致表膨胀到设计/预期外的大小从而影响查询性能.

更进一步的,它的索引机制的默认参数里里也有些看着是默认开的优化参数.

但是实际看执行计划会发现触发了不必要的扫描.

比如某些语句指定了某个时间范围,并且chunk/table已经按照预期的确定切割正确了,但是实际上还是会触发范围外的扫描.

但是如果把某些优化参数关掉,再看执行计划会发现符合预期了.

当然,往好处想想,这可能是planer/optimizer的bug.

另外一个维度的问题是timescaledb做ingestion的组件的质量问题.

中间有触发db连接失效,但是ingest没有重试直接退出导致chan block整个stuck的问题.

虽然简单提了pr然后隔几天他们自己看了又用另一方式fix了.

还有一个就是因为自己使用不是直接利用promscale那个组件,而是作为库引入了进来.

因为既然不用prometheus了,所以直接自己写scarp直接入库,整合为一个进程.

然后再剥离ingest的时候发现了很多奇怪和不必要使用方式以及接口调用风格.

最后放弃这个方案的原因大致是有点心累了.

在数据量到一定程度后,计算时间也分钟级以上了.

而且查询到时间范围并没有变化.

所以最后转向了clickhouse.

clickhouse作为最后方案的一个原因是没有一个类似timescale的pushdown引擎.

所以如果要用的话需要自己实现PromQL/MetricQL.

至少是场景所用到的语句和对应函数的支持.

AST部分是用的MetricQL的parser.

一方面是因为MetricQL语法上更松散一些,没有强要求区别instant vector和range vector.

另一方面是Prometheus并不太容易作为一个三方库引入进来,这个也是有相关issue明确了的.

所以剩下的就是到SQL到transpiler.

从结构上来说,MetricQL可以很直接的映射成一个嵌套的SQL.

语法上就是metric source scan + filter + function op -> metric source的递归过程.

而且label selector基本就直接解决了最下层的where和row column是什么了.

剩下的就是具体的函数的sql化问题.

比如sum/max等简单aggregate 函数的group 字段inference.

还有topk之类的window函数的应用.

对应到prometheus的http api的话,就有另外一些问题.

上面的只是针对instant value的查询生成.

当然是一般场景会有某个time range的time serial和time range维度的aggregate.

后者就是比如sum_over_time等函数的实现.

因为语法上限定了x_over_time是一个range vector,所以实际上实现也还好.

就是普通aggregate函数再加个time维度的聚合而已.

主要是range查询.

range查询的问题是形式上它是instant查询的不同时间点集合.

所以一个intuition就是直接生成各个时间点,然后再生成各个时间点的sql union起来.

这个从工程上来说是最直接的.

但实际效果却不是很理想.

虽然clickhouse的设计使得即使是底层复杂sql构成的instant查询,比如带metrci[5m]这种带短时lookback的也能在至多秒级出结果,基本无关总数据量多少.

这样一个直觉的话,最多执行时间会是差不多线性的.

但实际的结果却是出人意料地在AST->Plan的阶段.

像一个小时左右的range查询,step是15秒的话也是,240个instant的union.

一些比较复杂的instant sql本身嵌套的层次就比较多.

给每个嵌套生成一个序列table id的话,最后可能上千甚至几千的table.

sql本身的大小也可能到mb级别.

ClickHouse在处理这种大小的sql的编译优化的时候,就不太行了.

时间起码也是几分钟以上.

这在比如grafana端也早就超时了.

平心而论的话,这个应该多数planer都应付不太过来.

毕竟搜索空间膨胀太快.

另外一个思路是类似于x_over_time的聚合.

根据时间生成一个时间范围相关的pseudo group,当作一个普通字段参与到group by当中.

再在最外层remove替换为时间.

这个方式没再去实现.

可能遇到的问题一个是计算出来的时间跟实际存储数据的时间有一定的不一致情况.

这个倒不是关键问题.

另一个主要的是需要对对应的instant函数的处理实现一套range的版本.

当然,也可以以range的版本,用align之后的pseudo时间去生成instant的版本方式实现.

没有继续往下做的原因一个是有其他新的坑要填.

一个也是实际上原始的cardinality问题只需要instant版本的.

没什么太大的必要去完善支持用不到的部分.

至少是暂时用不到的部分.

这里另外一个题外话就是union的那个问题.

理论上来说,如果clickhouse支持类似presto/trino等直接执行plan的方式等话,可能就没解析的问题了.

毕竟归根到底,sql是plan表达能力的一个子集.

如果用plan的方式,可能有些实现就没那么麻烦.

而且这个union其实也算特定的一个场景.

由几乎同态的自查询构成.

想一下的话,不过也就是scan fitter calculate的时候分到不同的group罢了.

可以针对性地下推,避免膨胀的optimizer搜索.

    

一些数据

拉统计局的发电数据看了下.

2021年8月全国7385.5亿千瓦时.

用过去36个月的数据肉眼forecast一下的话,大致是会比去年同期增加500亿千瓦时的样子.

而按照往年的话8月大致会是一个峰值,9-10两个月份会有一个周期性回落,12月的时候大致会跟一年的峰值相近.

所以如果安500亿千瓦时算的话,应该会是在7800亿千瓦时附近的.

另外一组数据是各类发电的构成.

核能风力大概各自在5%左右.

光伏太阳能虽然今年单比是成倍的增长,但也只占2%多一些.

大部分还是70%火力和18%水力发电.

所以总的来说,电力的构成还是以火力发电为主.

然后同样的看原煤产量数据.

2021年8月的产量是33524万吨.

看数据的话,这两年是某种程度上负增长的.

但大致还是在3w万吨的水平上.

那么一个问题就是,如果按500亿千瓦时的同期电力增幅需求的话,对应的需要多少煤呢?

在考虑全部由火力发电提供的前提下.

翻内蒙华电的2020年度报告.

年发电量是330.85亿千瓦时.

同期发电成本是120亿.

拆分的燃料成本70亿.

另外一个就是主营业务另外一项的煤炭收入.

实现营收平均单价是293.14元每吨.

假设其中的燃料成本就是煤炭成本的话,折算下大致是每亿千瓦时需要7.2万吨煤.

500亿千瓦时的话,就是需要3600万吨.

也即是大致占原煤产量的10%左右.

同样的,如果用这个数据折算8月发电量中的煤炭消耗的话.

对应的就是3.7w万吨左右的原煤,大于当期原煤产量的3.3w万吨.

类似的,如果按3.3w万吨计算发电量的话,则大致会在6651亿千瓦时的水平.

这个大致等于2019年数据的峰值.

考虑如果省份按照火电自给率来计算的话.

缺口比较大的省份是 江苏福建江西湖北广西四川.

如果把缺失数据认为是本身不产煤考虑的话,江苏浙江福建湖北广东四川云南.

两者做个交补,比较瞩目的省份就是浙江和广东了.

再一些比较不是那么权威的数据.

2021年8月进口煤炭2805.2万吨,同比增长35.76%.

换算一下就是大致增长1k万吨.

对比500w预期吨话,倒也是有空间.

另一份也是不那么权威的数据是炼焦煤进口渠道数据.

2019年全年主要依靠蒙古和澳大利亚进口,分别占45%(3377万吨)和41%(3094万吨).

2020前10月分别是1972万吨和3512万吨.

这么看的话,很多事情就比较微妙了.

从电力构成上来说,清洁能源尤其光伏是还有比较长一段路要走的.

即使不是不切实际.

而鼓励水电的发展,某种程度上来说,可以算是一种中短期的权宜之计.

毕竟相比于光伏的效能和对应的电力构成规模来说,水电本身的规模和效能还是相对实际一些的.

但考虑到实际的投入周期和生态影响.

尤其如果考虑气候变化因素的话,某种程度上来说不确定因素可能并不比光伏少.

火力发电的话,至少短期内比例上是不太会有什么可见变化的.

也就是说在原材料需求上压力还是比较迫切的.

加上如果考虑预期和周边的产业诸如新能源汽车等因素,电力需求和资源产出本身以及其他政策目标因素的综合影响.

倒像是个越来越无解的局面.

毕竟目前就属于勉强可堪的局面.

一些计算

前段时间有个段子吧.

大概就是所有人努力的话,只会物价上涨.

简单的描述就是流通的过程都加一个固定百分比,剩下的就是类似现值计算的逻辑.

这里有个隐含假设就是这饿百分比是instantaneously propagate的.

或者v_{t+1} = v_{t}*(1*p) 的作用是即时超距的.

比较现实一点的模型是这种传导是有一定延迟和滞后的.

就像PPI和CPI一样.

因为供应链存在一定的生产以及更重要的账期时间.

这也是为什么有时候三角债是个难解的囚徒困境问题一样.

具体到个体的话,可能可以换一套描述.

比如何不食肉糜的模型.

给定个人的收入income i和对应的支出household,以及一定的再投资investment.

有income_{t+1}  = income_{t} - household_{t} - investment_{t} +  investment_{t}*k

即下期的收入相关与当期的收入减去当期生活/生存开支,以及当期投资项目.

引入investment的一个目的是描述某种程度的收入成长性量化方式.

可以是狭义的资产方面的投资,也可以是某种非物质性投入的折现.

非物质折现的合理性在于,它是基于当期的一些各种购买开销形成的.

比如培训和再搅匀等.

当个人的发展跟社会财富的增长幅度相匹配的时候.

比如简单的收入增长跟GDP增幅保持一致的情况.

那么,应该有income_{t+1} = income_{t} * (1+p)

->

income_{t} *p =  (k-1)*investment_{t} - household_{t}

因为househould水平是跟整体社会水平增长相关的.

即开头的household_{t+1} = (1+p)* household_{t}

再结合递推income_{t+1} *p =  (k-1)*investment_{t+1} - household_{t+1}

->

income_{t+1} *p =  (k-1)*investment_{t+1} - (1+p)* household_{t}

->

income_{t} * (1+p)*p = (k-1)*investment_{t+1} -  (1+p) * household_{t}

->

investment_{t+1}  =  (1+p)*(income_{t} *p + household_{t}) / (k-1)

当存在持续投入模式的情况下,均衡条件要求k>1,即roi应该是正的.

但是,同样地根据均衡条件,如果ROI为负的话,investment_{t+1}也为负的话.

形式上也是能维持个人和社会步调一致的.

此时有

income_{t+1}  = income_{t} - household_{t} + (k-1)*investment_{t}

->

income_{t+1}  = income_{t} - household_{t} - cost_{t}

即当一般认为的增值增长方式实际上是一个纯消费的情况,也是可以成立的.

recall一下,这个支撑的结论是要求个人收入水平跟社会总体平均水平是等同的.

即隐式地有p等同这个约束.

随之而来的就有几种模式.

一个是对于ROI为负的人群来说, investment也是负的.

或者更一般地

由income_{t+1}  = income_{t} - household_{t} - cost_{t},且要求income_{t+1} > income_{t}的话.

让数值都>0修正符号之后就形式上等价于

income_{t+1}  = income_{t} - household_{t} + funding _{t}

->

funding _{t} >  household_{t}

补助程度应该大于生存开销.

类似的,对于正ROI人群来说需要有

(k-1)*investment_{t} > household_{t} 

这可能有些meaning less.

重新考虑investment_{t+1}  =  (1+p)*(income_{t} *p + household_{t}) / (k-1)

随着增长率p的衰减,为保持平衡investment也将逐渐趋向于0.

即趋向income_{t+1}  = income_{t} - household_{t}的模式.

从通胀的角度来说,就是实际上flatten了.

这里的另外一个问题就是前面提到的.

一个隐含的假设是p是瞬时处处一致的.

但是当作一个动态宏观系统考察的话,是存在类似于弛豫时间的一个概念的.

热力学考察这个问题的时候是通过通过过程无关的最终状态模型来描述的.

因为理论上或者说目的描述上是需要converge到某个特定状态的.

在尝试用微观语义去解释的时候,引入的是系综/ensemble的概念.

即把一个大的动态系统划分为相对有限的isomorphic的子系统来解决的.

而通过这种量化方式可以用相对经典的力学框架去描述/解释状态变迁的驱动过程.

整个系统的状态converge就由这些小的构成部分的操纵来完成.

有时候你也很难说这种宏大叙事的理论框架是错的.

因为它确实能解释相当程度,并且具有一定的先验性质.

当从微观层面来看的话,又过于mystery/unstable.

以致于需要用概率去描述一些往复和纳入极端情况.

路径无关

之前翻资本论有个比较有趣的衍生点.

即交易是非对称non-transitive的.

也就是所谓的使用价值和交换价值的区别.

一物之于一个人的utility是不一定等价的,所以交换价值是不定的.

从形式上来说,如果给定A=B.

那么A*C ?= B*C 是不一定成立的.

也就是说任意两个商品的交换价值是不可比或者说arbitrary的.

即relative/相对价值的概念.

而从以上形式来说,这个概念脱离其定义时刻的前后都是无意义的.

因为相对/交换价值具有任意性.

那么从理论上来说,所有交易的标价/交易价值都是可以有任意值的.

但实际上来说,真实世界里某一个商品通常具有相对确定的普适价值.

资本论给出的解释是基于劳动力/labor的ensemble.

商品的产出由一系列基准的劳动力投入来衡量.

而劳动力这一个概念又是由所谓的无差别来标准化的.

因为劳动力系统的计算中,劳动力本身被视为一种常数,所以它的标量是相关于时间的.

如果在现实中纯粹应用这个模型的话,会导致一个无视/反效率的存在.

一个例子就是机器生产与人力投入的例子.

两者的效率差导致人力投入的时间更多,但实际价值更低.

那么什么是无差别呢?

它是一种全行业的平均劳动投入.

这是一个稍微有点递归的定义.

注意,无差别是平均的话,那么什么是平均本身呢.

比如当有新技术投入的时候,这个平均值是如何变化的呢?

或者出现减产或者局部地区差异的时候,这个平均又是如何定义的呢?

热力学系统里又个类似的概念.

什么是温度.

温度是一个描述某个特定系统在热平衡时的整体状态的一个度量.

即不管平衡时内部粒子/micro system如何变化,从宏观上来说,它是一个平衡的/平均的.

用这个来解释的话,交易就是一个热力学系统的平衡过程.

或者说是其微观细节.

而价格或者说市场的概念是一种统计意义上的平均值/宏观量.

基于宏观角度的模型解决的事宏观层面的状态变迁依据和计算.

比如一种货币政策目标或者市场利率目标则类似于一个热力学系统的状态计算.

它的实现路径通常来说,并不是理论设计的一部分.

因为它的数学描述的构建就是依赖于这种势函数/路径无关性.

将压强体积等作为变量融入到系统模型到目的不过是为了便于通过这种实验易控制变量来达到状态变迁的predictable/manageable.

类似的就是宏观经济中的各个观测指标.

那么微观意义呢?

它具有微观角度的实用性/可解释性么?

热力学假设用经典力学推演微观细节的时候有个gibbs paradox.

大致就是从微观粒子角度套用热力学结论的时候,两个相同状态的系统混合时演算出现了熵不为零的情况.

熵是热力学系统描述能态变化积分路径无关的一个产物.

类似于描述一个系统不同状态的差值的函数.

即如果两个系统状态系统,那么它们的叠加状态应该也是相同的.

因为没有实际的状态变化.

但是计算的结果却是非零.

这里给出的一个补丁是计算微观状态的时候除以一个1/N!.

给出的intuition解释是N!作为N粒子系统的所有组合状态的可能数量.

但直觉上应该是为了数学上的便利/优雅性.

因为修补过程利用的斯特林公式,将lnN!近似展开得到的熵零结果.

但至少可以认为这个跟N组合相关的intuition有一定的合理性.

即宏观和微观存在一个状态空间大小N!的近似关系.

也就是基本的平均概念.

一个宏观系统要用路径无关的状态函数描述的话,那么它对应的微观表现是具体粒子状态的平均化函数.

关于Go的一些相对优势

最近用Go重写了之前基于Envoy的一个东西.

性能从原来的32 CPU 20w+ 18ms latency变成40 CPU 40w+ 10ms.

这个结果初看没什么可比性.
但是拆分起来还是可以谈一谈的.

Envoy的版本大概就是到32 CPU的时候就上不去了.
也就是说之后的性能并不随着CPU资源的增加而scale.

这个之前略微谈过.

大致模型就是:
Time = sys_cost + read_fd*(read_bytes*cost_per_read_byte) + write_fd*(write_bytes*cost_per_write_byte).
sys_cost是固有的eventloop的开销.

后两项是抽象的读写每字节对应的动态抽象成本.

说是抽象的原因是考虑到实际的业务场景每请求的处理开销/代价是不太一样的.
所以规约到一个字节角度的动态参数化类函数描述.

然后假设K个eventloop之后的一部分请求能够得到响应.

也就是会有
latency = K*Time = K*( sys_cost + read_fd*(read_bytes*cost_per_read_byte) + write_fd*(write_bytes*cost_per_write_byte)) / N
->
a*sys_cost + b*N*cost_per_read_byte +c*N*cost_per_write_byte

因为cost都是某种特定场景下的常数.
所以最后可以规约为
latency = const_cost + N*cost_per_hybrid_byte

所以当小于32 CPU的时候,随着CPU增加,每个CPU需要处理的N变小,所以会随着scaleup.

而当>32 CPU的时候,后一项已经significantly小于,const_cost了,所以继续增加并不能有什么改善.

所以这是它的一个缺陷或者说应用场景考虑.

而Go由于runtime的关系,模型会有一些比较不一样的地方.

因为它的IO和channel/mutex等操作会触发groutine等调度.

从逻辑上保证P是burning cpu in the right way.

也就是说,当有类似操作的时候,go会让专门的线程(netpoller/sysmon等)去做blocking的工作,而让M继续执行runtime user level的meaningful code.

所以如果不考虑IO等blocking call的capacity的话.

它的latency大致就是直接的

latency = k*CPU/(N*c)

k为一个CPU提供的请求处理能力常数.

N为请求数,c为每请求需要的cpu资源数

所以简化下就是一个简单的

latency=a*CPU/N

的关系.

性能将随着CPU数的增加而增加.

这个跟benchmark的结果的部分结果也是可解释的.

在CPU/GOMAXPROCSS<40的时候,CPU资源的增加和性能的提升是准线性/sub-linear的.

但是继续增加的话,并不能再进一步地提高性能,甚至从抖动的角度来说,还有一定的degrade.

所以,这里就必须考虑把IO等的调度/capacity考虑进去了.

revise一下就是:

latency = (k*CPU)/(N*c-f*blocking)

f代表一个mean的平均调度周期内的从blocking->ready的G的数量.

以及bloking为对应的执行后续的开销.

intuitive的理解就是,divider是原本能调度的非blocking的user level的G减去必须调度的blocking ready的G.

这样的话,回头解释就是.

当CPU<40的时候,本质上是CPU bounded的,也就是其实并不能完全游刃有余地处理全部请求.

因此能产生的ready的数量是随着CPU数当增加而增加的.

所以是一个sub-linear的关系.

而当大于40的时候,基本上可以解释为是CPU已经不是瓶颈了,而主要是runtine处理IO/调度的能力.

所以这时候的f会相对地大量增加.

如果此时f*blocking是dominated的话,那么CPU的增加就会差不多近线形地被f的增加所抵消.

这样的话,就可以解释为什么继续增加CPU资源的时候,甚至可能会有degrade的情况.

这时候可能可以考虑的就是要么减少G的数量,要么减少syscall等blocking call的数量.

本质上,后者也是减少G的数量.

这个在之前一些版本的实验/探索里大致也是有部分实践可以说明的.

早期的一个实现采用了比较多的channel.

比如读写分开,处理数据分开.处理数据的过程也有channel.

这样的实现是会产生多几个数量级的G的.

所以后来的做法就是缩减了一些到公共channel,以及合并了一些原本独立的IO channel/goroutine.

这样的话,就减少了f和调度器的开销.

另外一个尝试就是把部分的写IO换成buffer io.

也就是合并syscall等部分.

但是现有的API做网络buffer io并不是很友好.

因为你需要手动地flush保证一定的latency的keep system running.

不然可能因为没有flush导致上下游都在等对方的IO.

所以要么就是加timer去flush.

要那么就是嵌套的select,外层non- blocking,然后default分支里再加blocking的select.

无论是哪种方式,都需要额外引入一个channel和goroutine.

这样的话就变成了syscall和goroutine/channel对于scheduler来说孰轻孰重的情况了.

而如果选择后者的话,代码复杂度会上升一些.

加上实际测试的效果似乎并不理想,所以最后这部分还是改为了直接syscall的方式.

当然,这里还有另外一个方向就是用mutex.

也就是write的时候用lock而不是channel.

这样的话,就可以在不用buffer io的前提下,speculate地合并一些写.

加上mutex本身也会触发调度,形式上和channel的效果类似.

但是它的问题在于不scale.

在限制CPU为1或者相对低的情况下,mutex通常能走fastpath.

也就是简单cas就能成功,不会触发调度,所以表现是相当地promising.

但是当CPU数量上去之后,资源抢占变得比较激烈,大多数时候都是slowpath,结果就不是很理想了.

所以这里一个思路就是对于mutex和channel的选择.

在抢占相对没那么严重的情况下,mutex似乎是比chan更好的一个选择.

回到IO的问题上.

这里的本质是Go目前没有一个比较好的感知IO ready情况的一个API.

理想状况下,需要是一个类似

func Write([]byte) <-chan IOResult

的API,

这样的话就能比较方便地做

for{

   ioCh:=w.Write(buf)

   select{

     case r<-ioCh:

       //if r.Err() != nil

     case newBuf <- bufChan:

      // gather more

      //. buf = append(buf,newBuf...)

   }

}

之类的.进一步减少groutine和syscall.

当然,初看起来这个自己实现也就是make一个channel然后go一下的问题.

ioCh := make(...)

go func(){

  defer close(ioCh) 

  size,err:=w.write()...

  //ioChan<- &{size,err}

}()

这里的问题一个是构造g的开销.

一个是不可避免地还是增加了一个g.

尽管看目前的runtime实现对g结构是有个resue/pooling的.

但是,多多少少还是涉及一些初始化的问题/开销.

而且更重要的是形式上来说,相比一个continue polling的goroutine并没有什么优势.

反而可能产生了更多的问题.

如果从runtime层面去做的话,可能就是在netpoll wait/pollDesc wait的相关路径更改/增加新的ready的回调方式了.

比如当前是的路径是挂起当前的g.

而按照上面API设计的话,可能就是netpollready的时候加个special case.

看是否有对应的g或者新的代表return chan的struct field,然后fake一个g或者更直接地,通过 channel kick start对端的g就是了.

当然,实际会更复杂一些.

比如加入之后还需要考虑pollDesc里的各个timer的处理等.

从萨尔瓦多谈起

前段时间有个关于BTC的消息,就是萨尔瓦多将其作为一个官方货币/法币.

细节上来说,是发行了一个挂钩BTC的另外一个虚拟货币,作为一个流通使用的货币.

这个有趣的点在于提供了一个以前没想过的层次或者说侧面.

也就是像对于这类没有什么经济支柱产业点小国来说,BTC的可能是某种程度上的积极意义所在.

一般来说,一个国家如果没有什么完整的工商业体系,或者说没有什么支柱经济产业的话.

那么大多数时候的商品是需要通过国与国之间的跨国商业活动实现的.

而不同国别之间就存在了法币不同的情况.

这样的话,就自然而然需要有一种互通的汇率存在.

理论上来说,这个是两国之间协商互认的一个事情. 

以什么比率是可以私自决定的.

因为交易只设计两方.

但实际上这种理想情况是不太可能存在的.

一般都是多国贸易.

那么这样带来的一个问题就是种类繁多带来的系统复杂性.

所以,一般来说,会选择一个统一的可信货币作为本国汇率的锚点.

也就是一般所说的挂钩美元.

当然,也可以直接将美元作为自己的法币.

从大的方向上来说,有区别,但不大.

以锚定方式的话,至少从形式上保留了一定的货币独立性.

对于美元的变化相对来说,有一个缓冲区/时间因素.

而直接以美元作为法币的话,自然就没什么可以操作的了.

挂钩美元的话,自然理论上也可以自由定价.

比如一些汇率干涉和管制手段,单方面的维持某个牌价.

这个的话,也自然对应的会有市场驱动下的黑市牌价之类的.

作为一种群体性的价格纠正/共识机制.

所以除非是采用严格的汇率管制手段,限制/管制汇率交易,不然定价和平价总会回归到市场行为.

也就是说,当采用锚定美元的方式,并且不做或者做不到外汇管制的话,那么汇率价格的形成就会落到国际市场上.

即相对直接的买入卖出持有抛售行为上,从而形成一个公信价格/汇率.

因此为了保证相对稳定和可信的对美元汇率,一国的就需要针对美元和自身货币在市场上做相应的维持动作.

而一般他国对弱势国家的货币持有意愿是不高的.

一个是没有需求.

另外一个是风险敞口大.

当美元贬值的时候,相对来说就是本币升值.

而为了维持固定汇率,一国就需要做相应的贬值动作.

理论上来说,作为市场上几乎唯一的买方,唯一能做的就是抛售相应的美元资产,买入自身货币.

以维持对应的比率关系.

而这样做的影响就是减少了美元储备.

类似的,当美元升值的时候,就需要追加美元储备.

而追加的方式并不能通过本币的外汇市场操作达到,而需要通过以其他可能的方式增加对应的美元资产.

不然的话,固定汇率就失去了平准依据.

所以对于小国来说,需要有相当大美元资产储备和缓冲来保证国内经济的稳定性.

使得不会因为美元的波动而影响日常经济.

但小国之所以是小国就是因为没有太强的经济优势和创汇能力.

加上如果不做管制的话,国家财政是不太可能有大量甚至足够的美元储备抵御波动的.

尤其如果一国比较动荡,自由兑换的美元可能就很难通过循环回流到国库,从而形式和结果上的,进一步削减美元储备,降低本币信用,形成一个负反馈.

那么回到开头的萨尔瓦多的做法.

形式上来说,它是引入了另外一个资产标的BTC,作为锚定的目标.

并且理论上允许虚拟法币和BTC的兑换.

也就是间接的,维护了虚拟法币和美元等其他货币的一个一定汇率.

单本质上来说,因为手续上需要经过虚拟法币到BTC到一个兑换过程,所以实际上可以认为是某种形式的汇率管制.

所划的防火墙不是拒绝交易,而是作为代持.

只要虚拟法币所代表的BTC不实际地流出本国,对于本国来说,就是一定程度的dark pool操作.

并不影响BTC的对应储备.

这种方式跟美元的方式区别在于,最终用户得到的是BTC.

本质上不是一个可以快速流通变现的东西.

而当得到的是纸钞美元的话,一般情况下是可以快速流通的.

所以这是BTC作为外汇管制手段的一方面.

另一方面,因为限制了美元的持有,所以在黑市方面的价格形成压力和影响会相对地没那么大.

也就是在汇率价格形成机制上,对抗因素减少.

当传统情况下需要对锚定的美元价格动作的时候,由于缺少对手盘,所以少了出于套利的交易目的行为.

这样的话就允许不那么及时甚至不维护对应的汇率关系.

因为即使本币在市场上丧失信用,但并不影响一国以美元储备进行的商贸活动.

而由于国内锚定的是BTC代理的美元价格,所以也不会因为原有的本币波动造成影响.

当然,这里假定的是BTC本身的波动可以忽略.

这样的话,形式上就有点类似于是直接使用美元作为本国法币使用了.

因为无论对内对外来说,都直接间接的是以美元等值计价的.

唯一的不同在于,BTC的代理管制所构造的dark pool,使得一国可以在以类美元法币的形态,采取一定程度上的自主货币政策.

即通过调整dark pool的杠杆率来实现相对弹性的国内价格调整.

这点是在原有框架内,不做外汇管制的经济弱国里做不到的.

而如果都采用这种方式的话,可能确实对经济体系是一个不小的冲击.

因为国际贸易回归到ledger状态. 

单一或者多元强势货币的波动就可能没那么直接的影响.

而且这种体系天然地把国内经济活动和国际间经济活动隔离的.

原则上,国内到国际都是可追溯的.

以及因为本质上是存在防火墙代理隔离的两套系统,所以相对来说可以是彼此独立的经济体形态.

也就是说,可以不存在关联影响.

那么,这说明BTC确实有一定积极意义么?

也不是.

抛开本身的波动性和负面因素.

这套系统需要的不过是一个国际国内的代币缓冲隔离带.

所以它可以是任何形式的数字货币.

甚至是不是货币形态都不重要.

因为本质是个制度性要求.

Eventloop及其他

最近一段时间写Envoy有些比较纠结的地方.

一个主要是eventloop模型,叠加C++本身的一些特性或者说问题.

写Java写Go的时候习惯于executor.submit或者go something.

毕竟closure带上上下文,交给调度器处理不在context的逻辑,一来心智上没什么负担随借随还.

二来毕竟多核,指不定并不实际影响latency,或者影响甚微.

而eventloop模型负担就比较重了.

因为本质上是一个topdown的设计,需要手工介入分时的概念,去衡量那些应该优先调度/调整顺序.

一个例子是写redis的proxy,外加一些协议层面的统计信息.

在实际debug情况下的测试结果,把统计关闭和打开大致会有几倍的性能差距.

原因也比较tuition.

相较于比较简单的协议解析来说,metric的各种lookup和string的allocation等反而开销更大.

所以一个直觉的处理方式就是异步化处理.

但是就eventloop模型来说,单线程其实没有所谓异步化处理.

最多也不过是对work queue的一些顺序调整.

当然,理论上来dealy到io事件之后处理是有可能利用一些本来就会花在poll上的时间的.

但也只是理论上.

实际上如果说真地在跑或者有了一定负载的话,大约也是io busy loop的.

所以delay到哪里其实代价都差不多.

另外一点就是envoy本身在libevent2上封装之后暴露出来的delay api要么是不停地塞到work queue的head,导致诸如delay([](){ doSomething(); delay(other)})这样的调用会直接递归出不来.

要么是timer base的delay方式粒度最小是1ms.

这多多少少不是让人很舒服.

因为是一个确定性的latency,而且不一定能容忍.

所以eventloop叠加callback或者coroutine之类的实现,本质上还是一个topdown的思维模式.

能做的最多就是次序上的调整,和基于此的一些speculative的开源节流方式.

而如果在这个思维模式下,加上C++的话又会有语言层面的一些纠结点.

既然已经在抠运行时调度的一些开销问题了,那么应对这些动作本身的开销也会多多少少考虑一些.

像比如要做delay的话,就必然涉及到把context带过去的问题.

直接如上的用lambda传递的话,在其他GC语言里可能就没那么多考虑.

毕竟即使考虑能做的也不多.

像Go可能还能做一些逃逸分析方面的考量,利用stack.

而Java类的基本就不用花这些心思了.

C++ lambda/std::function等就基本意味着要做value pass,触发copy.

而且一般来说就是memory allocation了.

当然理论上来说,可以写个stack allocator.

但对应的要做或者改造的地方就比较多了.

比如stack是哪个stack,如何保证这个stack是safe/accessible的.

一个简单的思路就是类似go的g0或者grouting stack.

用eventloop的frame层面的stack.

然后不够了fallabck会std allocator之类的.

但至少在envoy的场景这个是不太能做的.

毕竟寄宿在一层框架之上.

另外一个思路是可以在filter或者filter factory层面preallocate.

也就是在所属框架必然有的orignal/context object本身开辟一部分.

实际上也还是把自定义filter等组件作为一个goroutine stack来做allocation了而已.

这里带来的另外一个问题是这个allocation的lifecycle问题.

what if delay的operation执行的时候,这个hosted object free了?

不过在Envoy层面来说,这个问题不算大.

一来是从设计上来说,用了比较多的smart pointer,尤其比较严格的uniq_ptr.

object ownership关联关系方面的负担没那么重.

二是本身暴露的借口大多也有利用object自身的一个smart pointer做liveness check的.

在callback的时候会检查一下,所以也不用太担心.

但即使这样的话,也需要对lambda context bind的object做一些比较特殊或者类似的设计,以保证能够像envoy的这些security一样work.

而这样就意味着,如果没有follow这些practice的话,就容易或者说必然segment fault了.

关于这这点,一来是很难或者说不太容易做到这种API设计层面的约束.

二是即使做到了,接口结构层次也会显得不是太优雅.

总之,就是不太容易或者基本做不到在eventloop模型下,做一些优先级代价方面的取舍.

因为实际上无论如何都是要在一个线程内执行,只是先后的问题.

从线程自身的时间线来说,长度开销没有太大的区别.

那么跨eventloop调度呢?

Envoy的public API或者能使用到的API角度来说,是没有直接获取其他eventloop对象的.

在Envoy里叫做dispatcher.

但也只是不能直接.

因为它还提供了一个thread local相关的API借口.

是通过一个中心的main dispatcher向其管理 worker dispatcher post message切入到这些worker的context的实现.

也就是说能通过它间接地实现eventloop之间的非定向消息传递.

而既然又了非定向,结合一些比较ugly的诸如dispatcher name之类的标识ID之类的,也能实现定向message delivery.

只是做起来比较恶心.

而且还需要做一些额外的synchronize,保证在所有event loop确认触发了相应的事件/回调.

但这样一个明显的问题就是这种同步带来的不适感.

因为直觉上是对于各个eventloop的执行或者说性能不太友好的.

一个相对能够类比的例子就是GC的stop the world.

理论上体现到曲线上可能是会有一些毛刺感.

当然,就delay/async化metric统计来说,可以不用管同步问题.

一是不是特别重要.

二来,如果metric的值生成是instant/in place的,不同步处理最多也就是expose的方面有delay,影响不是很关键.

这样的话,另外一个点就是pass这些message的方式问题.

比如简单的一个std::list<Metric>,抛到另外一个eventloop的话,必然涉及到list的线程访问安全问题.

这个简单粗暴就是lock/mutex.

但考虑到像前面提到的,metric的生成速率本身比较高的话,mutex的同步开销就可能变得显著了.

一个相对优雅一些的做法是closure的binding方面做手脚.

把list move semantic,做clear cut,剥离竞争关系,一边是清空,一边是接管并顺带处理析构相关的开销.

这个算是一个观感尚佳的解决方案.

实际的问题是,这个异步eventloop可能处理不过来.

尤其前面场景,开启metric和关闭的性能是几倍到几十倍的差距.

这样的话,即使是1对1的eventloop配比关系有可能不够.

即使不考虑极端情况下worker eventloop已经把CPU跑满的情况,也需要考虑配比系数是怎样的.

而如果配比系数是adaptive的,那么随之而来的就是scale的算法和更重要的计算所需要用到的数据的synchronize或者不那么精确的approximate/estimate.

再就是进行scale时候的各个eventloop的同步以及已有callback/work queue如何/要不要re-balance的问题.

再极端一点的就是算法稳定性问题相关的,scale interval问题.

以及随之而来的re-scale的代价值不值等的问题.

最后下来可能就是重新发明了forkjoin pool/go primitive而已.

所以有时候会想,eventloop+manual memory management之于gc+runtime scheduler算是存在着代际的差异了.

至少从生产力层面来说.

而且如果说前者对于实现细节更有取舍控制权的话.

至少对于C++的实现来说,是需要有一些保留意见的.

像这里用到的例子,有比较让人不满意的差异的主要来源于debug build.

如果切换到release到话,可能差异就不是特别显著了.

这个imply的可能就是上古名言,不要过早优化所指向的真实含义.

编译器能做的优化可能比你想的更dirty/ugly.

像上面提到的lookup/string allocation等的开销.

再怎么写,可能不如丢给编译器inline加大范围的SSA/register allocation等.

就像后者的再怎么写,不如JIT的赌一把.

定向

前几天的一个随想.

大意就是BTC的单位价值,对于不同时期的产出单元应该是不同的.

因为用马克思的剩余价值角度来看的话,后期BTC的算力投入是比前期大很多的.

在假设算力成本没差别的前提下,由于投入不同衍生的结果价值自然应该是不同的.

然后这里反过来的一个点就是现代货币理论的一些东西.

现代或者说西方经济学的一个重要概念说信贷.

信贷是一种对货币流动性加速的一个发明.

在没有资产负债表概念之前,交易是当场结算的.

而借贷的产生衍生出的信贷实际上就是一种异步就算.

信贷/credit则是在此基础上的进一步泛化.

如果把借贷作为是一种被动债务产生的话,信贷则是相对主动产生的.

主动就代表一定的主观性.

比如贷款评估的时候,一个资产对应的货币量是多少,这个本质上来说是非常主观的.

因为逻辑上,这个只需要借贷双方认可接受就行.

跟实际上或者说第三方认不认可没有关系.

所以一个东西,A认为能借/贷10,B认为能借/贷10w是不矛盾的.

但是把这个债务打包作为资产进行二次或者次级交易的时候,引入的是一个新的第三方.

理论上来说,只要这个新的第三方C认可,交易也可以进行下去.

以此类推地,可以到N.

问题在于这种基于主观性互相认可的匹配具有相当的随机性和不效率化.

因为撮合具有相当的随机性.

所以为了便于流动和转手,需要有一个市场存在.

而市场的构成是对于某个规则有明确认可度的个体集合.

目的是减少撮合交易的摩擦或者是匹配难度.

也就是说,市场内的个体需要对交易的物品有基本的定价共识,从而减少不必要的重复价格互认过程.

于是就有了各种估值模型.

所以本质上来说,一个或者说一类交易品的价格形成过程更多的是一种consensus.

参与个体的一种群体默契或者说潜规则认同.

模型或者公式的正确性理论上来说,并没有什么实际价值.

一个简单的例子即使股票市场的不同公司估值模型.

拿某中止上市的某集团来说,会有以科技公司估值和以金融公司估值的市值差异.

这个的字面理解就是不同的公司类型有不同的估值模型和方式.

因为不同行业的公司有着不同的经营模式和现金流/盈利模型.

而之所以需要有不同的领域模型来解释和推算是因为如果按照纯粹的盈利/收入/分红能力来price的话,有些公司是没办法有正的价格的.

比如众所周知的互联网公司,在初期可能是没有盈利能力的.

活着更一般的,没有盈利活着弱盈利能力的公司,是没办法有一个让人舒服的价格的.

即使不考虑市场交易对价格促成的影响.

单纯就一个新上市公司如何估值来说的话,如果它没有盈利能力是不是就不能有一个价格了呢.

这是合理但不feasible的.

因为证券化就是为了融资,而需要融资往往就是因为缺乏当前的现金流.

所以,如果按照这种合乎逻辑但不实际的思路的话,证券市场就是自相矛盾的存在.

因此需要有一个默契的共识,来促成交易的表面合理性.

对于已经有类似已经上市了的公司,就会有按照现有公司的一些数据做基本forecast得出的估值方式.

intuition是既然同类在现今市场上按照这个行成逻辑有这个现实价格,那么通过类比自然能逻辑上合理地得出一个预测当然值.

这个看上去解释的过去的就是所谓的市场共识.

它不一定需要正确,但是需要是大家默契接受的评价标准.

之所以说不一定正确是因为,即使模型数据能吻合,但是实际上这个是长期市场交易撮合形成的价格.

代表的是过去特定历史时期的特定历史事件和市场情绪构成.

这个并不代表将来新公司能有相同或者类似的发展机遇和路径.

所以,本质上来说,这是一种默契的对诡辩的普遍接受.

毕竟在一定程度上make sense.

既然价格/模型的形成是在特定场景下的特定自我说服的话.

那么带来的一个问题就是,价格对表的货币当量.

但是,价格的形成因素又不具有相对可比性,但却能有有具有可比性的货币数量来互相衡量.

这就比较有趣了.

一个可能稍显复杂但是可以说明的例子就是不同的crypto currency之间的价格问题.

它们都可以跟现实法定货币做兑换.

同时每个crypto又有自身的相同/类似或者不同的产生机制,和对应的各异的波动性表现.

另一个例子就是更一般的任意两个商品的价格对比.

本质上来说,它们都是不可比的.

但是,通过或者这种一般等价物使得交易可以促成.

问题在于此时的货币作为一般等价物的合理性.

最初的等价合理性在于点对点之间的peer认同.

次一级的是公共市场的参与者内部间的consensus.

一般的认同共识则是基于日常的广泛生活交易串联穿插起来的.

比如市场A的共识对于市场B是没有意义的,因为B中的个体不需要A.

但是AB可能需要一个共同的C市场的需求,所以他们有了共同的交集和货币流动.

到这里的话,另一个有意思的推论就是.

当A的generate的量或者速率/成本低于B的时候,在通过C交易的时候,A就B有着货币产生效率上的天然优势.

比如A市场的单次交易能产生X数量的货币利润,而B内的对等交易只能产生0.1X的货币盈余的话.

在共同市场C上,A对B就有绝对的货币量优势或者说购买力优势.

所以,这就是基于信贷的货币理论的一个必然结果.

它实际上抹去了一般等价物的基本先验,而只保证的相对/有限/limited等价的存在.

另外一个问题是记账方式带来的危机周期性.

因为基本的逻辑都是延迟结算或者说option运作.

在假设vest/realize没问题的时候,资产负债表是可以配平的.

但是如果中间环节有问题的话,自然就会有不对成的情况.

而不对称的结果就是账目上的货币湮灭/消失.

当维持系统运转的货币量出现流动性或者说根本性的数目缩减的时候,自然是不太期望能够继续正常运行的.

虽然理论上,可以通过同样的合理虚构填充这部分流动性和数值,也就是通常所说的干预手段.

但前提在于能防止账目的进一步崩坏和没有其他新生的账目问题.

而这点事没办法保证或者说不可能的.

因为总存在考虑不到的链条节点.

于是表现出来的就是必然的周期性.

所以似乎信贷是一个可以解释很多事情的东西.

它的根源在于对一般等价的模糊化处理.

或者说没有一个相对明确的定义.

因为它的等价概念衍生于一个行为,也就是交易本身.

而跟交易涉及的标的物是没有什么关系的.

从形式上来说,交易物本身甚至可以不是实际存在的.

比如信贷自身.

那么马克思的一般等价定义呢?

它基于的是所谓人类劳动.

这是一个相对明确的实体或者说概念定义.

但是它的问题在于.

一个是本质上来说,它是undefined的,不同商品的无差别劳动是不可测量的.

在实际运用中,它的量度还是通过市场行为来观测的.

也就是说实际上并没有解决模糊化这个问题.

或者说至少没有直接地解决.

另一个是对于现存的信贷行为,它是解释不了的.

因为即使套用框架,你也没办法将一个未发生的事情做无差别劳动计量.

至少,不能解释估值概念/框架.

但是它提供了一个思路.

就是不再以交易作为货币一般等价的概念基础.

这里带来的一个概念可能就是货币政策可能不再以量,或者至少不再最终以量的多寡作为最终评价/衡量政策效果的标准/结论.

因为量的概念在不同的交易当中是不可比的.

反过来也就是说,在不同的渠道,不同的量的干预/扭曲程度/方式是有不同意义的.

飘

最近的冲突两方都有观点抛出了一个词,价值观不符.

这个确实可能是比较内涵的一个点.

从疫情初期的内外政策区别和舆论态度都可以算是一个体现.

今天看到两条消息,或者说两方论证.

一个是谈到棉花产量问题,连带的质量技术和产需都很大却库存积压的问题.

另一个则是对前一方的各点回应.

综合地来说,双方都没有否认进出口量大以及库存问题的存在.

区别在于,库存问题是选择性统计时间造成的数据偏差.

另外一点就是后者还提到了BCI成立后,恰恰接着的就是棉花行业的不景气.

所以如果以贸易问题作为问题焦点或者说事件立足点的话,那么对应的就是棉花的倾销性出口的事实存在了.

BCI的准入问题算是一种较为常规的行业准入协定限制,作为一种简单的提高产出成本的最简单可行的壁垒性措施.

按照一般价值观来说,就是一种联合性的君子协定或者说潜规则条约,明面上的是什么其实不是很重要.

当然,如果名正言顺自然更好.

作为贸易的一方,根据行业惯例和规则加入有限自然无可厚非.

但问题在于这条规则并没有起到预期的作用.

因为提高的成本不足以覆盖双方之间的产出成本差异.

这一点远一点的原因也是价值观和行业准入协定的影响.

只不过对象是劳动福利本身.

用行业壁垒理解工会和劳动福利的话,换算成经济效益就是用工成本.

当参与者按照相同的协议成本的时候,就是纯粹的明面生产水平和成本比拼.

也就是通常所说的公平市场竞争.

但是在用工成本不同的情况下,或者说没有达成一致共识的前提下,原有行业门槛的成本就变成了原成员共有的一个成本劣势.

这个可以用互联网广告和传统行业广告的区别来做类比.

信息技术产生的渗透广度从效率上来说是远远高于传统行业的广告模式的.

而且致命的矛盾就是,互联网的渠道是完全独立或者创新于传统广告业的.

这就是使得原有的行业壁垒在新生产力或者说竞争模式下变得毫无意义,同时维护行业壁垒的投入成本变成了一种没有回报的坏账.

所以,从本质上来说,这是两种生产用工方式完全不同造成的成本核算的不对称问题.

从竞争的角度来说,就是一方的成本低于另一方,导致的结果就是相对来说没有什么竞争力.

再考虑到如果成本优势方有生产优势以及规模优势的话,无论是倾销和正常的市场化行为,最终都会造成其他方市场份额的萎缩甚至退出消失.

从这个角度看威胁论的话,也就不是没有什么现实意义.

因为从一些产业来说,确实已经到了被动需求出口供应的地步.

极端的发展就是所以生产都将在一国产生.

对应的就是它过的生产和就业出现一个未知或者说并不理想的预期.

而这个又恰恰是自由市场共识或者说潜规则体系所不相容的制度或者说运作机制.

无法通过一个现有的有效方式,协同成本差距.

所以这种担忧和无力感是实实在在的.

换个角度来说.

这种担忧是虚构的或者说不切实际的么.

也不是.

即使是按照自由市场的逻辑来说,商业上即使可以通过规则条例确保规模限制.

但是也最多只是规模限制.

一个有效同时也微妙的比喻就类似于芯片行业.

可以约束产量规模甚至制程技术,但本质上来说,技术优势或者说差距不是那么容易填平的.

所以用最终的全面产品倾销来理解这种对抗性思路可能也不是太过离奇.

而这种概念在稍远一点的历史时期就是所谓的航海殖民时代.

这是一点.

另外一点就是强迫劳动的问题.

抛开前面的隐含逻辑,看描述的话.

一方给出的争端指责是大规模的劳工迁移和非自由意愿的劳动.

另一方的对应则是作为扶贫政策的常规操作.

双方都没有否认的一点就是确实存在着劳动人口的迁徙.

以及双方都认同或者说采纳的一份视频材料.

里面提到了一位工作人员描述工人为懒惰的片段.

这里无论是以强迫来动还是以扶贫工作的角度来看,确认的一个事实是工人工作有一定的非主动积极性.

这点怎么理解本质上会是个比较难界定的问题.

以宏观和制度性角度来说,这可以理解为一种压力驱动的进取模式.

应对的不给定外界驱动力难以达成进步的方式.

就像健身或者说考试学习等.

需要一种反人性/舒适区的手段.

但是如果以个体角度来看,就是一个被强迫竞争的态势.

一个同样也是有效且微妙的比喻就是延迟加班和内卷的问题.

它形式上就是一部分人的投入和另一部分人的期望投入存在不对称的情况.

而在外部考核评价体系下,不对称的投入期望成为一种数值上的类成本劣势.

尽管以个体的利益评估体系来说不应该做,但却被迫投入的一个情况.

中性地来说,两种情况都是一种外界驱动的被动加大投入的方式.

所不同的是,回报率的计算方式跟立场有关.

所以,以纯粹论据或者说价值观体系来说,两种说法都不算错.

这就是为什么说,抛出价值观冲突这点算是一个明确或者说某种程度上明朗化的一个表现.

不同的价值观带来的是不同的行为方式,以及行为预期.

不符合预期的行为自然一般会被认为非理性和不可理解的.

以及不同预期在协同交互过程中,自然对回报会有不同的理解和对应期望.

不一致反倒是一种必然.

从三角债谈起

在给定的循环三角债情况下,即比如A欠B 100,B欠C,100,C欠A 100的情形.

那么作为央行或者说银行信贷方来说,就有一个直接naive的方式作配平.

即给ABC各100的额度,然后后续就能恢复流转.

这种方式产生的信用额度就是300.

但是一个更optimal的方式是给其中一个100的信用,然后也一样可以让系统流转起来.

所以单就经济刺激和货币宽松来说,额度倒也不一定是体现最终实际规模的一个标准.

但可能反过来说,更反映的是解决切入的侧重点的问题.

通过给消费终端注入资金水平,用凯恩斯的思路就还是利用消费需求反推生产.

但通常来说这里的思路实质上依赖的并不真是末端消费者的消费行为所带来的产业链回溯.

而是末端消费产品的生产商的需求逆向扩张的结果.

也就是说,如果即使消费端有大量的资金购买/流入某个商品领域,但是这个商品本身能够惠及或者需求的产业链上游有限,或者说普及面不够广的话.

那么至少从投入成本和收效的角度来说,就是300和100的区别.

另外一个问题就是,从消费者角度来看.

注入的资金的性质或者说实际用途的效用分类问题.

假如是在一个相对静态或者说变量环境没那么多和复杂的情况下,单纯的提高可支配收入自然是可以理论上等比例地提高对生产需求的反馈.

但是如果消费曲线本身不是那么静态,或者说是在萎缩的前提下呢.

比如因为没有工作机会造成的收入停滞/衰退,消费的目的从改善型回归到的基本的生存需求上.

那么这个消费刺激的回馈场景就相对来说可见的.

会比较集中于基本和底层的衣食住行的低层次保障性消费上.

而一般地来说,像基础食品制造和加工的需求增加或者说恢复并不见得能对就业情况带来一些比较积极明显的改善.

因为现在工业文化在这类基础性保障供应上比没有太多的劳动力方面的需求.

或者说单位劳动力的生产能力剩余比较充裕,足以覆盖增加的部分.

所以它的实际效用可能还不及100.

然而,问题在于既然从效用角度来说,并不是一个显而易见的较优方案的话,为什么还会选择执行呢?

尤其在同期有其他一些产业链刺激鼓励决策/政策意向的前提下.

如果考虑说产业发展并不需要或者还没到需要一个自上而下设计推进的阶段的话,那么按照以往的理论,最终也还是能够推导倒消费终端和劳动者层面.

也就是促进就业和恢复经济的道路.

一个可能是劳动力结构问题.

或者说产业结构问题.

如果大多数劳动力/产业是一些比较小而分散的非规模经济的话.

那么即使有一个倾向性明显的产业鼓励政策,由于不在同一个层面,也就自然无法被惠及和影响.

比如多是一些自由和个体小微企业的话,除非是行业强相关.

不然产业链长度是有限的.

另一个可能是时间问题.

或者说紧迫性问题.

因为虽然理论上来说,刺激性方案可以在结论上产生一些产业连续乘数现象.

但是实际的执行上会有一个时间因素在里面.

如果在效果产生之前就已经破产或者无法生存的话,结果的推演如何美好也是没什么太大意义的.

但这里的另外一个问题就是,从额度或者说数量上来说,能覆盖的也就是几个月的生活成本而已.

这样的话,问题就变成是这个时间周期是预期的一个安全恢复边际呢,还说是一个在当前成本支出情况下,所力所能及的一个极限extend了.

从市场rumor来说,利率飙升是一个几乎没什么歧义的共识.

毕竟长期成本放在那.

但问题在于,这个动机是纯粹的预期成本带来的还是带有一些其他情绪和因素.

如果参杂的是对于国债的一个偏好增强的话.

那么同样的理由就可以理解为一种对风险偏好方式的情绪改变.

再进一步的就是对非国债的一种避险趋势或者说本能.

而这点跟对就业改善预期的不期望也是大致有一定的趋同性思路的.

这样的话,把持续宽松承诺和持续上升的国债收益率两个本该相悖的东西放一起看的话,似乎也不是那么不相容.

问题在于,如果远期来说是宽松的话,而利率水平又上升,那么指向的就是inflation了.

这个反映到国际上的话,就会是一个相对比较有趣的问题了.

如果作为锚定货币的话,对方要继续锚定inflate之后的汇率的话,就会比较困难.

因为不一定能适用同等宽松的策略.

而如果不能的话,那么从负债角度来说,就是一种财富的转移/成本的嫁接了.

再进一步的如果经济体本身就有一些问题的话,可能就是连锁反应了.

而作为非锚定货币但是主要信用支撑载体和通货的话,可能对应的就是多元化分散了.

减少对单一货币信用的依赖程度,减少通胀的被动输入依赖.

从货币母国的角度来说,可能就是国际信用/地位的相对浮动变化了.

乐高的玩法

前两天拼乐高的时候想了下,感觉应该会有竞技类型的比赛.

毕竟理论上来说,这个还是可以有一些策略和训练性质在里面的.

如果不考虑一些其他商业因素的话,乐高的建模以现在的技术水平来说,可能也就是一些3D渲染的应用.

一个比较近似的例子就是Minecraft,以有限组合的类pixels.

每个积木单元可以是基础的构件.

至于形态的多样性主要就取决于渲染效果的近似性需要的.

有些需要更柔和精确的就可能会作为一个特化元件.

这个在没有computer assisted的时代应该个挺有挑战和挺有意思的事情.

当然,在现在来说可能依然是.

一方面是传统的元件拟合设计.

另一方面可能是更商业化的,如何平衡特化/利润/独特性/通用性/成本/品控的一些列综合因素解了.

前面说的竞技性的点在于,本质上来说它就是一个模式识别的过程.

因为渲染构造和元件复用的因素,一般来说每个元件与元件之间是有一定的组合亲和度/概率性的.

类似于棋牌类项目的起手式/模式之类的.

给定一个初始状态会有一个对应的状态概率空间的展开.

当然具体到乐高本身的展开又可能会有些不一样的地方.

元件的展开和元件空间的构成的结果是一些更高一些维度的组件性质概念.

或者说是更大规模一点的元件.

就像神经网络的low level的feature叠加成更高level的表达方式.

所以,理论上来说,这就是一个物理空间概念上的拟合矩阵.

复杂度和parameter数量对应的就是元件的设计和叠加连接方案了.

抽象地说,这就是一个算法的快速解的比较过程.

给定一个拟合目标如何更快速地还原构建出近似解.

具体到实际就是需要对元件的组合规律有所了解和记忆.

这里面又涉及到如何从一堆细散物件里准确找出需要的元素.

所以就是一个识别,分类,检索,构建,叠加的过程.

如果把初始的器件筛选过程比喻为磁盘IO的话,就类似于有顺序随机读写之类的实现性能差异.

而选择以那种高级元件为构建目标就是上层的buffer管理之类的了.

之所以说是buffer是因为像建筑类,主要就是一些重复度高的building block的批量制作过程.

就像做计算时候的cacheline等管理.

从这个角度来说,这种竞技性就是技巧和设计或者说流程架构上的效率区别的比较.

那么顺着这个思路,就像一些游戏的速通记录一样,在一定程度之后会有一种相对认可和公开的模板模式作为一个相对优解的出现.

于是第二层的竞技因素就在同样步骤和方式的前提下,单纯比拼速度的形式了.

如果以日漫ACG的方式表现的话,大概又可能会有拼装手法/手势上的一些纯体育竞技方向的技巧差距拉开.

不过这个实际搜索了下确实有类似的contest.

只不过速度没有想象中那么快.

至少从视觉观感上来说,不如魔方等同为既定技巧下的速度竞赛.

不过这可能是因为竞争或者说接受度没那么广.

以及看到的素材本身不代表实际顶尖竞赛水平.

那么除了这些点之外呢?

尤其speed contest方面还有其他玩法么?

因为之前的都是基于构建.

那么自然的可以有拆除或者重构建的竞赛方式.

最简单的就是给定一个模式,以最少和最快等标准从中拆除然后再构建的方式.

再进一步的,可以是拆除资源是共享的引入资源限制和竞争关系.

这样的话又会带来其他一些的变量.

比如各类元件资源的数量是给定和既定的.

同时需要构建的元件的对应数值也是确定的.

那么在数量方面至少就产生了策略对抗性玩法.

因为某种元件可能是有限的甚至是唯一解的.

如果获得不到或者不够就意味着速度优势并没有什么价值.

以及如果再进一步的,加入竞赛者之间的资源掠夺方式就又会使得变量进一步膨胀.

就像典型的RTS游戏.

speed rush和资源型都可以是一种制胜策略.

其他的一些思路诸如密室类key玩法.

因为本质上来说,可以把它看作是一个programable的东西.

既然是这样话,那么它包括的就是build run and test一系列中间流程以及最终的runnable的产物.

中间流程可以成为竞争点的话,自然最后的runnable的成品也可以是要素之一.

而且如果把整个串起来的话,就对规划性和策略预判有更高的要求了.

因为从即使前面阶段能够获胜,但最后runnable的东西不适合不可用也没有意义.

毕竟这最后一点的设计可以是在初期unreveale的.

这就像地下城模式的剧情和角色天赋转职适应性一样的设计.

所以回头看的话,这几乎就是一个可以把所有game play因素搬到线下的一个东西.

或者更确切地说,就像一个转生RPG的一个重要初始道具.

后期的发展和剧情推动以及互动元素都在于这个的build run的全过程.

失控

前段时间es改licence的事情.
AWS的回应则是直接fork了一个出来.

再往前类似的还是有Cloudera/Hortonworks之类公司的命运.
以及关于Chrome/Istio等的debate.

还有可能就是也是近期的CentOS的事情.

这里其实可能都是同一个问题,关于open source的.

或者应该说是同一类问题.

一个是商业化/生存/延续性.

一个是更理想化一些的存在性/感问题.

最初是没有什么所谓商业模式和存续性问题的.

一来是时代背景.

二则是本身的重点在于要解决的问题,而不是作为工具的项目本身.

后来是以技术咨询的方式提供了一种运营支撑的能力.

而对于这种能力的需求,本质上来说是成本变高了.

这似乎是个废话.

因为维护成本变高了,自然对于投入就更有需求的.

成本的提升在于需要解决的问题和需要覆盖的面越来越广和深.

自然的对于人员心智和各项配套软硬件的需求会增多.

所以成本增加和专职专业化自然地会需要有一种能够以有偿支持的方式维持.

当然,理论上来说,纯靠爱发电的项目也不是不存在.

而且数量也不能说算少,其中有影响力的也有相当规模.

但总得来说,它还是需要有一种能够支撑运转下去的经费来源.

所不同的是这笔开销是来自于自身的投入,还是说靠crowd.

crowd方式一种是donation,一种就是商业化的转化方式.

donation的一个主要因素在于还是人群的基数.

只有到了一定用户和影响力的前提下,才有可能依靠donation维持下去.

所以,商业化可能是相对来说唯一的选择.

商业性能成功的前提在于需求的必要性.

不管是因为技术门槛的主动必要,还是以投入产出周期衡量的被动必要性.

换句话来说,技术咨询的价值在于要么使用方自己搞不定,要么自己搞的各种成本来说不划算.

那么反过来,只要这两个不成立了,商业化的前提就可能需要revise了.

在现在来说,项目本身的技术门槛可能已经是不太可能存在的了.

一方面是硬件的发展,使得在一定规模的非技术因素面前,软件本身的差异性带来的结果并不会很大.

另一个是一定规模以上的公司,本身的研发能力和技术覆盖面可能比项目owner有着更多的优势.

所以,纯技术角度来说,项目本身的必要性就变得有些不那么必要了.

第二点的成本问题.

这个更好的例子就是es本身.

云服务本身提供的解决方案和集成度使得在成本方面,也变得不是那么有吸引力.

因为相对地或者变相地来说,就是原来专利的市场变得有更多的竞争者和同行加入.

所以即使本身的服务必要性从市场角度来说并没有太多变化,但是利润和收入自然是另外一回事了.

而针对云本身的另外一个问题就是,istio所代表的另外一个角度.

Istio的分立以及Kubernetes/Chrome社区对Google的concern反映的一个直接表象就是独立性问题.

它指向是项目发展的主导权和方向性问题.

前面说了,open source project的技术方面是基本上可以说无足轻重的.

修bug提feature实现这些都不是什么太大的问题.

问题的核心在于怎么回到社区中去.

抛开立场来说,一个pr能不能merge更多的是取决于是不是符合社区的某种审美和需求以及方向上是不是具有统一性.

如果不符合社区精神,或者跟社区的规划相冲突的话,自然是不太可能被接受的.

这是个没什么特别值得挑剔的逻辑.

也合乎想当然和正义.

问题的点在于社区是谁.

或者说谁实际代表了这种否决/投票权.

所以像前面提到的三者,它隐含的第二层问题在于主导者的conflict of interest.

你如何保证或者说如何对抗Istio/Kubernetes/Chrome对涉及背后公司的服务利益的时候,不会有偏向性或者说针对性的弱化强化.

因为本质上来说,这些开源项目是一些商业公司的员工专职维护的.

尽管有时候,主导项目的是若干个不同的公司.

但除开这几个公司之外的,或者说把这几个公司看作一个利益共同体的话. 

那么对于其他公司来说,是否具有公平性.

答案自然是否定的.

因为即便抛离道德因素.就同等的资源投入约束来说,在给定的proposal当中,也是会以某种有立场的方式priority的.

你也不能完全说是不公平.

毕竟实际的最优解就是这样.

所以某种程度上来说,现在的open source真的就剩source是open的.

形式上,更多的是一种公开的委员会成员之间的open collaboration.

当然,还是前面提到的.

至少在目前的阶段,技术本身不是太大的门槛.

自己fork也是另外一条路.

只是相对来过去来说,维护成本会更高.

而对于商业模式而言,基本上就是不太可能有的了.

毕竟,不管在技术能力和商业规模上,owner本身的体量差距是有一定的.

所以,如果从这个角度反过来看互联网或者说社会本身的某种发展趋势来说的话.

其实也就相对好理解或者说解释.

现代社会的很多东西,尤其是信息化的基本上都是建立在几个巨头的基础设施之上的.

本质上来说,除开巨头本身,每个个体或者说团体不过是上面的一个lender.

在方向性和趋势甚至于说需求来说,都取决于平台本身提供了什么.

所以有现在一些特别或者说奇怪的现象,反倒是非常正常的.

那么问题在于,为什么之前没有或者说不明显地被感知呢?

为什么需要明显地anti- Trump,ban GameStop transaction呢?

因为从平台本身的角度来说,这么做具有正义性和某种可能的道德约束感.

一个是在自己认知对立面的ignorant.

另一个是反秩序的chaos.

本质上是自认为的对irrational的修正手段.

所以从这个角度说是可能的某种处于社会风序良俗的社会道德责任感使然.

虽然并不一定成立或者说存在.

但至少来说,是一个可以对外阐述的合乎逻辑的理由/陈述.

那么这个理由成立么?

或者说有相当的正当性么?

这个可能就比较有趣和微妙了.

如果把它纯粹化一点,这就是个简单的regulate/censorship的动作.

这个是现在才有的么?

也不是.

一个简单的例子就是恋童等话题.

这个也是某种出于于社会风序良俗的社会道德责任感使然的禁止行为.

它的正当性或者说被接受的点也在于,这个是一个确实接近于全社会层面的道德约束共识.

所以它没有那么明显的意识形态冲击性.

而现在的这种conflict的存在就在于反过来的,在是不是正当/符合道德共识这点上存在着明显的分歧.

这种分歧显得明显的原因在于,两者或者更确切地说,多方的人数都具有显著大多数的性质.

不像恋童等具有少数性原则.

或者至少在发声和被接受的层面来说,各方面具有着势均力敌的可比性.

所以到这里似乎可以认为这是一种认识被打破之后的知识混乱时期.

因为暂时地谁也没法用一种可行有效地方式dominate对方,使其它方变为相对少数.

而基于此反过来imply的就是,平台作为基础设施提供方的权威性或者说某种控制能力的失效/收到挑战.

那么新的问题就是,既然在前面的理论框架内,平台上面的个体/群体的消费品都是由平台产生控制产出的.

也就是说,从设计上来说,这是一个至少在高层次是单向传导的可控系统设计的话,下层/底层的变化反应产生的动态性是如何造成上面的不稳定发生的呢.

所以要么前面的假设和推断是错的.

要么这个系统本身存在没被考虑到的exploit点.

新资本主义

看了下美国2019的一些数据.

收入中位数是3w美元.

80分位的话,应该是在6w美元左右.

那么两千美元的stimulus大致就相当于中位数3/4个月收入.

80分位2/5个月收入.

也就是说如果只是当作一个缓冲区看待的话,时间不超过一个月.

以总人口300+million算的话,这项的开销656 billion.

即使按收入统计口径的人口算的话,200+million的人口开销也在458 billion.

差不多是GDP的2%-%3.

所以某种程度上可能可以理解为一种提前兑现或者说维稳的措施.

作为对于GDP增长率的预先兑现/对冲.

只是可能并不是很有效率.

考虑minimum wage.

之前是7.25.

按照正常一周五天每天八小时算的话,年收入大概是1.5w.

根据2019年的数据,这个比例大概有60m,在收入统计口径的人口的26%左右.

按总人口比例的话,18%.

提高到15刀的话,差不多就是3w美元.

也就是2019年的中位数收入数字.

一个不太恰当的理解就是把原来30分位的生活水平拉到50分位的位置.

假设这15刀的增长差额以某种形式的政府补贴替换的话.

大致是970 billion.

是2k美元stimulus方案的2倍.

但同样但思路就是,如果不是补贴7刀,而是补贴一半的话.

就是3%的GDP和20%的收入水平提升的决策关系了.

另外一个数字是证券市场.

2019 US Stock Market Value总值是37,689 billion.

2018年的值是30,102.

也即是说以市值计算的话,一年增长是25%.

到这里的话,这些有些相似巧合的数据就变得有些意思了.

理论上来说,市值增长能够兑现的话,那么对于财政补贴需求的资金来源就没有什么太大问题的.

因为占比不过是年增长的11%左右的程度.

所以从这个角度看川普不惜一切代价保证券市场的手段也不算是没有什么依据.

毕竟证券市场的一个特征就是非线性的.

市值的变动并不存在一个双向的必然的量级关联关系.

那么它带来的就是一个发展或者说策略的变化方式.

传统的国别或者区域之间的经济相对性是通过贸易来实现的.

买卖之间的差额积累,以及衍生出的进出口差额成为贸易双方经济地位的一个区别实现方式.

所谓的低买高卖的商业逻辑.

它底层依赖的一个是供需的差异化.

也就是互通有无的关系.

另一个是成本的考虑.

即在双方都有的情况下,一种择优选择的方式.

两者的一个共同点就是,确实地存在竞争与合作的关系.

但是如果切换成金融市场的话,就是另外一个方式.

它其实并不依赖与参与者之间的实际联系和依赖关系.

因为运作的核心机制是套利.

一个相对极端情况但是有现实基础的就是,即使一个东西本身是没有什么具体价值的.

但是基于某种市场的共识,它的交易依然能够存在.

也就是使得套利空间存在.

那么反过来说,金融本身是可以不依托于底层的实际贸易交往存在的.

更近一步的,即使没有直接接触关系,在金融市场依然能够以某种方式促成套利的存在.

从而使得资金和资本产生流向.

一个理论上的形式就是,以殖民的角度来说.

一方可以以金融的方式转化/掠夺/占有/享受另一方的产出.

且相对地,最终并不支付任何成本.

所以某种程度上来说,这可能是比制造业全球化更为隐蔽和优势的一种殖民方式.

金融的全球化并不需要特定的标的物存在.

所以除了禁业风险之外,几乎没有什么其他地缘性的问题存在.