Wednesday, October 18, 2017
WatchFull Updated
WatchFull is a collection of programs, written in Perl, which assist Unix systems administrators in avoiding and responding to file system space exhaustion crises. WatchFull monitors file systems and reports when they fall below a specified percentage of free space. LogJam watches system and application log files (for example Web server access and error logs) and warns when they exceed a threshold size. Top40 scans a file system or directory tree and provides a list of the largest files within it. I have just posted the first update to WatchFull since its initial release in 2000. Version 1.1 updates the source code to current Perl syntax, corrects several warning messages, and now runs in “use strict;” and “use warnings;” modes. The source code should be compatible with any recent version of Perl 5. The HTML documentation has been updated to XHTML 1.0 Strict, CSS3, and Unicode typography. WatchFull Home PagePosted at
19:55
Monday, October 16, 2017
New: Marinchip Systems: Documents and Images
I have just posted an archive of documents and images about Marinchip Systems, the company I founded and operated from 1977 through 1985. Marinchip delivered, starting in 1978, the first true 16-bit personal computer on the S-100 bus, with the goal of providing its users the same experience as conecting to a commercial timesharing service which cost many times more. While other personal computer companies were providing 8 Kb BASIC, we had a Unix-like operating system, Pascal, and eventually a multi-user system.
Marinchip (which was named after the Marinship shipyard not far from where I lived, which made Liberty ships during World War II), designed its own hardware and software, with hardware based upon the Texas Instruments TMS9900 microprocessor and the software written by, well, me.
Texas Instruments (TI) in this era was a quintessential engineering company: “Hey, we've designed something cool. Let's go design something else, entirely different, which is even cooler!” There didn't seem to be anybody who said, “No, first you need to offer follow-on products which allow those who bet on your original product to evolve and grow as technology advances.” TI built a supercomputer, the TI-ASC, at the time one of the fastest in the world, but then they lost interest in it and sold only seven.
The Marinchip 9900 did somewhat better, although its performance and unit cost were more modest. Hughes Radar Systems designed our board into the F-16 radar tester and bought the boards in large quantities for this embedded application. The 9900 processor was one of the only 16-bit processors qualified for use in geosynchronous satellites, and we sold a number of systems to satellite manufacturers for software development because our systems cost a fraction of those sold by Texas Instruments. In 1985, after Autodesk took off, and I had no more time for Marinchip, I sold the company, with all of its hardware, software, and manufacturing rights to Hughes Electronics which had, by then, been acquired by General Motors, so I said, “I sold my company to General Motors”.
What can you learn from this? Probably not a heck of a lot. Certainly, I learned little. I repeated most of my mistakes from Marinchip in Autodesk, and only learned later, from experience, that there are things which work at one scale which don't when the numbers are ten or a hundred times larger. Still, if you haven't seen personal computing as it existed while Jimmy Carter was the U.S. president, take a glance. As far as I know, nothing we did at Marinchip contributed in any way to our current technology. Well, almost nothing. There was this curious drafting program one of our customers developed which was the inspiration for AutoCAD…. Marinchip Systems: Documents and Images
Posted at
19:15
Wednesday, October 11, 2017
Reading List: The Planet Remade
- Morton, Oliver. The Planet Remade. Princeton: Princeton University Press, 2015. ISBN 978-0-691-17590-4.
-
We live in a profoundly unnatural world. Since the start of the
industrial revolution, and rapidly accelerating throughout the
twentieth century, the actions of humans have begun to influence
the flow of energy and materials in the Earth's biosphere on a
global scale. Earth's current human population and standard of
living are made possible entirely by industrial production of
nitrogen-based fertilisers and crop plants bred to efficiently
exploit them. Industrial production of fixed (chemically
reactive) nitrogen from the atmosphere now substantially exceeds
all of that produced by the natural soil bacteria on the planet
which, prior to 1950, accounted for almost all of the nitrogen
required to grow plants. Fixing nitrogen by the Haber-Bosch
process is energy-intensive, and consumes around 1.5 percent
of all the world's energy usage and, as a feedstock, 3–5%
of natural gas produced worldwide. When we eat these crops, or
animals fed from them, we are, in a sense, eating fossil fuels.
On the order of four out of five nitrogen molecules that make up
your body were made in a factory by the Haber-Bosch process. We
are the children, not of nature, but of industry.
The industrial production of fertiliser, along with crops
tailored to use them, is entirely responsible for the rapid
growth of the Earth's population, which has increased from around
2.5 billion in 1950, when industrial fertiliser and
“green revolution” crops came into wide use, to
more than 7 billion today. This was accompanied not by the collapse
into global penury predicted by Malthusian doom-sayers,
but rather a broad-based rise in the standard of living, with
extreme poverty and malnutrition falling to all-time
historical lows. In the lifetimes of many people, including
this scribbler, our species has taken over the flow of nitrogen
through the Earth's biosphere, replacing a process mediated by
bacteria for billions of years with one performed in factories.
The flow of nitrogen from atmosphere to soil, to plants and
the creatures who eat them, back to soil, sea, and ultimately
the atmosphere is now largely in the hands of humans, and
their very lives have become dependent upon it.
This is an example of “geoengineering”—taking
control of what was a natural process and replacing it with
an engineered one to produce a desired outcome: in this case,
the ability to feed a much larger population with an
unprecedented standard of living. In the case of nitrogen
fixation, there wasn't a grand plan drawn up to do all of this:
each step made economic sense to the players involved. (In fact,
one of the motivations for developing the Haber-Bosch process was
not to produce fertiliser, but rather to produce feedstocks for
the manufacture of military and industrial explosives, which had
become dependent on nitrates obtained from guano imported to
Europe from South America.) But the outcome was the same: ours
is an engineered world. Those who are repelled by such an
intervention in natural processes or who are concerned by
possible detrimental consequences of it, foreseen or
unanticipated, must come to terms with the reality that
abandoning this world-changing technology now would result in
the collapse of the human population, with at least half of
the people alive today starving to death, and many of the
survivors reduced to subsistence in abject poverty. Sadly, one
encounters fanatic “greens” who think this would be
just fine (and, doubtless, imagining they'd be among the
survivors).
Just mentioning geoengineering—human intervention and
management of previously natural processes on a global
scale—may summon in the minds of many Strangelove-like
technological megalomania or the hubris of Bond villains,
so it's important to bear in mind that we're already
doing it, and have become utterly dependent upon it.
When we consider the challenges we face in accommodating
a population which is expected to grow to ten billion by
mid-century (and, absent catastrophe, this is almost a
given: the parents of the ten billion are mostly alive
today), who will demand and deserve a standard of living
comparable to what they see in industrial economies, and
while carefully weighing the risks and uncertainties involved,
it may be unwise to rule out other geoengineering interventions
to mitigate undesirable consequences of supporting the
human population.
In parallel with the human takeover of the nitrogen cycle,
another geoengineering project has been underway, also
rapidly accelerating in the 20th century, driven both by
population growth and industrialisation of previously
agrarian societies. For hundreds of millions of years, the Earth
also cycled carbon through the atmosphere, oceans, biosphere,
and lithosphere. Carbon dioxide (CO₂) was metabolised
from the atmosphere by photosynthetic plants, extracting carbon for their
organic molecules and producing oxygen released to the atmosphere, then
passed along as plants were eaten, returned to the soil,
or dissolved in the oceans, where creatures incorporated
carbonates into their shells, which eventually became limestone
rock and, over geological time, was subducted as the
continents drifted, reprocessed far below the surface, and
expelled back into the atmosphere by volcanoes. (This is a
gross oversimplification of the
carbon cycle,
but we don't need to go further into it for what follows. The
point is that it's something which occurs on a time scale of
tens to hundreds of millions of years and on which humans, prior
to the twentieth century, had little influence.)
The natural carbon cycle is not leakproof. Only part of the
carbon sequestered by marine organisms and immured in limestone
is recycled by volcanoes; it is estimated that this loss of
carbon will bring the era of multicellular life on Earth to an
end around a billion years from now. The carbon in some plants
is not returned to the biosphere when they die. Sometimes, the
dead vegetation accumulates in dense beds where it is protected
against oxidation and eventually forms deposits of peat, coal,
petroleum, and natural gas. Other than natural seeps and
releases of the latter substances, their carbon is also largely
removed from the biosphere. Or at least it was until those
talking apes came along….
The modern technological age has been powered by the exploitation of these fossil fuels: laid down over hundreds of millions of years, often under special conditions which only existed in certain geological epochs, in the twentieth century their consumption exploded, powering our present technological civilisation. For all of human history up to around 1850, world energy consumption was less than 20 exajoules per year, almost all from burning biomass such as wood. (What's an exajoule? Well, it's 1018 joules, which probably tells you absolutely nothing. That's a lot of energy: equivalent to 164 million barrels of oil, or the capacity of around sixty supertankers. But it's small compared to the energy the Earth receives from the Sun, which is around 4 million exajoules per year.) By 1900, the burning of coal had increased this number to 33 exajoules, and this continued to grow slowly until around 1950 when, with oil and natural gas coming into the mix, energy consumption approached 100 exajoules. Then it really took off. By the year 2000, consumption was 400 exajoules, more than 85% from fossil fuels, and today it's more than 550 exajoules per year.
Now, as with the nitrogen revolution, nobody thought about this as geoengineering, but that's what it was. Humans were digging up, or pumping out, or otherwise tapping carbon-rich substances laid down long before their clever species evolved and burning them to release energy banked by the biosystem from sunlight in ages beyond memory. This is a human intervention into the Earth's carbon cycle of a magnitude even greater than the Haber-Bosch process into the nitrogen cycle. “Look out, they're geoengineering again!” When you burn fossil fuels, the combustion products are mostly carbon dioxide and water. There are other trace products, such as ash from coal, oxides of nitrogen, and sulphur compounds, but other than side effects such as various forms of pollution, they don't have much impact on the Earth's recycling of elements. The water vapour from combustion is rapidly recycled by the biosphere and has little impact, but what about the CO₂? Well, that's interesting. CO₂ is a trace gas in the atmosphere (less than a fiftieth of a percent), but it isn't very reactive and hence doesn't get broken down by chemical processes. Once emitted into the atmosphere, CO₂ tends to stay there until it's removed via photosynthesis by plants, weathering of rocks, or being dissolved in the ocean and used by marine organisms. Photosynthesis is an efficient consumer of atmospheric carbon dioxide: a field of growing maize in full sunlight consumes all of the CO₂ within a metre of the ground every five minutes—it's only convection that keeps it growing. You can see the yearly cycle of vegetation growth in measurements of CO₂ in the atmosphere as plants take it up as they grow and then release it after they die. The other two processes are much slower. An increase in the amount of CO₂ causes plants to grow faster (operators of greenhouses routinely enrich their atmosphere with CO₂ to promote growth), and increases the root to shoot ratio of the plants, tending to remove CO₂ from the atmosphere where it will be recycled more slowly into the biosphere. But since the start of the industrial revolution, and especially after 1950, the emission of CO₂ by human activity over a time scale negligible on the geological scale by burning of fossil fuels has released a quantity of carbon into the atmosphere far beyond the ability of natural processes to recycle. For the last half billion years, the CO₂ concentration in the atmosphere has varied between 280 parts per million in interglacial (warm periods) and 180 parts per million during the depths of the ice ages. The pattern is fairly consistent: a rapid rise of CO₂ at the end of an ice age, then a slow decline into the next ice age. The Earth's temperature and CO₂ concentrations are known with reasonable precision in such deep time due to ice cores taken in Greenland and Antarctica, from which temperature and atmospheric composition can be determined from isotope ratios and trapped bubbles of ancient air. While there is a strong correlation between CO₂ concentration and temperature, this doesn't imply causation: the CO₂ may affect the temperature; the temperature may affect the CO₂; they both may be caused by another factor; or the relationship may be even more complicated (which is the way to bet). But what is indisputable is that, as a result of our burning of all of that ancient carbon, we are now in an unprecedented era or, if you like, a New Age. Atmospheric CO₂ is now around 410 parts per million, which is a value not seen in the last half billion years, and it's rising at a rate of 2 parts per million every year, and accelerating as global use of fossil fuels increases. This is a situation which, in the ecosystem, is not only unique in the human experience; it's something which has never happened since the emergence of complex multicellular life in the Cambrian explosion. What does it all mean? What are the consequences? And what, if anything, should we do about it? (Up to this point in this essay, I believe everything I've written is non-controversial and based upon easily-verified facts. Now we depart into matters more speculative, where squishier science such as climate models comes into play. I'm well aware that people have strong opinions about these issues, and I'll not only try to be fair, but I'll try to stay away from taking a position. This isn't to avoid controversy, but because I am a complete agnostic on these matters—I don't think we can either measure the raw data or trust our computer models sufficiently to base policy decisions upon them, especially decisions which might affect the lives of billions of people. But I do believe that we ought to consider the armanentarium of possible responses to the changes we have wrought, and will continue to make, in the Earth's ecosystem, and not reject them out of hand because they bear scary monikers like “geoengineering”.) We have been increasing the fraction of CO₂ in the atmosphere to levels unseen in the history of complex terrestrial life. What can we expect to happen? We know some things pretty well. Plants will grow more rapidly, and many will produce more roots than shoots, and hence tend to return carbon to the soil (although if the roots are ploughed up, it will go back to the atmosphere). The increase in CO₂ to date will have no physiological effects on humans: people who work in greenhouses enriched to up to 1000 parts per million experience no deleterious consequences, and this is more than twice the current fraction in the Earth's atmosphere, and at the current rate of growth, won't be reached for three centuries. The greatest consequence of a growing CO₂ concentration is on the Earth's energy budget. The Earth receives around 1360 watts per square metre on the side facing the Sun. Some of this is immediately reflected back to space (much more from clouds and ice than from land and sea), and the rest is absorbed, processed through the Earth's weather and biosphere, and ultimately radiated back to space at infrared wavelengths. The books balance: the energy absorbed by the Earth from the Sun and that it radiates away are equal. (Other sources of energy on the Earth, such as geothermal energy from radioactive decay of heavy elements in the Earth's core and energy released by human activity are negligible at this scale.) Energy which reaches the Earth's surface tends to be radiated back to space in the infrared, but some of this is absorbed by the atmosphere, in particular by trace gases such as water vapour and CO₂. This raises the temperature of the Earth: the so-called greenhouse effect. The books still balance, but because the temperature of the Earth has risen, it emits more energy. (Due to the Stefan-Boltzmann law, the energy emitted from a black body rises as the fourth power of its temperature, so it doesn't take a large increase in temperature [measured in degrees Kelvin] to radiate away the extra energy.) So, since CO₂ is a strong absorber in the infrared, we should expect it to be a greenhouse gas which will raise the temperature of the Earth. But wait—it's a lot more complicated. Consider: water vapour is a far greater contributor to the Earth's greenhouse effect than CO₂. As the Earth's temperature rises, there is more evaporation of water from the oceans and lakes and rivers on the continents, which amplifies the greenhouse contribution of the CO₂. But all of that water, released into the atmosphere, forms clouds which increase the albedo (reflectivity) of the Earth, and reduce the amount of solar radiation it absorbs. How does all of this interact? Well, that's where the global climate models get into the act, and everything becomes very fuzzy in a vast panel of twiddle knobs, all of which interact with one another and few of which are based upon unambiguous measurements of the climate system. Let's assume, arguendo, that the net effect of the increase in atmospheric CO₂ is an increase in the mean temperature of the Earth: the dreaded “global warming”. What shall we do? The usual prescriptions, from the usual globalist suspects, are remarkably similar to their recommendations for everything else which causes their brows to furrow: more taxes, less freedom, slower growth, forfeit of the aspirations of people in developing countries for the lifestyle they see on their smartphones of the people who got to the industrial age a century before them, and technocratic rule of the masses by their unelected self-styled betters in cheap suits from their tawdry cubicle farms of mediocrity. Now there's something to stir the souls of mankind! But maybe there's an alternative. We've already been doing geoengineering since we began to dig up coal and deploy the steam engine. Maybe we should embrace it, rather than recoil in fear. Suppose we're faced with global warming as a consequence of our inarguable increase in atmospheric CO₂ and we conclude its effects are deleterious? (That conclusion is far from obvious: in recorded human history, the Earth has been both warmer and colder than its present mean temperature. There's an intriguing correlation between warm periods and great civilisations versus cold periods and stagnation and dark ages.) How might we respond? Atmospheric veil. Volcanic eruptions which inject large quantities of particulates into the stratosphere have been directly shown to cool the Earth. A small fleet of high-altitude airplanes injecting sulphate compounds into the stratosphere would increase the albedo of the Earth and reflect sufficient sunlight to reduce or even cancel or reverse the effects of global warming. The cost of such a programme would be affordable by a benevolent tech billionaire or wannabe Bond benefactor (“Greenfinger”), and could be implemented in a couple of years. The effect of the veil project would be much less than a volcanic eruption, and would be imperceptible other than making sunsets a bit more colourful. Marine cloud brightening. By injecting finely-dispersed salt water from the ocean into the atmosphere, nucleation sites would augment the reflectivity of low clouds above the ocean, increasing the reflectivity (albedo) of the Earth. This could be accomplished by a fleet of low-tech ships, and could be applied locally, for example to influence weather. Carbon sequestration. What about taking the carbon dioxide out of the atmosphere? This sounds like a great idea, and appeals to clueless philanthropists like Bill Gates who are ignorant of thermodynamics, but taking out a trace gas is really difficult and expensive. The best place to capture it is where it's densest, such as the flue of a power plant, where it's around 10%. The technology to do this, “carbon capture and sequestration” (CCS) exists, but has not yet been deployed on any full-scale power plant. Fertilising the oceans. One of the greatest reservoirs of carbon is the ocean, and once carbon is incorporated into marine organisms, it is removed from the biosphere for tens to hundreds of millions of years. What constrains how fast critters in the ocean can take up carbon dioxide from the atmosphere and turn it into shells and skeletons? It's iron, which is rare in the oceans. A calculation made in the 1990s suggested that if you added one tonne of iron to the ocean, the bloom of organisms it would spawn would suck a hundred thousand tonnes of carbon out of the atmosphere. Now, that's leverage which would impress even the most jaded Wall Street trader. Subsequent experiments found the ratio to be maybe a hundred times less, but then iron is cheap and it doesn't cost much to dump it from ships. Great Mambo Chicken. All of the previous interventions are modest, feasible with existing technology, capable of being implemented incrementally while monitoring their effects on the climate, and easily and quickly reversed should they be found to have unintended detrimental consequences. But when thinking about affecting something on the scale of the climate of a planet, there's a tendency to think big, and a number of grand scale schemes have been proposed, including deploying giant sunshades, mirrors, or diffraction gratings at the L1 Lagrangian point between the Earth and the Sun. All of these would directly reduce the solar radiation reaching the Earth, and could be adjusted as required to manage the Earth's mean temperature at any desired level regardless of the composition of its atmosphere. Such mega-engineering projects are considered financially infeasible, but if the cost of space transportation falls dramatically in the future, might become increasingly attractive. It's worth observing that the cost estimates for such alternatives, albeit in the tens of billions of dollars, are small compared to re-architecting the entire energy infrastructure of every economy in the world to eliminate carbon-based fuels, as proposed by some glib and innumerate environmentalists. We live in the age of geoengineering, whether we like it or not. Ever since we started to dig up coal and especially since we took over the nitrogen cycle of the Earth, human action has been dominant in the Earth's ecosystem. As we cope with the consequences of that human action, we shouldn't recoil from active interventions which acknowledge that our environment is already human-engineered, and that it is incumbent upon us to preserve and protect it for our descendants. Some environmentalists oppose any form of geoengineering because they feel it is unnatural and provides an alternative to restoring the Earth to an imagined pre-industrial pastoral utopia, or because it may be seized upon as an alternative to their favoured solutions such as vast fields of unsightly bird shredders. But as David Deutsch says in The Beginning of Infinity, “Problems are inevitable“; but “Problems are soluble.” It is inevitable that the large scale geoengineering which is the foundation of our developed society—taking over the Earth's natural carbon and nitrogen cycles—will cause problems. But it is not only unrealistic but foolish to imagine these problems can be solved by abandoning these pillars of modern life and returning to a “sustainable” (in other words, medieval) standard of living and population. Instead, we should get to work solving the problems we've created, employing every tool at our disposal, including new sources of energy, better means of transmitting and storing energy, and geoengineering to mitigate the consequences of our existing technologies as we incrementally transition to those of the future.
Posted at
13:35
Tuesday, October 10, 2017
New: ISBNiser Utility
As I read and review lots of books, I frequently need to deal with International Standard Book Numbers (ISBNs) which, like many international standards, come in a rainbow of flavours, all confusing and some distasteful. There are old ISBN-10s, new ISBN-13s, the curious way in which ISBN-13s were integrated into EANs, “Bookland”, and its two islands, 978 legacy, which maps into ISBN-10, and 979, sparsely populated, which doesn't. Of course, these important numbers, which have been central to commerce in books since the 1970s and to Internet booksellers today, contain a check digit to guard against transcription and transposition errors and, naturally, the two flavours, ISBN-10 and ISBN-13 use entirely different algorithms to compute it, with the former working in base eleven, which even those of us who endured “new math” in the 1960s managed to evade. I've just published ISBNiser, a cleaned-up version of a program I've been using in house since 2008 to cope with all of this. It validates ISBNs in both the 10- and 13-digit formats, interconverts between them, and generates links to purchase the book cited at Amazon, on any Amazon national site, and optionally credits the purchase to your Amazon Associates account or an alternative account you can specify when configuring the program. You can specify ISBNs with or without delimiters among the digits, and with any (non-alphanumeric) delimiter you wish. If you're faced with an all-numeric ISBN as is becoming more common as publishers move down-market, you can put the hyphens back with the U.S. Library of Congress ISBN Converter, which will give you an ISBN-10 you can convert back to ISBN-13 with ISBNiser. ISBNiser Home PagePosted at
23:09
Sunday, October 8, 2017
The Hacker's Diet Online: Source Code Release Update
The Hacker's Diet Online has been in production at Fourmilab since July, 2007: more than ten years. It provides, in a Web application which can be accessed from any browser or mobile device with Web connectivity, a set of tools for planning, monitoring, and analysing the progress of a diet and subsequently maintaining a stable weight as described in my 1991 book The Hacker's Diet. The application was originally hosted on Fourmilab's local server farm, but as of January, 2016, Fourmilab's Web site has been hosted on Amazon Web Services (AWS). Due to changes in the server environment, a few modifications had to be made to the application, none of which are visible to the user. These changes were applied as “hot fixes” to the running code, and not integrated back into the master source code, which is maintained using the Literate Programming tool Nuweb. I have just completed this integration and posted an updated version of the published program (1.4 Mb PDF) and downloadable source code (2.7 Mb tar.gz). The code generated from this program is identical to that running on the server, with the exception of passwords, encryption keys, and other security-related information which have been changed for the obvious reasons. A complete list of the changes in this release appears in the change log at the end of the published program. The Hacker's Diet Online now has more than 30,000 open accounts, not counting completely inactive accounts which never posted any data after being opened, which are archived and purged every few years.Posted at
20:14
Monday, October 2, 2017
Floating Point Benchmark: JavaScript Language Updated
I have posted an update to my trigonometry-intense floating point benchmark which updates the benchmarks for JavaScript, last run in 2005. A new release of the benchmark collection including the updated JavaScript benchmark is now available for downloading. This JavaScript benchmark was originally developed in 2005 and browser timing tests were run in 2005 and 2006. At the time, most implementations of JavaScript were pure interpreters or interpreters of a byte-code representation, and their performance reflected this. With the run time of the C benchmark taken as 1, JavaScript ran anywhere from 27.6 (Opera 8.0) to 46.9 (Mozilla Firefox 1.0.6) times slower. What a difference a decade makes! The JavaScript engines in the leading modern browsers use optimisation and techniques such as just-in-time compilation to deliver performance which is often competitive with languages that compile to machine code. This is what permitted me to re-implement Cellular Automata Laboratory as an application which ran entirely within the browser, eliminating the need for a separate programming language environment. Having observed how well JavaScript performed in that project, it was clear that the time had come to revisit the language and compare contemporary implementations with C. The benchmark is essentially unchanged from the one run in 2005. I have added some declarations of variables to make the code compliant with "use strict", added some comments to the code, and included a main program which allows the benchmark to run from the command line under node.js, but there are no changes to the code which is timed when running the benchmark. Comparisons to the execution time of the C benchmark were made against a version compiled with GCC 5.4.0. A recent release of the mathematical function library for GCC appears to have dramatically slowed down the trigonometric functions, apparently in the interest of last-bit accuracy, perhaps by as much as a factor of two compared to previous libraries. That should be kept in mind when considering the comparisons with JavaScript implementations. The change to the C library trigonometric functions made no difference in the results computed by the benchmark, which are verified to 13 significant digits. A variety of JavaScript engines are used by current browsers. One would expect that performance in a JavaScript benchmark among browsers which share the same engine would be about the same, and the results confirm this. There are, however, dramatic differences among engines. For each JavaScript implementation, I ran the benchmark five times on an idle machine, using an iteration count calculated to result in a run time of approximately five minutes. I then computed the mean time of the five runs and divided by the iteration count to obtain the run time in microseconds per iteration. As the reference, I started with the C version, compiled with GCC 5.4.0, and run for 166,051,660 iterations. Run times in seconds were (296.89, 296.37, 296.29, 296.76, 296.37) for a mean time of 296.536, or 1.7858 microseconds per iteration. The first test I ran was with Node.js v6.11.3. This is a command line environment which uses the V8 JavaScript engine also used by Google Chrome. I ran 112,697,692 iterations and measured run times in seconds of (300.001, 300.542, 300.850, 301.022, 302.053) with a mean of 300.8936, and 2.6699 microseconds per iteration. This is 1.4951 times slower than C. Next was Google Chrome version 61.0.3163.91, which was run for 119,019,281 iterations with timings of (293.573, 293.420, 292.188, 292.740, 292.939) with a mean of 292.972 seconds and 2.4616 microseconds per iteration, which is 1.3784 times slower than C. I then tested Chromium, the free version of the browser upon which Google Chrome is built, version 60.0.3112.113, and as expected, the results were almost identical: 1.3863 times slower than C. The Brave browser is derived from the Chromium code base and thus inherits its V8 JavaScript engine. Version 0.18.36 was a little bit faster in the tests, coming in at 1.3336 times slower than C. So far, the results were pretty much consistent with what I'd observed during the Cellular Automata Laboratory project: JavaScript performs at a speed competitive to compiled languages or the better byte code languages, and is suitable for all but the most computationally-intense tasks. Next up was Mozilla Firefox, which was now on version 55.0.2, a long way from the 1.0.6 I tested in 2005. Firefox uses its own JavaScript engine called Rhino, which is written in Java and compiles JavaScript into Java bytecode, which is executed with a just-in-time compiler. When I ran the benchmark, I could scarcely believe my eyes. I had to use an iteration count of 457,577,013 (yes, nearly half a billion) to achieve a run time around five minutes. I measured run times of (303.958, 303.255, 303.683, 304.136, 304.283) seconds with a mean of 393.863, or 0.6641 microseconds per iteration. This is simply stunning: the ratio of run time to C is 0.3719 or, taking the reciprocal, JavaScript in Firefox ran the benchmark almost 2.7 times faster than C, compiled with GCC to native 64-bit Intel machine code in full optimising mode. What's going on here? My guess is that we're seeing the poor performance of the new GCC trigonometric function libraries taking their toll. Fbench is far more intense in its use of trigonometric functions than even most other scientific software, so a slow implementation of these functions will show up strongly in the results. I suspect the Java engine which ultimately runs the JavaScript code of the benchmark uses different libraries which, although perhaps less accurate (but entirely adequate for this program), run much faster than those now used by GCC. The final test was a little bit more involved, since it tested Apple's Safari browser which uses a JavaScript engine called Nitro that is part of the WebKit framework. Current releases incorporate just-in-time compilation to machine code. In order to time this browser, I had to run it on a Macintosh Pro instead of the Dell laptop running Xubuntu Linux on which all the other tests were run. The Macintosh dates from 2008, and is substantially slower than the Dell machine. To adjust results to compensate for this speed difference, I ran the Perl version of the benchmark on the two machines and divided the run times to obtain the speed ratio between them. Since the Perl benchmark was identical and the two machines were running comparable versions of Perl, this provides a reasonable estimate of their relative performance. Running the benchmark in Safari 11.0 (11604.1.38.1.7), it immediately became clear this was another fast one. I needed an iteration count of 177,542,107 to obtain the desired run time of around five minutes, and I measured the following times: (299.428, 299.418, 299.417, 299.439, 299.400) for a mean of 299.4204 seconds and 1.6865 microseconds per iteration. But since this machine is less than half the speed of the Dell, this must be multiplied by the speed ratio of 0.4487 to obtain an equivalent time of 0.7567 microseconds per iteration had the Macintosh been as fast as the machine on which the other benchmarks were run. This works out to a run time ratio of 0.4237 compared to C, or about 2.36 times faster than C; in the same ballpark as Firefox and much faster than the V8-based systems. Here is a table summarising the results, ranked from fastest to slowest.| Browser/System | JavaScript Engine | Run Time vs. C |
|---|---|---|
| Mozilla Firefox | Rhino | 0.3719 |
| Safari (Mac OS X) | Nitro | 0.4237 |
| Brave | V8 | 1.3336 |
| Google Chrome | V8 | 1.3784 |
| Chromium | V8 | 1.3863 |
| Node.js | V8 | 1.4951 |
| Language | Relative Time |
Details |
|---|---|---|
| C | 1 | GCC 3.2.3 -O3, Linux |
| JavaScript | 0.372 0.424 1.334 1.378 1.386 1.495 |
Mozilla Firefox 55.0.2, Linux Safari 11.0, MacOS X Brave 0.18.36, Linux Google Chrome 61.0.3163.91, Linux Chromium 60.0.3112.113, Linux Node.js v6.11.3, Linux |
| Visual Basic .NET | 0.866 | All optimisations, Windows XP |
| FORTRAN | 1.008 | GNU Fortran (g77) 3.2.3 -O3, Linux |
| Pascal | 1.027 1.077 |
Free Pascal 2.2.0 -O3, Linux GNU Pascal 2.1 (GCC 2.95.2) -O3, Linux |
| Swift | 1.054 | Swift 3.0.1, -O, Linux |
| Rust | 1.077 | Rust 0.13.0, --release, Linux |
| Java | 1.121 | Sun JDK 1.5.0_04-b05, Linux |
| Visual Basic 6 | 1.132 | All optimisations, Windows XP |
| Haskell | 1.223 | GHC 7.4.1-O2 -funbox-strict-fields, Linux |
| Scala | 1.263 | Scala 2.12.3, OpenJDK 9, Linux |
| Ada | 1.401 | GNAT/GCC 3.4.4 -O3, Linux |
| Go | 1.481 | Go version go1.1.1 linux/amd64, Linux |
| Simula | 2.099 | GNU Cim 5.1, GCC 4.8.1 -O2, Linux |
| Lua | 2.515 22.7 |
LuaJIT 2.0.3, Linux Lua 5.2.3, Linux |
| Python | 2.633 30.0 |
PyPy 2.2.1 (Python 2.7.3), Linux Python 2.7.6, Linux |
| Erlang | 3.663 9.335 |
Erlang/OTP 17, emulator 6.0, HiPE [native, {hipe, [o3]}] Byte code (BEAM), Linux |
| ALGOL 60 | 3.951 | MARST 2.7, GCC 4.8.1 -O3, Linux |
| PL/I | 5.667 | Iron Spring PL/I 0.9.9b beta, Linux |
| Lisp | 7.41 19.8 |
GNU Common Lisp 2.6.7, Compiled, Linux GNU Common Lisp 2.6.7, Interpreted |
| Smalltalk | 7.59 | GNU Smalltalk 2.3.5, Linux |
| Forth | 9.92 | Gforth 0.7.0, Linux |
| Prolog | 11.72 5.747 |
SWI-Prolog 7.6.0-rc2, Linux GNU Prolog 1.4.4, Linux, (limited iterations) |
| COBOL | 12.5 46.3 |
Micro Focus Visual COBOL 2010, Windows 7 Fixed decimal instead of computational-2 |
| Algol 68 | 15.2 | Algol 68 Genie 2.4.1 -O3, Linux |
| Perl | 23.6 | Perl v5.8.0, Linux |
| Ruby | 26.1 | Ruby 1.8.3, Linux |
| QBasic | 148.3 | MS-DOS QBasic 1.1, Windows XP Console |
| Mathematica | 391.6 | Mathematica 10.3.1.0, Raspberry Pi 3, Raspbian |
Posted at
21:34
Friday, September 29, 2017
Floating Point Benchmark: Prolog Language Added
I have posted an update to my trigonometry-intense floating point benchmark which adds Prolog to the list of languages in which the benchmark is implemented. A new release of the benchmark collection including Prolog is now available for downloading. Prolog is a language designed for logic programming. Working in conjunction with a database of facts and rules, one can make queries which are answered by applying the rules of formal logic. Thus, in Prolog, one often describes the answer one seeks and lets the language implementation find it rather than prescribing the steps through which the answer is obtained as one would in a conventional imperative programming language. Prolog is used in artificial intelligence and computational linguistics research, and is well-suited to the analysis of unstructured natural language. Components of IBM's Watson question answering system are written in Prolog. The first Prolog system was developed in 1972, and the language was standardised as ISO/IEC 13211-1 in 1995, with subsequent corrigenda in 2007 and 2012. Prolog is intended for problems which are nothing like that performed by the floating point benchmark, which is a typical scientific computing task involving floating point numbers and trigonometric functions. However, Prolog supports floating point numbers and trigonometric functions, and as a Turing-complete language is able to perform any computational task which can be programmed in any other such language. So, this can be considered as a case of misusing Prolog for a task for which it wasn't remotely intended, with the goal of seeing how well it expresses the algorithms and performs. The resulting program uses very little of Prolog's sophisticated pattern-matching and inference engine: the task simply doesn't require these facilities. Instead, Prolog is used as a functional programming language, employing its variables to pass arguments to and return values from functions coded as Prolog rules. The result looks somewhat odd to those accustomed to other programming languages, but one you get used to the syntax, the code is expressive and comprehensible. Pattern matching allows replacing all of the conditionals for the four cases of the transit_surface operation (marginal or paraxial ray, flat or curved surface) with four different rules selected by the arguments passed to them, as done in functional languages such as Haskell and Erlang. I originally developed this benchmark on GNU Prolog version 1.4.4, but when I went to run the benchmark for an archival run time of around five minutes, I ran into the problem that GNU Prolog does not fully implement tail call optimisation. What does this mean? Prolog, like many functional languages, does not provide control structures for iteration. Instead, iteration is accomplished by recursion. For example, here's how you might write the factorial function in C using iteration:
int factorial(int n) {
int result = 1;
int i;
for (i = 1; i <= n; i++) {
result *= i;
}
return result;
}
But Prolog has no equivalent of C's for statement, so you define
the factorial function recursively as it's usually expressed in
mathematics:
fact(N, NF) :-
fact(1, N, 1, NF).
fact(X, X, F, F) :- !.
fact(X, N, FX, F) :-
X1 is X + 1,
FX1 is FX * X1,
fact(X1, N, FX1, F).
Now, this looks a bit odd until you become accustomed to the
rather eccentric syntax of Prolog, but the key thing to take
away is that evaluation is accomplished by the four argument
definition of fact(). When the final definition of fact() calls
itself, it is the last item executed, and tail call optimisation
takes note of this and, instead of recursively calling itself,
uses the same stack frame and transforms the recursion into an
iteration. This allows recursion to an arbitrary depth without
consuming large amounts of stack memory.
Tail call optimisation is common among languages such as Lisp,
Haskell, and Prolog, but GNU Prolog does not implement it, or at
least doesn't do so in a sufficiently general manner as to
permit running benchmarks with a large number of iterations.
As a result, I moved the project from GNU Prolog to SWI-Prolog:
a mature Prolog system which properly supports tail call
optimisation. I used Linux version 7.6.0-rc2, which is a stable
and complete implementation of Prolog, using the 64-bit Ubuntu
installation package.
Development of the program was straightforward, with the only
speed bumps my coming to terms with the Prolog way of doing
things. This program constitutes an “abuse of language” almost
as extreme as the COBOL version. Prolog is intended for logic
programming where its underlying inference engine does most of
the work in resolving queries where the programmer specifies a
way to find the answer but not the details of how it is to be
evaluated. Optical design ray tracing couldn't be more
different—the computations must be evaluated procedurally, so I
ended up using Prolog as a functional programming langauge,
writing procedural code as ∧ expressions within rules, while
taking advantage of Prolog's polymorphism and pattern matching
to make the code more expressive of the problem being solved.
Since Prolog provides full support for floating point arithmetic
and trigonometric functions, there were no problems in
evaluating the expressions used in the benchmark.
After testing the benchmark in SWI-Prolog for accuracy, I ran
the Prolog benchmark for 13,725,893 iterations and obtained the
following run times in seconds for five runs:
(287.14,
286.64,
288.11,
288.15,
286.38)
These runs give a mean time of 287.284 seconds, or 20.9301
microseconds per iteration.
I then ran the C benchmark for 166,051,660 iterations, yielding
run times of:
(296.89,
296.37,
296.29,
296.76,
296.37)
seconds, with mean 296.536, for 1.7858 microseconds per
iteration.
Dividing these gives a SWI-Prolog run time of 11.7203 longer
than that of C. In other words, for this benchmark, SWI-Prolog
runs around 11.72 times slower than C.
I next wanted to compare GNU Prolog with C. Because of the lack
of tail call optimisation, I was unable to run the benchmark for
the required number of iterations to obtain an “on the record”
run of about five minutes (even when I tried tricks of nesting
iterations in calls), so I estimated its performance as follows.
I ran the benchmark on GNU Prolog with 450000 iterations, which
was the maximum I could use after setting “export
GLOBALSZ=80000000000” to create an enormous global stack. I
received the following timings in seconds:
(4.37,
4.36,
4.41,
4.33,
4.32)
of which the mean is 4.358 seconds.
Then, I ran the same benchmark under SWI-Prolog and measured:
(8.90,
8.80,
8.79,
8.99,
8.96)
for a mean of 8.888. This gives a run time ratio of GNU Prolog
to SWI-Prolog of 0.49032, and applying this to the measured
ratio of SWI-Prolog to C, we can infer a ratio of GNU Prolog to
C of 5.7467.
I do not report this as a primary benchmark for GNU Prolog
because its lack of tail call optimisation prevented it from
fulfilling the conditions of the benchmark: a run of around five
minutes. It is, however, indicative of the performance of
Prolog which can be obtained by compiling to native code, and is
included because it demonstrates that Prolog can perform within
the range of other compiled languages.
In summary, Prolog did pretty well on this job for which it
wasn't designed. The program is straightforward and readable,
and the performance in SWI-Prolog is comparable to other
languages which compile to byte code, as does this Prolog
implementation. GNU Prolog, which compiles to native machine
code, performed better than GNU Common Lisp in compiled mode,
but toward the slow end of machine code compilers (but, since
the full benchmark could not be run, the GNU Prolog results are
not archival).
This directory includes a Makefile which can build the benchmark
using either SWI-Prolog of GNU Prolog (which, of course, must be
installed on your machine). The SWI-Prolog version of the
benchmark uses that system's nonstandard three argument format/3
predicate to print its results to Prolog atoms, allowing the
program to perform its own accuracy test at the completion of
the benchmark. GNU Prolog and the ISO standard do not implement
this extension, so alternative code is used which simply prints
the output of the last iteration of the benchmark to standard
output where it is compared with the expected results with diff.
The relative performance of the various language implementations (with C taken as 1) is as follows. All language implementations of the benchmark listed below produced identical results to the last (11th) decimal place.
| Language | Relative Time |
Details |
|---|---|---|
| C | 1 | GCC 3.2.3 -O3, Linux |
| Visual Basic .NET | 0.866 | All optimisations, Windows XP |
| FORTRAN | 1.008 | GNU Fortran (g77) 3.2.3 -O3, Linux |
| Pascal | 1.027 1.077 |
Free Pascal 2.2.0 -O3, Linux GNU Pascal 2.1 (GCC 2.95.2) -O3, Linux |
| Swift | 1.054 | Swift 3.0.1, -O, Linux |
| Rust | 1.077 | Rust 0.13.0, --release, Linux |
| Java | 1.121 | Sun JDK 1.5.0_04-b05, Linux |
| Visual Basic 6 | 1.132 | All optimisations, Windows XP |
| Haskell | 1.223 | GHC 7.4.1-O2 -funbox-strict-fields, Linux |
| Scala | 1.263 | Scala 2.12.3, OpenJDK 9, Linux |
| Ada | 1.401 | GNAT/GCC 3.4.4 -O3, Linux |
| Go | 1.481 | Go version go1.1.1 linux/amd64, Linux |
| Simula | 2.099 | GNU Cim 5.1, GCC 4.8.1 -O2, Linux |
| Lua | 2.515 22.7 |
LuaJIT 2.0.3, Linux Lua 5.2.3, Linux |
| Python | 2.633 30.0 |
PyPy 2.2.1 (Python 2.7.3), Linux Python 2.7.6, Linux |
| Erlang | 3.663 9.335 |
Erlang/OTP 17, emulator 6.0, HiPE [native, {hipe, [o3]}] Byte code (BEAM), Linux |
| ALGOL 60 | 3.951 | MARST 2.7, GCC 4.8.1 -O3, Linux |
| PL/I | 5.667 | Iron Spring PL/I 0.9.9b beta, Linux |
| Lisp | 7.41 19.8 |
GNU Common Lisp 2.6.7, Compiled, Linux GNU Common Lisp 2.6.7, Interpreted |
| Smalltalk | 7.59 | GNU Smalltalk 2.3.5, Linux |
| Forth | 9.92 | Gforth 0.7.0, Linux |
| Prolog | 11.72 5.747 |
SWI-Prolog 7.6.0-rc2, Linux GNU Prolog 1.4.4, Linux, (limited iterations) |
| COBOL | 12.5 46.3 |
Micro Focus Visual COBOL 2010, Windows 7 Fixed decimal instead of computational-2 |
| Algol 68 | 15.2 | Algol 68 Genie 2.4.1 -O3, Linux |
| Perl | 23.6 | Perl v5.8.0, Linux |
| Ruby | 26.1 | Ruby 1.8.3, Linux |
| JavaScript | 27.6 39.1 46.9 |
Opera 8.0, Linux Internet Explorer 6.0.2900, Windows XP Mozilla Firefox 1.0.6, Linux |
| QBasic | 148.3 | MS-DOS QBasic 1.1, Windows XP Console |
| Mathematica | 391.6 | Mathematica 10.3.1.0, Raspberry Pi 3, Raspbian |
Posted at
20:56
Sunday, September 24, 2017
Floating Point Benchmark: PL/I Language Added
I have posted an update to my trigonometry-intense floating point benchmark which adds PL/I to the list of languages in which the benchmark is implemented. A new release of the benchmark collection including PL/I is now available for downloading. I have always had a fondness for PL/I. Sure, it was an archetypal product of IBM at the height of the supremacy of Big Blue, and overreached and never completely achieved its goals, but it was a product of the 1960s, when technological ambition imagined unifying programming languages as diverse as Fortran, COBOL, and Algol into a single language which would serve for all applications and run on platforms ranging from the most humble to what passed for supercomputers at the time. It was the choice for the development of Multics, one of the most ambitious operating system projects of all time (and, after its wave of enthusiasm broke on the shore of reality, inspired Unix), and the C language inherits much of its syntax and fundamentals from PL/I. Few people recall today, but the first version of AutoCAD shipped to customers was written in PL/I. When we were developing AutoCAD in 1982, we worked in parallel, using Digital Research's PL/I-80 (a subset of PL/I, but completely adequate for the needs of AutoCAD) on 8080/Z-80 CP/M systems and C on 8086/8088 machines. As it happened, AutoCAD-80, the PL/I version, shipped first, so the first customer who purchased AutoCAD received a version written in PL/I. The goal of PL/I was the grand unification of programming languages, which had bifurcated into a scientific thread exemplified by Fortran and variants of Algol and a commercial thread in which COBOL was dominant. The idea was that a single language, and a single implementation would serve for all, and that programmers working in a specific area could learn the subset applicable to their domain, ignoring features irrelevant to the tasks they programmed. By the standards of the time, the language feature set was ambitious. Variables could be declared in binary or decimal, fixed point or floating, with variable precision. Complex structures and arrays could be defined, including arrays of structures and structures containing arrays. A variety of storage classes were available, allowing the creation of dynamically or manually allocated storage, and access through pointers. Support for recursive procedures and reentrant code was included. The language was defined before the structured programming craze, but its control structures are adequate to permit structured programming should a programmer choose that style. Object orientation was undreamt of at the time, and support for it was added only much later. Iron Spring Software is developing a reasonably complete implementation of PL/I which runs on Linux and OS/2. It adheres to ANSI standard X3.74-1987 (ISO/IEC 6522:1992), the so-called “Subset G” of the language, but, in its present beta releases, does not support all features of the standard, The current state of the beta version is documented in the Programming Guide. With one exception (the ASIN mathematical builtin function), none of the missing features are required by the floating point benchmark, and ASIN is easily emulated by the identity (expressed in PL/I)asin(x) = atan(x, sqrt(1 − (x * x)))
implemented as a procedure in the program. The Iron Spring PL/I compiler is closed source, and will be offered for sale upon general release, but during the beta period downloads are free. The runtime libraries (much of which are written in PL/I) are open source and licensed under the GNU Lesser General Public License (LGPL). There are no restrictions or licenses required to redistribute programs compiled by the compiler and linked with its libraries. This version of the benchmark was developed using the 0.9.9b beta release of the Iron Spring PL/I compiler. Current Linux downloads are 32-bit binaries and produce 32-bit code, but work on 64-bit systems such as the one on which I tested it. It is possible that a native 64-bit version of the compiler and libraries might outperform 32-bit code run in compatibility mode, but there is no way at present to test this. The PL/I implementation of Fbench is a straightforward port derived from the Ada version of the program, using the same imperative style of programming and global variables. All floating point values are declared as FLOAT BINARY(49), which maps into IEEE double-precision (64 bit) floating point. As noted above, the missing ASIN (arc sine) builtin function was emulated by an internal procedure named l_asin to avoid conflict with the builtin on compilers which supply it. Development of the program was straightforward, and after I recalled the idioms of a language in which I hadn't written code for more than thirty years, the program basically worked the first time. Support for the PUT STRING facility allowed making the program self-check its results without any need for user interaction. To avoid nonstandard system-dependent features, the iteration count for the benchmark is compiled into the program. After I get the benchmark running and have confirmed that it produces the correct values, I then time it with an modest iteration count, then adjust the iteration count to obtain a run time of around five minutes, which minimises start-up and termination effects and accurately reflects execution speed of the heart of the benchmark. Next, I run the benchmark five times on an idle system, record the execution times, compute the mean value, and from that calculate the time in microseconds per iteration. This is then compared with the same figure from runs of the C reference implementation of the benchmark to obtain the relative speed of the language compared to C. When I first performed this process, it was immediately apparent that something had seriously gang agley. The C version of the benchmark ran at 1.7858 microseconds per iteration, while the PL/I implementation took an aching 95.1767 microseconds/iteration—fully 53 times slower! This was, in its own way, a breathtaking result. Most compiled languages come in between somewhere between the speed of C and four times slower, with all of the modern heavy-hitter languages (Fortran, Pascal, Swift, Rust, Java, Haskell, Scala, Ada, and Go) benchmarking no slower than 1.5 times the C run time. Most interpreted languages (Perl, Python, Ruby) still benchmark around twice as fast as this initial PL/I test. It was time to start digging into the details. First of all, I made sure that all of the floating point variables were properly defined and didn't, for example, declare variables as fixed decimal. When I tried this with the COBOL version of the benchmark, I indeed got a comparable execution time (46 times slower than C). But the variables were declared correctly, and examination of the assembly language listing of the code generated by the compiler confirmed that it was generating proper in-line floating-point instructions instead of some horror such as calling library routines for floating point arithmetic. Next, I instrumented the program to verify that I hadn't blundered and somehow made it execute more iterations of the inner loop than were intended. I hadn't. This was becoming quite the mystery. It was time to take a deeper look under the hood. I downloaded, built, and installed OProfile, a hardware-supported statistical profiling tool which, without support by the language (which is a good thing, because the PL/I compiler doesn't provide any) allows measurement of the frequency of instruction execution within a program run under its supervision. I ran the benchmark for five minutes under OProfile:
operf ./fbench
(because the profiling process uses restricted kernel calls, this must be done as the super-user), and then annotated the results with:
opannotate --source --assembly fbench >fbench.prof The results were flabbergasting. I was flabber-aghast to discover that in the entire five minute run, only 5.6% of the time was spent in my benchmark program: all the rest was spent in system libraries! Looking closer, one of the largest time sinks was the PL/I EXP builtin function, which was distinctly odd, since the program never calls this function. I looked at the generated assembly code and discovered, however, that if you use the normal PL/I or Fortran idiom of “x ** 2” to square a value, rather than detecting the constant integer exponent and compiling the equivalent code of “x * x”, the compiler was generating a call to the general exponential function, able to handle arbitrary floating point exponents. I rewrote the three instances in the program where the “**” operator appeared to use multiplication, and when I re-ran the benchmark it was almost ten times faster (9.4 times to be precise)! Examination of the Oprofile output from this version showed that 44% of the time was spent in the benchmark, compared to 5.6% before, with the rest divided mostly among the mathematical library builtin functions used by the program. Many of the library functions which chewed up time in the original version were consequences of the calls on EXP and melted away when it was replaced by multiplication. Further experiments showed that these library functions, most written in PL/I, were not particularly efficient: replacing the builtin ATAN function with my own implementation ported from the INTRIG version of the C benchmark sped up the benchmark by another 6%. But the goal of the benchmark is to test the compiler and its libraries as supplied by the vendor, not to rewrite the libraries to tweak the results, so I set this version aside and proceeded with timing tests. I ran the PL/I benchmark for 29,592,068 iterations and obtained the following run times in seconds for five runs (299.23, 300.59, 298.52, 300.94, 298.07). These runs give a mean time of 299.47 seconds, or 10.1209 microseconds per iteration. I then ran the C benchmark for 166,051,660 iterations, yielding run times of (296.89, 296.37, 296.29, 296.76, 296.37) seconds, with mean 296.536, for 1.7858 microseconds per iteration. Dividing these gives a PL/I run time of 5.667 longer than that of C. In other words, for this benchmark, PL/I runs around 5.7 times slower than C. This is toward the low end of compiled languages in which the benchmark has been implemented. Among those tested so far, it falls between ALGOL 60 (3.95 times C) and GNU Common Lisp (compiled, 7.41 times C), and it is more than twice as fast as Micro Focus Visual COBOL in floating point mode (12.5 times C). It should be remembered, however, that this is a beta test compiler under active development, and that optimisation is often addressed after full implementation of the language. And since the libraries are largely written in PL/I, any optimisation of compiler-generated code will improve library performance as well. The lack of optimisation of constant integer exponents which caused the initial surprise in timing tests will, one hopes, be addressed in a subsequent release of the compiler. Further, the second largest consumer of time in the benchmark, after the main program itself with 44%, was the ATAN function, with 23.6%. But the ATAN function is only used to emulate the ASIN builtin, which isn't presently implemented. If and when an ASIN function is provided, and if its implementation is more efficient (for example, using a Maclaurin series) than my emulation, a substantial increase in performance will be possible. Nothing inherent in the PL/I language limits its performance. Equivalent code, using the same native data types, should be able to run as fast as C or Fortran, and mature commercial compilers from IBM and other vendors have demonstrated this performance but at a price. The Iron Spring compiler is a promising effort to deliver a professional quality PL/I compiler for personal computers at an affordable price (and, in its present beta test incarnation, for free). The relative performance of the various language implementations (with C taken as 1) is as follows. All language implementations of the benchmark listed below produced identical results to the last (11th) decimal place.
| Language | Relative Time |
Details |
|---|---|---|
| C | 1 | GCC 3.2.3 -O3, Linux |
| Visual Basic .NET | 0.866 | All optimisations, Windows XP |
| FORTRAN | 1.008 | GNU Fortran (g77) 3.2.3 -O3, Linux |
| Pascal | 1.027 1.077 |
Free Pascal 2.2.0 -O3, Linux GNU Pascal 2.1 (GCC 2.95.2) -O3, Linux |
| Swift | 1.054 | Swift 3.0.1, -O, Linux |
| Rust | 1.077 | Rust 0.13.0, --release, Linux |
| Java | 1.121 | Sun JDK 1.5.0_04-b05, Linux |
| Visual Basic 6 | 1.132 | All optimisations, Windows XP |
| Haskell | 1.223 | GHC 7.4.1-O2 -funbox-strict-fields, Linux |
| Scala | 1.263 | Scala 2.12.3, OpenJDK 9, Linux |
| Ada | 1.401 | GNAT/GCC 3.4.4 -O3, Linux |
| Go | 1.481 | Go version go1.1.1 linux/amd64, Linux |
| Simula | 2.099 | GNU Cim 5.1, GCC 4.8.1 -O2, Linux |
| Lua | 2.515 22.7 |
LuaJIT 2.0.3, Linux Lua 5.2.3, Linux |
| Python | 2.633 30.0 |
PyPy 2.2.1 (Python 2.7.3), Linux Python 2.7.6, Linux |
| Erlang | 3.663 9.335 |
Erlang/OTP 17, emulator 6.0, HiPE [native, {hipe, [o3]}] Byte code (BEAM), Linux |
| ALGOL 60 | 3.951 | MARST 2.7, GCC 4.8.1 -O3, Linux |
| PL/I | 5.667 | Iron Spring PL/I 0.9.9b beta, Linux |
| Lisp | 7.41 19.8 |
GNU Common Lisp 2.6.7, Compiled, Linux GNU Common Lisp 2.6.7, Interpreted |
| Smalltalk | 7.59 | GNU Smalltalk 2.3.5, Linux |
| Forth | 9.92 | Gforth 0.7.0, Linux |
| COBOL | 12.5 46.3 |
Micro Focus Visual COBOL 2010, Windows 7 Fixed decimal instead of computational-2 |
| Algol 68 | 15.2 | Algol 68 Genie 2.4.1 -O3, Linux |
| Perl | 23.6 | Perl v5.8.0, Linux |
| Ruby | 26.1 | Ruby 1.8.3, Linux |
| JavaScript | 27.6 39.1 46.9 |
Opera 8.0, Linux Internet Explorer 6.0.2900, Windows XP Mozilla Firefox 1.0.6, Linux |
| QBasic | 148.3 | MS-DOS QBasic 1.1, Windows XP Console |
| Mathematica | 391.6 | Mathematica 10.3.1.0, Raspberry Pi 3, Raspbian |
Posted at
15:17
Friday, September 15, 2017
Tom Swift and His Electric Runabout updated, EPUB added
All 25 of the public domain Tom Swift novels have been posted in the Tom Swift and His Pocket Library collection. I am now returning to the earlier novels, upgrading them to use the more modern typography of those I've done in recent years. The fifth novel in the series, Tom Swift and His Electric Runabout, has now been updated. Several typographical errors in the original edition have been corrected, Unicode text entities are used for special characters such as single and double quotes and dashes, and the HTML version is now XHTML 1.0 Strict. An EPUB edition of this novel is now available which may be downloaded to compatible reader devices; the details of how to do this differ from device to device—please consult the documentation for your reader for details. Tom Swift's electric car, described in this 1910 novel, compares quite favourably with those on the market more than a century later. Top speed was one hundred miles an hour, and in chapter four Tom says of range on a battery charge, “Well, if I can make it do three hundred miles I'll be satisfied, but I'm going to try for four hundred.” But in case the battery runs down and there's no charging station nearby, Tom has a trick up his sleeve even Elon Musk can't exploit. Asked by his father, “Suppose you're not near a charging station?”, Tom replies, “…I'm going to have it fixed so I can take current from any trolley line, as well as from a regular charging station. My battery will be capable of being recharged very quickly, or, in case of need, I can take out the old cells and put in new ones.” In 1910, interurban trolley lines were ubiquitous in the eastern United States, so the intrepid motorist, seeing the charge gauge creeping down toward zero, need only divert to the nearest trolley line, hook up to the rail and overhead wire or third rail, and before long everything would be just tickey-boo. No thief, the young Swift remarks, “ ‘I'm going to pay for the current I use,’ explained the young inventor. ‘I have a meter which tells how much I take.’ ”Posted at
13:58
Tuesday, September 12, 2017
UNUM Updated to Unicode 10, HTML5
I have just posted version 2.1 of UNUM. This update, the first since 2006, updates the database of Unicode characters to Unicode version 10.0.0 (June 2017) and adds, for the first time, full support for the entire set of Chinese, Japanese, and Korean (CJK) ideographic characters, for a total of 136,755 characters in all. CJK characters are identified by their nomenclature in commonly used lexicons, and, where specified in the Unicode database, English definitions. The table of HTML named character references (the sequences like “<” you use in HTML source code when you need to represent a character which has a syntactic meaning in HTML or which can't be directly included in a file with the character encoding you're using to write it) has been updated to the list published by the World Wide Web Consortium (W3C) for HTML5. It used to be that HTML named character references were a convenient text-based shorthand so that, for example, if your keyboard or content management system didn't have a direct way to specify the Unicode character for a right single quote, you could write “’” instead of “’”, the numeric code for the character. This was handy, made the HTML easier to understand, and made perfect sense and so, of course, it had to be “improved”. Now, you can specify the same character as either “’”, “’”, or “’” as well. “Close Curly Quote”—are there also Larry and Moe quotes? Now, apparently to accommodate dim people who can't remember or be bothered to look up the standard character references which have been in use for more than a decade (and how many of them are writing HTML, anyway?), we have lost the ability to provide a unique HTML character reference for Unicode code points which have them. In other words, the mapping from code points to named character references has gone from one-to-one to one-to-many. Further, named character references have been extended from a symbolic nomenclature for Unicode code points to specify logical character definitions which are composed of multiple (all the current ones specify only two) code points which are combined to generate the character. For example, the character reference “≫̸”, which stands for the mathematical symbol “not much greater than”, is actually composed of code points U+226B (MUCH GREATER-THAN) and U+0338 (COMBINING LONG SOLIDUS OVERLAY). Previously, UNUM could assume a one-to-one mapping between HTML character references and Unicode code points, but thanks to these innovations this is no longer the case. Now, when a character is displayed, if it has more than one HTML name, they are all displayed in the HTML column, separated by commas. If the user looks up a composite character reference, all of the Unicode code points which make it up are displayed, one per line, in the order specified in the W3C specification. The addition of the CJK characters makes the code point definition table, which was already large, simply colossal. The Perl code for UNUM including this table is now almost eight megabytes. To cope with this, there is now a compressed version of UNUM in which the table is compressed with the bzip2 utility, which reduces the size of the program to less than a megabyte. This requires a modern version of Perl and a Unix-like system on which bzip2 is installed. Users who lack these prerequisites may download an uncompressed version of UNUM, which will work in almost any environment which can run Perl. UNUM Documentation and Download Page Update: Version 2.2 improves compatibility of the compressed version of the utility by automatically falling back to Perl's core IO::Uncompress::Bunzip2 module if the host system does not have bunzip2 installed. (2017-09-19 18:47 UTC)Posted at
23:35
