首页 文章 精选 留言 我的

精选列表

搜索[翻译],共9354篇文章
优秀的个人博客,低调大师

翻译】split lock检测与处理

本文在解读 https://lwn.net/Articles/790464/ 的基础上,加入自己理解,与原文存在差异。 从地址不对齐访问到split lock Intel CPU微架构允许不对齐的内存访问,但ARM、RISC-V等架构却不允许。在众多的不对齐中,一个特殊的场景是:原子操作的操作数(由于地址不对齐)跨越两个cache lines,Intel将之叫做split lock。它有两个特征: 原子操作,即汇编指令包含Lock前缀; 操作数地址不对齐,还跨越两个cache lines; 其实大部分吃瓜群众都不知道这个特性,但是它却对应用性能影响极大。最近,Intel工程师Fenghua Yu同学正在开发一组内核补丁,用于检测和处理split lock,现在已经发出了第8版code review。阿里巴巴在多年前就意识到split loc

优秀的个人博客,低调大师

[翻译]高阶Python一学就会

高阶Python一学就会 在前一篇文章中,我们学习了几个一般来说比较有用的Python语言的特性。 考虑到这篇文章是前一篇文章的续集,在这里我们进一步延伸一些显式使用装饰器的概念,我们并没有扰乱前一篇文章的内容。 装饰器 装饰器的概念展现了python领域内最漂亮和最强大的设计可能性之一,这不仅仅是在Python编程中,也在整个软件设计领域。本质上来说,装饰器就是一种包装,主要是想在不改变被包装的原代码的原则下,实现延伸代码功能性的目的。为了能让这个概念更清晰易懂,我们来从最基础的内容开始。 函数亦称为第一类对象 函数简单来说就是基于给定的自变量返回一个值。在python中,这些函数还有另外一种荣誉称号,叫作第一类对象。考虑到函数可以被像普通的对象一样被作为自变量传递,函数荣膺这项称号还真的是恰如其分。比如说,它们可以被作为自变量传递给其它函数,同时也可以被用做一个函数返回值。 作为自变量的函数 def greet(name): print ('Hello ' + name) def send_greetings(fun, name): fun(name) send_greetings(greet, 'John') 闭包函数 闭包函数是定义在其它函数内部的函数。这使得:闭包函数只有在其父函数被调用时才会被定义,或者说闭包函数的作用域仅存在于父函数内部,亦或者说闭包函数只是作为父函数的一个局域变量存在的。 def send_greetings(name): def greet_message(): return ‘Hello ‘ result = greet_message() + name print (result) send_greetings(‘John’) 从函数中返回函数 Python还允许你将一个函数作为返回值传给另一个函数。本质上来讲,我们只是将内部函数的引用传回以待后续的调用。 def classify(element): def even_number(): print ('Element is even.') def odd_number(): print ('Element is odd.') if element%2 == 0: return even_number else: return odd_number classify(2)() 装饰器 现在,有了上面所有这些基本概念的经验之后,我们来这些概念串起来组成一个完整的图像。 def my_decorator(fun): def wrapper(): print (‘Before calling the function…’) fun() print (‘After calling the function…’) return wrapper def say_hello(): print (‘Hello!’) say_hello = my_decorator(say_hello) 就是这样!!! 这就是我们能得到的最简单的装饰器。我们把到前面学到的东西一个个的都用进来了。所以装饰器其实就是 一个把另一个函数作为自变量的函数,它生成了一个新的函数,同时对原先的函数扩展了功能性,它最终返回的是生成的新的函数,这样我们可以在其他地方使用它。 另外,python让编程者可以非常整洁漂亮地创建并使用装饰器。 def my_decorator(fun): def wrapper(): print (‘Before calling the function…’) fun() print (‘After calling the function…’) return wrapper @my_decorator def say_hello(): print (‘Hello!’) 上下文环境管理 简单来说吧,上下文管理是一种资源的获取和释放机制,它避免了资源泄露并确保即使在遇到一些糟糕的异常情况后仍能完成恰当的清理工作。比如说,保证文件在打开之后的关闭,锁在获得之后的释放。这个概念在大量其他编程语言中有清楚地表述和恰当地使用,比如说C++ 中的RAII。 技术上来说,它是一个对象需要去遵循的通讯协议。这个协议要求,对象要像一个上下文管理器一样,要执行 __enter__ 和 __exit__ 方法。 __enter__ 返回要被管理的资源,而 __exit__ 完成任何可能出现的清理工作并且什么也不返回。 class File: def __init__(self, name): self.name = name def __enter__(self): self.file = open(self.name, 'w') return self.file def __exit__(self, type, value, trace_back): if self.file: self.close() 现在,上面这个类可以在with语句中被安全地使用。更一般地,使用with,我们可以调用任何东西并返回一个上下文管理器。 with File('example.txt') as f: f.write('Hey hello') f.write('See you later. Bye!!!') __enter__在with语句被调用的时候被执行。当代码块的语句执行完了的时候 __exit__ 方法会被调用。 上下文管理器还可以被用在更复杂的问题中。我们看另一个上下文管理器几乎不可避免的例子。这个问题中的资源就是锁,我们可以避免的问题就是死锁。 from threading import Lock lock = Lock() def do_something(): lock.acquire() raise Exception('Oops I am sorry. I have to raise it!') lock.release() try: do_something() except: print ('Got an exception.') 注意,在释放锁之前会报异常。这会导致一个明显的副作用,那就是所有调用do_something的其它线程会永远地出现拥堵从而导致系统死锁。使用上下文管理器,我们可以避免这种尴尬的情况。 from threading import Lock lock = Lock() def do_something(): with lock: raise Exception('Oops I am sorry. I have to raise it!') try: do_something() except: print ('Got an exception.') 哇塞!看到没,即使遇到一些异常情况,代码也能恰当地完成清理工作。很明显,在任何可能的情况下都不会出现使用了上下文管理器来获得锁,而还没有释放锁就结束的情形。它就应该是这样。 连锁的异常 设想一种情况,因为除以零而使得方法抛出ZeroDivisionError的异常。显然,在python中我们有很好的一组工具能够来处理异常。然而,如果异常的原因是因为这个函数所调用的一些其它函数中出现了TypeError呢。仅仅报告最顶层的异常是不够,这样我们会丢失原始的异常信息和一连串异常的主要原因。 为了演示这个问题中的概念,我们举个简单的例子。 def chained_exceptions(): try: raise ValueError(17) except Exception as ex: raise ValueError(23) from ex if __name__ == "__main__": chained_exceptions() 在python 2.0中,上述情况会导致后面的异常被抛出而前面的会丢失,像下面这样。 Traceback (most recent call last): File “test.py”, line 3, in chained_exceptions raise ValueError(23) ValueError: 23 很明显,我们丢失了信息中有价值的那部分,因为我们丢失了异常导致的真正的起因。然而,在python3.0中运行同样的脚本,我们可以看到完整的异常栈跟踪的信息。 Traceback (most recent call last): File “test.py”, line 3, in chained_exceptions raise ValueError(17) ValueError: 17 The above exception was the direct cause of the following exception: Traceback (most recent call last): File “test.py”, line 8, in <module> chained_exceptions() File “test.py”, line 5, in chained_exceptions raise ValueError(23) from ex ValueError: 23 如果对您对本文的内容有任何的修改或者改进的意见,请在评论中让我看到。(原文链接:https://medium.com/quick-code/advanced-python-made-easy-2-d5a7ffb4e658)

优秀的个人博客,低调大师

翻译】Awesome Asyncio 中文版

本文来自云栖社区官方钉群“Python技术进阶”,了解相关信息可以关注“Python技术进阶”。 Python Asyncio 精选资源列表,囊括了网络框架,库,软件等资源。 Awesome-asyncio是 Timo Furrer 发起并维护的 Python Asyncio 资源列表。本项目是其中文版,在这里,收集了大量的 Asyncio 的最棒、最新的资源,供大家探索 Python 异步编程世界。 Python 3.4 引入了 Asyncio 模块作为标准库,通过协程、多路 I/O 访问 Socket 和其他资源来编写单线程并发代码,并在网络客户端与服务器上运行。Asyncio 内置了对异步 I/O 的支持,其编程模型类似于消息循环,从 Asyncio 模块可以直接获取 EventLoop 引用,再把需要执行的协程放到 EventL

优秀的个人博客,低调大师

RocketMQ如何支持更多队列(翻译

简述 Kafka是一个分布式流处理平台,它诞生自日志聚合案例。它不需要太高的并发性。在阿里的大规模案例中,我们发现原始模式不能满足我们的事件需求。因此,我们开发了一个名为RocketMQ的消息中间件,来解决更广泛的使用场景,从传统的发布/订阅情景到超大容量的不容忍消息丢失的事物系统。现在,在阿里,RocketMQ集群每天处理超过5000亿次事件,为3000多核心应用提供服务。 kafka的分区设计 生产者的并行写受分区数量的限制。 消费者的消费并行级别同样受到消费分区数量的限制。假设最大分区数量是20,当前消费中的消费者最大数量也只能是20. 每个主题由固定数量的分区组成。分区数量决定单个broker可能拥有的最大主题数,而不会显著的影响性能。 更多详情请参考这里 为什么Kafka不支持更多分区 每个分区都存储着所有的消息数据。尽管每个分区都按照顺序写盘,但随着并发写入分区的数量增加,从操作系统层面来说,写入就变的随机。 由于数据文件的分散,使用Linux IO组提交机制会比较困难。 Rocket如何支持更多分区? 所有的消息数据存储在提交日志文件。所有的写操作都是完全有序的,而读操作是随机的。 消费队列存储用户实际消费位置信息,这些消息也可以以顺序方式刷到磁盘。 优势 每个消息队列都是轻量级的,并且包含有限的元数据。 访问磁盘是完全按序的,这也会避免磁盘锁的争夺,当大量队列被创建也不会引发高磁盘IO等待。 劣势 消息消费会首先读取消费队列,然后是提交日志。这个过程将会带来一定的成本,在最坏的情况下。 提交日志和消费队列需要保证逻辑一致,这将会给编程模型带来额外的复制性。 动机 随机读。尽可能多的读取以提高页面缓存的命中率,减少读取IO操作。因此大容量内存依然是更可取的。如果大量消息堆积,读性能会不会下降很严重?答案是否定的,理由如下: 1,即使消息的大小只有1KB,系统也会提前读取更多数据。这意味着后续数据的读取,这将访问主存储器,而不是缓慢的磁盘IO读取。 2,从磁盘随机访问提交日志。在SSD情况下将I/O调动程序设置为NOOP,读qps将显著提速,这样会比电梯调度算法更快。 鉴于消费队列仅保存固定大小的元数据,主要用来记录消费进度,因此会很好的支持随机读。拥有页面缓存预取的优势,访问消费队列同访问主内存一样快,即使在大量消息堆积的情况下。作为结果,消费队列不会对读性能带来明显的损失。 提交日志保存几乎所有的信息,包括消息数据。类似关系数据库的重做日志,只要提交日志存在,消费队列,消息健索引和所有其他所需数据都能被完全恢复。

优秀的个人博客,低调大师

计算与推断思维 翻译完成

面向(未来的)数据科学家的入门课来咯~ 前一半讲 Python 编程,后一半讲统计学基本概念并用 Python 模拟。 Github:https://github.com/Kivy-CN/data8-textbook-zh Gitee:https://gitee.com/wizardforcel/data8-textbook-zh 电子书还没生成好,由于存在 SVG 图片,工具会报错,在线和本地都没办法。 赞助我 KivyCN 学习资源 Think Python 中文第二版 UCB CS61a 教材:SICP Python Tutorialspoint NumPy 教程 Matplotlib 用户指南 斯坦福 CS229 机器学习中文讲义 Duke STA663 计算统计学中文讲义 笨办法学 Python · 续 笨办法学 Linux 数据结构思维 写给人类的机器学习 UCB Data8 教材:计算与推断思维

优秀的个人博客,低调大师

Linux 小知识翻译 - 「架构」(arch)

这次,聊聊「架构」这个术语。 在PC相关的文档中,是不是经常看到「x86架构」这个短句。但是对于这句话,是不是总感到有种似懂非懂的感觉。 架构的英语是「architecture」。这里面有「建筑」,「建筑风格」,「构造」的意思。实际上架构这个词在很多领域中都有「构造」的意思。 其实,即使在电脑的世界里,「架构」也有被用在多种场合。软件设计中会使用「架构」这个术语,硬件中也会使用「架构」这个术语。 使用时会涉及到多个方面,很难用一句话来概括「架构」的意思,但基本含有之前提到的「构造」,「设计风格」的意思。 那么,「x86架构」指的又是什么呢?「x86」是被称为电脑的头脑的CPU的一种。 所以,说「x86架构」的时候,就是指以 x86 CPU为核心的各种硬件的组合。 总之,只有CPU的话电脑是无法运行的,根据CPU的不同,硬件(使用什么样主板好呢?使用什么样的内存好呢?等等)的构成也会变化。 把和CPU相关的硬件的全体被称为「架构」,这样来考虑可能比较好。 (硬件)架构这个术语产生的理由是因为软件会「根据硬件架构的不同而改变」。即,同样的软件,可能在某些架构上能运行,其他架构上则不能运行或者运行的不好。 为了防止这种事情,有必要掌握使用软件的电脑的架构是什么样的。 标签: linux 本文转自wang_yb博客园博客,原文链接:http://www.cnblogs.com/wang_yb/p/3796348.html,如需转载请自行联系原作者

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册