Pub Date : 2018-11-01DOI: 10.1109/candar.2018.00007
A. Bailly
s of Contributed Talks Program Size: A Call for Inquiry Lucas Bang Harvey Mudd College, USA bang@cs.hmc.edu Size is a fundamental program characteristic that has deep implications for the phenomenological experience and in uence of computer code. Program size has a paradoxically rich yet sparse theoretical history that deserves closer examination. Here, I highlight the importance of program size, using a relatively obscure size theorem of Blum [1] as a beacon, and discuss the relevance of program size on the past, present, and future of programming. Theory in Praxis. Programmers are typically familiar with several foundational results in theoretical computer science and these results show up with varying frequency in the day-to-day experience of most people who regularly write code. A few examples will help illustrate. Ideas like undecidability, incomputability, and incompleteness [6, 17, 3] are required topics in many computer science programs, but it is not common to take them into practical consideration while performing routine software development tasks. Slightly more consideration-worthy on a regular basis is the notion of complexity classes, notably NP-completness [10]. It is indeed the case that the ability to recognize NPcomplete problems can have a real impact on programmers, users, and others a ected by solutions to scheduling, planning, routing, and optimization programs. Even more common are the considerations for algorithmic space and time complexity [5]; programming almost always accounts for memory and time e ciency. Finally, program correctness [12] is of utmost concern; by some accounts, programmers spend 35-50% of their time validating code [2]. If you have experience programming, I would encourage you to re ect on how relative frequency with which you have taken each of these facets of theoretical computer science into account while coding. I claim that the degree to which we consider theoretical areas of computing (e.g. each of the the aforementioned computability, complexity classes, algorithmic complexity, and correctness) in our daily lives is proportional to the potential for phenomenological discomfort caused by not taking them into consideration. I support this claim through the lens of Heidegger's ready-to-hand and present-at-hand framework [8]. Further, I claim that program size is indeed of the utmost importance to the daily activity of programming and to the e ect that programs have on society. Abstractions are born, to some degree, in order to manage program size complexity. When an abstraction does not behave as expected, the programmer shifts from a state of ready-at-hand to present-at-hand in the face of large programs. Yet, there does not currently exist a common familiarity with theoretical results related to program size providing a vocabulary that a ords re ection or communication about such concerns. Remember Not To Forget. Among theoreticians, Kolmogorov Complexity, is well-know. For a string s, the Kolmog
Lucas Bang Harvey Mudd学院,美国bang@cs.hmc.edu规模是一个基本的程序特征,它对现象学经验和计算机代码的影响有着深刻的影响。程序大小有一个矛盾的丰富而稀疏的理论历史,值得更仔细地研究。在这里,我强调程序大小的重要性,使用Blum[1]的一个相对模糊的大小定理作为灯塔,并讨论程序大小与编程的过去、现在和未来的相关性。理论与实践。程序员通常熟悉理论计算机科学中的几个基本结果,这些结果在大多数经常编写代码的人的日常经验中以不同的频率出现。几个例子将有助于说明。不可判定性、不可计算性和不完全性[6,17,3]等概念是许多计算机科学程序中必需的主题,但是在执行常规软件开发任务时将它们纳入实际考虑并不常见。在常规基础上稍微值得考虑的是复杂度类的概念,特别是np完备性[10]。事实上,识别非完全性问题的能力对程序员、用户和其他受调度、计划、路由和优化程序解决方案影响的人有真正的影响。更常见的是对算法空间和时间复杂度的考虑[5];编程几乎总是考虑到内存和时间效率。最后,程序的正确性[12]是最重要的;根据一些统计,程序员花费35-50%的时间来验证代码[2]。如果您有编程经验,我会鼓励您在编码时考虑到理论计算机科学的每个方面的相对频率。我认为,我们在日常生活中考虑计算理论领域(例如前面提到的每一个可计算性、复杂性类、算法复杂性和正确性)的程度,与不考虑它们而导致的现象学不适的可能性成正比。我通过海德格尔的现成(ready-to-hand)和现在-在手(present-at-hand)框架来支持这一主张[8]。此外,我认为程序的大小对于编程的日常活动和程序对社会的影响确实是至关重要的。在某种程度上,抽象的诞生是为了管理程序大小的复杂性。当抽象的行为不像预期的那样时,程序员在面对大型程序时就会从现成的状态转变为现成的状态。然而,目前还没有一个普遍熟悉的与程序大小相关的理论结果,提供一个词汇表来反映或交流这些问题。记住不要忘记。在理论家中,柯尔莫哥洛夫复杂性是众所周知的。对于字符串s, s的Kolmogorov复杂度是在不提供输入的情况下,通用编程语言中输出s的最小程序的大小[11]。不太为人所知,但我认为与日常程序员经验更相关的是Blum的大小定理,它并不像第一眼看到的那么简单[1]。布卢姆大小定理(1967)。设φi为递归函数的标度,g为无界递归函数,f为任意递归函数。我们可以让指标i, j∈N使得φi = φg(i)且f(|i|) < |g(j)|,即φg(i)的大小任意大于φi的大小,尽管它们计算的是同一个函数。在Robert Harper的《编程语言的实用基础》[7]和一篇博客文章《老的被忽视的定理仍然是定理》中,他简要但清楚地阐明了Blum大小定理的结果:对于一个编程系统,你可以保证能够确定地知道任何程序的行为(例如停止),对于特定的问题,最小的解决方案是一个不可思议的大程序。作为这一事实的具体例子,Harper指出了用于计算两个自然数的最大公约数的欧几里得算法(可能是几行Python)。在受限的编程系统system T中,编写GCD很快变得相当笨拙,因为所有程序都保证收敛。我个人可以证明我曾经这样做过,这确实是相当痛苦的,而且这个项目变得相当大。https://existentialtype.wordpress.com/2014/03/20/old-neglected-theorems-are-still-theorems/
{"title":"Program Committee","authors":"A. Bailly","doi":"10.1109/candar.2018.00007","DOIUrl":"https://doi.org/10.1109/candar.2018.00007","url":null,"abstract":"s of Contributed Talks Program Size: A Call for Inquiry Lucas Bang Harvey Mudd College, USA bang@cs.hmc.edu Size is a fundamental program characteristic that has deep implications for the phenomenological experience and in uence of computer code. Program size has a paradoxically rich yet sparse theoretical history that deserves closer examination. Here, I highlight the importance of program size, using a relatively obscure size theorem of Blum [1] as a beacon, and discuss the relevance of program size on the past, present, and future of programming. Theory in Praxis. Programmers are typically familiar with several foundational results in theoretical computer science and these results show up with varying frequency in the day-to-day experience of most people who regularly write code. A few examples will help illustrate. Ideas like undecidability, incomputability, and incompleteness [6, 17, 3] are required topics in many computer science programs, but it is not common to take them into practical consideration while performing routine software development tasks. Slightly more consideration-worthy on a regular basis is the notion of complexity classes, notably NP-completness [10]. It is indeed the case that the ability to recognize NPcomplete problems can have a real impact on programmers, users, and others a ected by solutions to scheduling, planning, routing, and optimization programs. Even more common are the considerations for algorithmic space and time complexity [5]; programming almost always accounts for memory and time e ciency. Finally, program correctness [12] is of utmost concern; by some accounts, programmers spend 35-50% of their time validating code [2]. If you have experience programming, I would encourage you to re ect on how relative frequency with which you have taken each of these facets of theoretical computer science into account while coding. I claim that the degree to which we consider theoretical areas of computing (e.g. each of the the aforementioned computability, complexity classes, algorithmic complexity, and correctness) in our daily lives is proportional to the potential for phenomenological discomfort caused by not taking them into consideration. I support this claim through the lens of Heidegger's ready-to-hand and present-at-hand framework [8]. Further, I claim that program size is indeed of the utmost importance to the daily activity of programming and to the e ect that programs have on society. Abstractions are born, to some degree, in order to manage program size complexity. When an abstraction does not behave as expected, the programmer shifts from a state of ready-at-hand to present-at-hand in the face of large programs. Yet, there does not currently exist a common familiarity with theoretical results related to program size providing a vocabulary that a ords re ection or communication about such concerns. Remember Not To Forget. Among theoreticians, Kolmogorov Complexity, is well-know. For a string s, the Kolmog","PeriodicalId":125849,"journal":{"name":"2020 IEEE/ACM 13th International Conference on Utility and Cloud Computing (UCC)","volume":"26 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2018-11-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"133884996","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Pub Date : 2017-09-14DOI: 10.1109/ICCCN.2017.8038352
Song Fu, Abhishek Parakh
Novel scalable scientific algorithms are needed in order to enable key science applications to exploit the computational power of large-scale systems. This is especially true for the current tier of leading petascale machines and the road to exascale computing as high-performance computing (HPC) systems continue to scale up in compute node and processor core count. These extreme-scale systems require novel scientific algorithms to hide network and memory latency, have very high computation/communication overlap, have minimal communication, and have no synchronization points. Scientific algorithms for multi-petaflop and exa-flop systems also need to be fault tolerant and fault resilient, since the probability of faults increases with scale. Resilience at the system software and at the algorithmic level is needed as a crosscutting effort. Finally, with the advent of heterogeneous compute nodes that employ standard processors as well as general-purpose computing graphics processing units (GPGPUs), scientific algorithms need to match these architectures to extract the most performance. This includes different system-specific levels of parallelism as well as co-scheduling of computation. Key science applications require novel mathematical models and system software that address the scalability and resilience challenges of current- and future-generation extreme-scale HPC systems. The goal of this workshop is to bring together experts in the area of scalable algorithms to present the latest achievements and to discuss the challenges ahead.
{"title":"Message from the Workshop Chairs","authors":"Song Fu, Abhishek Parakh","doi":"10.1109/ICCCN.2017.8038352","DOIUrl":"https://doi.org/10.1109/ICCCN.2017.8038352","url":null,"abstract":"Novel scalable scientific algorithms are needed in order to enable key science applications to exploit the computational power of large-scale systems. This is especially true for the current tier of leading petascale machines and the road to exascale computing as high-performance computing (HPC) systems continue to scale up in compute node and processor core count. These extreme-scale systems require novel scientific algorithms to hide network and memory latency, have very high computation/communication overlap, have minimal communication, and have no synchronization points. Scientific algorithms for multi-petaflop and exa-flop systems also need to be fault tolerant and fault resilient, since the probability of faults increases with scale. Resilience at the system software and at the algorithmic level is needed as a crosscutting effort. Finally, with the advent of heterogeneous compute nodes that employ standard processors as well as general-purpose computing graphics processing units (GPGPUs), scientific algorithms need to match these architectures to extract the most performance. This includes different system-specific levels of parallelism as well as co-scheduling of computation. Key science applications require novel mathematical models and system software that address the scalability and resilience challenges of current- and future-generation extreme-scale HPC systems. The goal of this workshop is to bring together experts in the area of scalable algorithms to present the latest achievements and to discuss the challenges ahead.","PeriodicalId":125849,"journal":{"name":"2020 IEEE/ACM 13th International Conference on Utility and Cloud Computing (UCC)","volume":"28 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-09-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"131808981","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}