中文的标题就叫做“秋日遐思”吧，或者说瞎思也好。有一个revery的词专门描述这种空想的状态，或者说应该叫做 meditation?
在高楼密布的地方似乎很难体会到诗词里说的那种“自古逢秋悲寂寥”的意境。最近常常能看到三种颜色的天空，偶尔会有一只鹰在空中盘旋。不禁让人想到电影里说的 little hunger 和 great hunger 的故事。Jobs说的keep hungury, keep foolish。可能要看 hungury for what 才能让自己不吃成一个胖子。
做梦梦见了小学时候的同桌放学后等我一起回家。好久没有联系的人脑海里只剩下几个关键词和她小时候笑起来的样子。于是就凭着映像搜索，也要感谢网络的便捷。她说话的时候还能依稀看见小时候的轮廓，讲话的时候还是偶尔还略浮夸。同桌的亲戚是我们当时的班主任，想想那时大概是沾了同桌的光，班主任对我不错，可这也是后来的事情。还记得刚开始，我是坐在班里的最后一排，因为上课捡了一块橡皮被老师叫去办公室打屁股。后来慢慢意识到，好多时候是老师对我好也不是因为自己多有潜力还是老师本身有多高尚，大概还是因为爸妈打过招呼的关系吧，可爸妈能帮助的也毕竟只是有限的阶段，那自己还有什么能让别人来投资自己的本事和手段呢。老师，说的高尚一点是教书育人，可实际上也不过就是一份职业罢了，就那么多时间，多关注了你也就少关注了别人。
屋子里的烟雾报警器一直在响，晚上打了emergency的电话。在大叔帮忙换报警器的时候，本以为拔开电线插头，把两个裸线接在一起是很麻烦的事情。可原来现在的操作都是标准化的，有一个椭圆形的中间是中空的塑料壳一样的装置，只要把两个线放进去然后转动那个装置，两个线头就会自动锁紧在一起。虽然是个简单的装置，但感觉还是很奇妙，觉得有不少心思在里面。想起小的时候看家里人做同样的事情，先用钳子把两个线头拧紧在一起，然后各种黑胶布裹来裹去，每次更换线头都是繁琐费力，这大概就是小作坊和标准化临时代码和架构良好的项目之间的区别吧。
夏天来不及追回
花儿在冬天枯萎
并非每夜都能睡
到是期望一场醉
论文怎样都是水
生活怎样都是累
不知怎样才是对
为何生活变乏味
难道犯了什么罪
头发稀疏脸疲惫
看到心里都是泪
把自己写的论文草稿给老师或者别人看，那感觉就如同去医院看病。大概我这是慢性疾病，所以看的比较久，颇有种纠缠不清的感觉。最近p说他有个小孩子，以前看到像仇人一样，现在好了一些。大概不只知道是重了哪门子的邪，写的代码总是不久之后就deprecated掉了，很少有能长久发挥作用的某几个项目。之前做了一些关于programming的视屏放在youtube上，本来以为没什么人看的，结果竟然收到了有人问问题的邮件，多少感觉还有点奇妙，仿佛形成了某种正反馈。
可能论文写好的标准就是像一个reviewer那样来思考，那reviewr什么样呢？没有很多的时间和耐心，语言素养很好，一些不好的词句表达，冗余的表示或者是图表的搭配都会让他们觉得这个work用功程度不够。不会细看，会很快地浏览整个文章，从全局的角度来考虑这个工作是否solid。一句话也不会反复地区读，会很快地过然后得到大致的映像(第一映像以及结果呈现很重要喽)，看不懂就就觉得是writer的问题，所以writer要把前因后果写清楚，逻辑上不能跳步。这个数据为什么是选择这样的，先不管理由是否足够合理，但要尝试从scientific的角度给理由，表述准确，少用模糊的词，快是和谁比就快，慢是和谁比就慢。出现的term要提前给出解释或引用，不能一上来就默认user对术语很懂。
每次一段一段的修改往往会丢失一些全局性，reviewer当然不会一段一段的看，肯定是一整段一整段的看，大概就就像是弹一个曲子一样，每次都先把这个曲子弹完然后老师才会点评，中间哪里哪里不好，之后集中精力重点修复有问题的地方，最后再整体合起来继新的一轮iteration，自己看自己的work也应该是分成两个部分，找问题和改问题要区别开，找问题要快速浏览，全局把控，一遍读下来不纠缠细节。改问题要一点点小心修正字斟句酌。
之前做rl的作业，主要是关于10 bandit的problem，在programming的时候总是有点类似dynamic progamming的table迭代的问题，有一个常用的小技巧印象比较深刻就是如何使用比较少的空间求平均值，具体可以参考rl的教材，主要就是迭代的问题，如何通过rn来更新到rn+1，降低空间复杂度。
之前又一次花了一整天的时间在看一个MPI引起的问题，主要原因就是多个task run 在同一个节点的时候，mpi会使用shared memroy通信，这个时候之前的低版本的有些问题，会产生一个错误说是相关的library有问题，但如果更新高版本的MPI之前所依赖的一个library又无法正常build，于是只能把node多分配一些，然后不同的任务run在不同的node上，避免使用shared memory。还有一些trick的地方比如3.x的MPI与srun结合的时候要用pmix_v2然后2.x的是用。后来还是升级了高版本的MPI，只不过在build library的时候绕过了一些项目，比如build test 以及 using fortran
之前与同学一起吃饭，讨论什么样的idea放在paper之中算是比较好的idea。两个观点还比较有意思，一个是说，这个idea不是那种incremental的类型，比如类似于在一个东西上修修补补优化之后更近一步。另一是说这个idea要适用于一类问题而不是一个问题，就是说要比较具有一定程度的适用性。从这两个角度老路问题往往能有不一样的想法。
没有人傻到再去造永动机，但是类似的想法还是改头换面出现在不同的场合中。人总是难以摆脱主观而固执，常常是想我就要一个这样或着那样的东西。大概并不是说，你想怎么样就怎么样，而是事情本来是怎么样，会朝着什么样的方向发展，才是顺一点的思路。
选择了一条路又怎么能羡慕别人选的路呢。成长和崩塌都是很迅速的过程，中间的时光似乎就是可以可无的熬着，许多天许多年的如一日。NJ的雨和雪都是很拼的样子，到还是喜欢细雨蒙蒙的感觉更多一些。有一些不再联系了但心里总想着的人，仿佛一个个都浓缩成了朋友圈中的一个头像和名字。人很奇怪啊，并非所有的事情都能找到一个合理的解释。谁去哪玩了，谁结婚了，谁的小孩儿满周岁了，由于每次点开看都是隔了好久之后，那种感觉挺奇妙的，仿佛是说，啊，原来你都毕业了，啊，原来你都结婚了。
与老板讨论问题必备要素 the framework to consider the problem：what is the problem, motivating use case, the next step(time line), how about the system design, what is the assumption and the tradeoff for this work, how about the scalability for this problem, how scalable it is, what is the core issue for its scalability. Currently, it is still not clear for me to figure out all the necessary assumptions for the distributed system. for the hash or the dht, before explain the solution, it is necessary to explain the requirements for this system, what is the assumptions here.
有一点programming的感触，主要是看programming的背后承载的是什么
programming层面更多的是经验知识，把背景体系弄清楚之后具体实现出来，什么样就算是弄清楚了呢，一个是依赖的逻辑关系是什么，1:N 还是 N:1 还是M:N一个是object的interface的问题，struct是否包含了所有的信息。总是是要先把logic的东西理顺。
有时候也会想想手段都有哪些什么的。
一个是 device 层面的track
use the high speed device (memory hierachy, cache)
use the high speed network
use more resource to solve original problem efficiently, utilize more resources efficiently (distributed , scalable)
compiler configuration DAG 自动优化
使用code操作各种driver是一个很实用的技术，这里的瓶颈就是最先进的device比较难获得，比如一些先进的存储device，而且总是能找到一些相关的替代产品。
一个是 数据加上算法 这个track 大致考虑的是，如何
reduce the repeated computing (store the computed results, balance between the time and the space) (check pointing, falure recovery)
decrease the size of transferred data by specific strategy
increase the parallel of computing and the I/O as much as possible (data partition, parallel algorithm)
combine with the domain knowledge, such as implement specific equation (偏重于应用一些)
弄paper的时候要多考虑考虑这些问题，大概就是所谓的contribution的着眼点，如果发现自己的work这些点没有的话，这个work的motivation就是有问题的，就是更多的所谓的一个工程的项目或者是业务项目。
从这个角度上看，最远期的能看到的技术的投资是quantem computing & algorithm，近一点的就是rdma的library的熟练掌握，比如libfabric还有 shared memory 的使用，还有PMDK(https://pmem.io/book/assets/Chapters/Chapter01_Preview.pdf) (persistent memory)虚拟化内核这些技术距离自己有点远了。
数据和算法方面最火的应该是DL ML 但是自己接触的场景不多，根据目前的条件和课程选择来看，统计类的算法加上RL可能是一条比较好的路，数值方法上和simulation贴合一些，大概就是目前的一些思考了吧。
还有想想自己代码无关的知识都有哪些，这些可能是比较重要的desgin srategies。
做一个事情遇到阻碍是常常发生的，有的时候是来自别人的阻碍，有的时候是来自客观条件的限制。其实有的时候不要对别人的所谓泼冷水有太过于care，核心是要明白自己弄的这个事情价值点在哪里。长远看有几个大的原则一定要把握住，做的事情一定要有叠加性，就是把efforts转化成了一个实际的东西（比如使用scripts而不是每次重新type commands就是一个typical的case)，自己做的这个东西能发挥一些长远的价值，不能为了research而research，此外这个东西一定要发挥出一些切实的价值，再给别人show的时候，首先自己要对做的内容有一些confident，这个confident来源于实际的usecase(就如同代码的testing一样)，然后解释的时候要有耐心，娓娓道来，对比人说的话也要取其精华去其糟粕。怎么讲不能为了research而research呢，一定要知道自己做的这个东西强项以及缺点在哪里，缺点的地方怎么样通过和别人的合作来弥补完整，就是一定要关注real problem而不是fake problem，至于real problem是什么，就要根据具体的领域来看了。
刚开始的时候会把正在弄latex放在github上，然后本地latex编译这种，几个人合作的时候就互相issue，但有时候还是会冲突覆盖等等。后来回归到了overleaf，合作的时候方便多了，但发现自己改的时候在overleaf的editing的模式下很难有全局的感触，于是就是弄成pdf，每次完整地过一遍，把有问题的地方标出来，但是不去修改，之后再进入修改的状态，大概是review的状态和修改的状态在来回地切换。后进来发现每次给老师写pdf这个不能叠加，于是就尝试开始把readme当做proposal来写，这样以后这个repo别人看的时候也不是一堆代码，然后整理paper的时候也是现成的材料直接能用，background，motivation，approach甚至是一点implementation的details都可以写在readme里，然后对这个readme进行不断的迭代更新会有一点叠加的效果，而不是随便写了一个pdf交给老师然后过几天就没下文了，也不能持续地叠加。
有的时候也看一些综艺节目，比如主持人，奇葩说什么的，现在的综艺节目都是有那种向着职业化方向发展的趋势，比如都是导师带着学生然后比赛pk的这种模式。和好多年前的那种差别还真是大。以前的时候一个节目叫做正大综艺，就是找一些表演节目的团体各种表演，唱歌跳舞种种，想想很有年代感。说到年代感，一个体会就是每次填电子表格到了生日的时候，都要往上翻好几页，以前的时候似乎很快就能找到。有的时候又觉得自己要提升一下眼界，不能总是停留在学生的思路上，日常生活，为人处世。又要去参加sc了，还是自己掏钱，想想去年也是一样，各方面也没什么大的长进吧，一年多了感觉还是在做同样的事情，比如之前老师就在强调scalability，经过了很多坑，方向也不对头，这个事情自己首先要心中有数，知道大的方向和主流的趋势在哪里，然后还要知道老师要的是什么。完全按照着老师的走和一点也不按照老师的走都是搞不定的。就有点回到了和别人argue时候的技巧，自说自话的时候往往就谈不到一块儿去，首先要知道自己想要讲的观点和主题是什么，然后耐心地听懂别人讲的是什么，在弄懂别人讲的内容的基础上在看自己理解有没有偏差，好多时候自己都是在自说自话了。
想想高中的时候参加了一个学生记者团，当时要和另外一个同学去采访一个出去出国交流的同学，本来应该两个人一起过去，后来不知道为什么自己就跑过去弄了，也没有和另外一个同学打招呼，可能是挺讨厌的那种人吧，不怎么会和别人合作。所以有的事情就先听听别人的意见，然后明确自己都弄懂别人想说的了再取其精华去其糟粕。
关于 technical report 与 research paper 的不同是要好好考虑一下，好多时候是要倒着想想看，先要说传达什么内容，然后再加上一些细节，技术细节以及实现细节就完全可以很快带过。或者technical report的内容可以放在project repo 的 readme 里面来，然后paper中主要呈现的是方法和结果。
最近有两个想法，不管是research相关的内容还是和别人讲话的时候，有时自己就是活在自己的世界里。比如说自己就要要弄这个问题，自己就是要这样做种种，最后就成了民科的感觉。显然首先是放空自己，然后了解别人说的话，梳理清楚了脉络，再把自己的观点和思路融入在其中。特别是research这种事情，从来也不是一个人的事情。
还有一个是关于writting的事情，可能是看了奇葩说之后自己比较有感触。好多时候重要的点在于怎么来表达分析的过程而不是说怎么去claim或者argue。自己在writing的时候常常也是这样，会习惯先给一个结论，然后在陈述。纵然思考的时候是这样，但叙述的时候也是反着来的。有几次甚至发现，在写完分析的过程之后，给出的结论更加准确具体，没有详细的分析就直接去claim一个论点显然是自己常常会犯的问题，有的时候是没有把前提解释清楚，有的时候是在论点不准确，总而言之在开始的时候给出论点是一个非常危险的行为。在开始的，比如段落的开始作为总述的句子可以是说这段介绍分析的过程，或者是从哪个角度来开始分析，而并不是一开始就claim，一上来就argue反而是一种业余和让人难以接受的行为。所谓分析的另一个过程是弄懂别人说的什么，领会到别人的意思之后再有针对性的交流，否则就容易变成自说自话。其实在找research方向的时候很容易有自说自话的嫌疑，好多时候就是自己脑补一个direaction觉得靠谱，但没有细细理解别人的论文中的思路，很可能这个点别人已经讨论过了，很可能这个点并没有很高的价值，总之在确认做这个事情之前先静下心来问问自己是不是真的把相关的论文理解的透彻了。
fall story 可能也就到这里了吧。
回想起来，冗长的日子里夹杂着一些细碎的情感。
回想起来，总觉得忙来忙去的，却又没有什么大的长进，也不知道自己整日在忙什么。
有一些总是担忧着的总也搞不定的问题，却又总是被反复提及，徒增压力，却也无可奈何。
也说不上是到底是变得敏感了呢，还是变得麻木。
是有几次想吐槽，话到了嘴边却又是欲说还休，心想还是算了吧。
无趣的状态似乎也变成了常态，这怎么能行呢，所谓的生活呢，难道是自我惩罚吗？
看了一场电影，前半段睡觉，后半段质疑剧情烂俗，也可能是没有听懂吧。
总觉得周遭和自己有关的事情变得越来越少了。
