* Posts by Torben Mogensen

423 posts • joined 21 Sep 2006

Page:

Boffins offer to make speculative execution great again with Spectre-Meltdown CPU fix

Torben Mogensen

Speculative versus parallel execution

Speculative execution is basically a way to make sequential computation faster. When the processor has to wait for, say, a condition to be decided, it makes a guess as to the outcome and starts working from that guess. If it guesses right, you save time, if not, you both lose time (for clean-up) and waste heat (for doing wasted work). You can try to work on multiple different outcomes simultaneously, but that is more complicated, and you will definitely waste work (and heat).

Speculative execution relies on very precise predictions, and these cost a lot in resources for gathering and storing statistics and analysing these. The bottom line is that speculative execution is very costly in terms of complexity and energy.

Another solution is to pause execution until the outcome is known. While this pause lasts, you can have another thread use the execution units. This is called multi-threading, and is usually implemented by having an extra (or several) copy of all registers, and schedule instructions from two (or more) threads simultaneously. You only execute instructions that are guaranteed to be needed, so there is no speculation. You can even have both threads execute instructions simultaneously, if there are no resource conflicts. The scheduling unit is somewhat more costly, as it has to look at more instructions, but it is not as bad as the complexity of speculative execution. The downside is that each thread does not run faster than if it ran alone on a processor without speculative execution, but the throughput of instructions is likely higher than this case. If the threads share cache, there is a risk of information spillage, so you generally limit this to threads from the same program.

The next step is to make multiple cores, each with their own cache. If the memory is protected (and cleared when given to a new process), this can be made safe from leakage, it scales better than multi-threading, and the complexity is lower. This is part of the reason why the trend is towards more cores rather than faster single cores. In the extreme, we have graphics processors: A large number of very simple cores that do no speculation and no out-of-order execution and which even share the same instruction stream. Sequential execution on these is horribly slow, but the throughput is fantastic, as long as you can supply a suitable workload. It is nigh impossible to make C, Java, and similar languages run fast on graphics processors, so you either need specialised languages (https://futhark-lang.org/) or call from C or Java library routines written in very low-level languages and hand-optimised.

In conclusion, the future belongs to parallel rather than speculative execution, so you should stop expecting your "dusty decks" of programs written in C, Java, Fortran, etc. to automagically run faster on the next generation of computers.

0
0

Intel outside: Apple 'prepping' non-Chipzilla Macs by 2020 (stop us if you're having deja vu)

Torben Mogensen

Re: What was wrong with m68k anyway?

Apple moved from 68K to PowerPC because there was no high-performance 68K processor. PowerPC promised (and delivered) higher performance than 68K, at least in the foreseeable future. At that time, Apple was mainly about desktop machines, so power use was not all-important.

The move to x86 was allegedly motivated by lower power use for the same (or higher) performance, which was required for laptop use. Competition between Intel and AMD had driven an arms race for more power for less power, and Apple could ride on that.

A move to ARM can be partially motivated by a desire for lower power use, but it is more likely so Apple can build their own ASICs, as they have done for iPhone, and so more code can be shared between iOS and MacOS.

1
0
Torben Mogensen

About time

I have long been expecting this move, and I I'm surprised it hasn't happened earlier. Using the same CPU on iPhones and Macs will simplify a lot of things for Apple, as will having the ability to make their own chips combining CPUs with coprocessors of their own choice instead of relying on the fairly limited choice that Intel offers.

With the advent of 64-bit ARMs, integer performance is similar to x86 performance, and due to the smaller core size, you can fit more cores onto a chip, increasing overall performance. Where ARM CPUs have lagged behind Intel is in floating-point performance, but that may not be important for Apple. And if it is, they have a license that allows them to make their own FPU to go alongside the ARM cores. In any case, the most FP-intensive tasks are rapidly moving from classical FPUs to GPUs, so as long as Apple supplies their Macs with GPUs that runs OpenCL at decent speed, sequential FP performance may not matter much. In general, single-core performance (whether integer or FP) is becoming less and less important as the number of cores grow: To get high performance, you have to code for multiple cores, regardless of whether you code for Intel or ARM.

As for running legacy code, this can be done with just-in-time binary translation: The first time a block of x86 code is executed, it is emulated by interpretation, but a process is at the same time started on another core that translates the x86 code to ARM. As soon as this translation finishes, the code will run compiled when next executed. There might even be multiple steps: Interpretation, simple translation, and optimised translation, each being started when the previous form has been executed sufficiently often that it is expected to pay off.

4
0

Programming languages can be hard to grasp for non-English speakers. Step forward, Bato: A Ruby port for Filipinos

Torben Mogensen

Someone (I don't recall who) once said something along the lines of "If they ever build a computer that can be programmed in English, they will find that people can't program in English". The point being that the level of precision required for instructing a computer is far beyond most people even when using their native language -- or maybe in particular when using their native language.

As a side note, I recall that BBC BASIC had a a "colour" command, while most other BASICs had a "color" command.

1
0
Torben Mogensen

Re: Oh, the irony!

"If memory serves me right Simula and Erlang are both Scandinavian."

Yes. Simula is/was Norwegian and Erlang is/was Swedish, but both became international efforts once they gained popularity.

0
0
Torben Mogensen

Re: Nothing new here

In Algol 68, keywords were distinguished from identifiers by case Keyword are upper case (or boldface or quoted) and identifiers lower case. This allowed non-English versions of Algol 68 just by providing a table of keyword names. And since there is no overlap with identifiers, the code could automatically be converted to use English keywords (or vice-versa) without risk of variable capture.

Similarly, in Scratch keywords are just text embedded in graphical elements, and changing the bitmaps of these graphical elements can change the language of the keywords without affecting other parts of the program, and the same program will be shown with English keywords in an English-language Scratch system and in Japanese (or whatever) in a Japanese Scratch system, because the internal representation does not include the bitmaps.

But I agree that, unless the programming language attempts to look like English (COBOL, AppleScript, etc.), the language of the keywords matter next to nothing, as long as the letters used are easily accessible from your keyboard. There are programming languages with next to no keywords (APL being an extreme example), and (apart from sometimes requiring special keyboards), they are not really more or less difficult to learn than languages with keywords in your native language (what makes APL difficult to learn is not its syntax). An exception may be children, which is why Scratch allows "reskinning" the graphical elements.

1
0

Death notice: Moore’s Law. 19 April 1965 – 2 January 2018

Torben Mogensen

HmmYes writes: "To be honest, Moores law died about 2005ish.

Youve not really seen much in the way of clock speeds beyond 2-3G."

What you observe here is not the end of Moore's Law, but the end of Dennard scaling.

1
0
Torben Mogensen

Speculative execution

The root of Spectre and Meltdown is speculative execution -- the processor trying to guess which instructions you are going to execute in the future. While this can increase performance if you can guess sufficiently precisely, it will also (when you guess incorrectly) mean that you will have to discard or undo work that should not really have been done in the first place. On top of that, accurate guesses aren't cheap. Some processors use more silicon for branch prediction than they do for actual computation.

This means that speculative execution is not only a security hazard (as evidenced by Meltdown and Spectre), but it also costs power. Power usage is increasingly becoming a barrier, not only for mobile computing powered by small batteries, but also for data centres, where a large part of the power is drawn by CPUs and cooling for these. Even if Moore's law continues to hold for a decade more, this won't help: Dennard scaling died a decade ago. Dennard scaling is the observation that, given the same voltage and frequency, power use in a CPU is pretty much proportional to the area of the active transistors, so halving the size of transistors would also halve the power use for similar performance.

This means that, to reduce power, you need to do something other than reduce transistor area. One possibility is to reduce voltage, but that will effectively also reduce speed. You can reduce both speed and voltage and gain the same overall performance for less power by using many low-frequency cores rather a few very fast cores. Making cores simpler while keeping the same clock frequency is another option. Getting rid of speculative execution is an obvious possibility, and while this will slow processors down somewhat, the decrease in power use (and transistor count) is greater. As with reducing clock speed, you need more cores to get the same performance, but the power use for a given performance will fall. You can also use more fancy techniques such as charge-recovery logic, Bennet-clocking, reversible gates, and so on, but for CMOS this will only gain you a little, as leakage is becoming more and more significant. In the future, superconductive materials or nano-magnets may be able to bring power down to where reversible gates make a significant difference, but that will take a while yet.

In the short term, the conclusion is that we need simpler cores running at lower frequencies, but many more of them, to get higher performance at lower power use. This requires moving away from the traditional programming model of sequential execution and a large uniform memory. Shared-memory parallelism doesn't scale very well, so we need to program with small local memories and explicit communication between processors to get performance. Using more specialised processors can also help somewhat.

14
0

Arm Inside: Is Apple ready for the next big switch?

Torben Mogensen

About time, I think

When Apple started making their own ARM chips, I predicted that they would move to ARM on the Mac line also. It has taken longer than I expected, but Apple has good reasons for this:

1. It would make Macs the ideal tool for developing iPhone software, as it can be made to run it without emulation.

2. More parts of the OS can be shared between Mac and iPhone.

3. It allows Apple to make a SoC to exactly their specifications instead of relying on what Intel produces.

4. It removes dependency on Intel (or AMD).

It is not impossible for Apple to make a 64-bit ARM processor that will outperform the fastest Intel processor. I'm sure Apple would love having the fastest laptops around, so people would migrate from Wintel to Apple for performance reasons. Apple need to do more work on the FP side to make this happen, but it is not impossible.

0
0

Amazon to make multiple Lord of the Rings prequel TV series

Torben Mogensen

Could go either way

There is potential for disaster, but if handled well, it could be good. I think the best period for an initial run is the period between the Hobbit and LotR, as mentioned earlier. I'm not sure Moria will work well as a main storyline -- the retaking is probably not all that interesting, and the fall happens rather late in the time line (since Gimli is not aware of it when the Fellowship enters Moria). The rangers fighting orcs and goblins up north is probably a better idea, but with a better storyline than the "War in the North" game. It could feature a young Aragorn so there is some name recognition.

I'm not sure the story of Túrin Turambar (The Children of Hurin) will work on TV, nor Beren and Lúthien. The tale of Númenor definitely takes place over too long a time frame to work on TV.

3
0

ASUS smoking hashes with 19-GPU, 24,000-core motherboard

Torben Mogensen

Re: Those scientists...

Machine learning of almost any kind is sufficiently parallelisable to exploit such a monster. Deep learning neural networks are very popular these days, and they need lots of processor power. It is already running on graphics processors for that reason. DNA analysis too.

13
0

Faking incontinence and other ways to scare off tech support scammers

Torben Mogensen

Quick solution

While playing elaborate pranks on the scammers may be fun, you are wasting your own time as well as theirs -- and your time is probably much more valuable, to you at least.

So when I get a call from someone claiming to be from the Microsoft Tech Support Centre or some such, I just say "No, you're not" and hang up.

21
2

81's 99 in 17: Still a lotta love for the TI‑99/4A – TI's forgotten classic

Torben Mogensen

Double interpretation overhead

The main reason that BASIC on the TI99/4a was slow was that the BASIC interpreter was not written in assembly language (which would not have been difficult, as the TMS9900 was much easier to program than 8-bit alternatives such as 6502 or Z80), but in a language called GPL (Graphics Programming Language), which was compiled to a byte code that was interpreted by the CPU. I estimate the overhead of using interpreted byte code to be 5-10 times, so a BASIC interpreter written directly in assembly language would have sped up the BASIC enormously -- depending on what you do, though. For some operations such as floating-point calculation or graphics primitives, the overhead is relatively small, but for integer calculations it is pretty hefty. Games that are written in assembly language are not affected by this, but I still find it a curious design decision -- it made the TI99/4a compare very badly to other home computers in BASIC benchmarks, which is what most magazines used to compare speed of home computers.

4
0

UK prof claims to have first practical blueprint of a quantum computer

Torben Mogensen

Primes

"the machines will be able to do things like factor very large prime numbers"

That is not very difficult. A prime number factorises to itself, no matter how large it is.

What is meant is that it can (in theory) factor products of very large primes.

Also, the D-wave is not a universal quantum computer, but specialised to do simulated annealing. There probably was a remark about that in an earlier version of the article, since there is an orphaned footnote explaining annealing. The D-wave is similar to analogue computers that can also solve some optimisation problems very quickly, and there is debate about whether D-wave actually uses quantum effects at all or if it is just a fancy analogue computer.

3
0

For $deity's sake, smile! It's Friday! Sad coders write bad code – official

Torben Mogensen

xkcd

has this comment on the matter: https://xkcd.com/1790/

2
0

Coming to the big screen: Sci-fi epic Dune – no wait, wait, wait, this one might be good

Torben Mogensen

SciFi Channel version

SciFi Channel made a low-budget, but decent adaptation as a TV miniseries (http://www.imdb.com/title/tt0142032/), followed by a somewhat-higher-budget version of Dune Messiah/Children of Dune as another miniseries (just called "Children of Dune"), which was also quite decent.

I agree that a single film is not enough to give a decent treatment of the book. A GoT-scale TV-series would be best, but a film trilogy could also work. Then one film for Messiah and another trilogy for Children. If all succeed, one film for each of the following books (God Emperor, Heretics, and Chapter House) is a possibility.

4
0

Google man drags Emacs into the 1990s

Torben Mogensen

Re: Already in the 1980s

You could, if you added sideways RAM. In any case, most games used lower resolution screen modes not only to save space but also to make updates faster.

0
0
Torben Mogensen

Already in the 1980s

Double buffering was widely used on home computers in the early 1980s -- I remember doing it on my BBC micro, and most games did it to get smoother updates. I suspect the method is much earlier than that.

3
0

WebAssembly: Finally something everyone agrees on – websites running C/C++ code

Torben Mogensen

O.K. concept

I have long wished for a low-level, ubiquitous browser language that allows static types/checks (unlike Javascript) and which is not sauced in object-oriented legacies such as null-pointers everywhere, downcasts, dynamic calls, and so on. Something that is as well suited for ML or Haskell as it is for Java or C#.

There is a lot of research in typed assembly language, proof-carrying code, and so on, that allow static verification of safety properties without relying on sandboxing. Something like that would be great. I don't know enough about WebAssembly to decide if it does that, but I suspect not.

2
0

Perlan 2: The glider that will slip the surly bonds of Earth – and touch the edge of space

Torben Mogensen

Re: This makes me wonder . .

The payload of this glider is two people and life support for these in addition to instruments for sampling air. So my guess is 300-400 kg. That could be enough to carry a small rocket that could reach space, but probably not enough to get anything into orbit. Using a balloon to carry a rocket to the edge of the atmosphere seems more practical.

5
0

Science non-fiction: Newly spotted alien world bathes in glow of three stars

Torben Mogensen

Re: habitable?

From the orbit of Pluto (which is a similar distance to our sun as this planet is from its main star), our sun just looks like a very bright star. The two other stars are even further away, so there is very little light indeed.

It is plausible that the planet is still somewhat hot, since it is only 16 million years old, and it is possible that tidal heating might warm some moons. But there is little chance that life has had time to evolve: Initially, the planet would be too hot for life, so if it has the right temperature for life now, it has only had that for a couple of million years, which is probably not enough. The moons are not much better off.

There are much better candidates for life among the known exoplanets.

4
0

Three-bit quantum gate a step closer to universal quantum computer

Torben Mogensen

Re: quantum memcopy?

A Fredkin gate can in theory copy qubits: Use the qubit as control and apply 0 and 1 on the two inputs. The control will be unchanged but one of the outputs will be a copy of the control (and the other will be its negation).

0
0

Picking apart the circuits in the ARM1 – the ancestor of your smartphone's brain

Torben Mogensen

Dynamic logic?

IIRC, ARM2 was fully static, so you could single-step through an instruction sequence or stop the clock indefinitely. So I was surprised to hear that the flags in ARM1 used dynamic logic.

If the flag logic was the only dynamic logic on the chip, it makes good sense to change that in the redesign to get single-step capability, so it is perfectly plausible that this happened.

5
0

Huffing and puffing Intel needs new diet of chips if it's to stay in shape

Torben Mogensen

Different economics

PC and server processors have typically had a high unit price and, hence, a high earning per unit. This is the market Intel has mainly succeeded in. Processors for IoT need to have a very small unit price, which means lower earnings per unit. Intel has previously had some success with 8-bit embedded processors, but they are being pushed out of that market by low-end ARM cores in highly integrated SoCs.

Intel has traditionally not done SoCs. One reason is that no single SoC fits all purposes. ARM handles that by licensing: A large number of different companies make an even larger number of different SoCs by integrating their own peripherals around ARM cores. Intel doesn't license its cores.

So if Intel wants to get into the IoT market, they should start licensing. The x86 platform probably has too much complexity baggage to compete effectively against ARM in that market, so Intel should design a simple 64-bit microprocessor that they can license to SoC builders.

Alternatively, Intel could gets its income by fabricating processors from other companies on its foundries. Intel has pretty good fabrication technology, so if it can't compete on processor sales, it might very well compete on chip fabrication.

4
0

How to build a real lightsabre

Torben Mogensen

Plasma?

The idea of using a filament to produce an electric field to ionize the gas has the problem that it is fragile and likely to melt when surrounded by hot plasma. 27escape proposed using magnetic fields, and that has more merit. After all, this is what fusion reactors uses to contain plasma that is easily hot enough for a light sabre. This could also explain the sounds when light sabres clash (the magnetic fields interfere and create extra ionisation) and even the fact that they stop each other: If the fields have the same polarity, they would repel. But it would need serious trickery to create a strong, shaped magnetic field from something the size and shape of a light-sabre handle.

2
0

Meet ARM1, grandfather of today's mobe, tablet CPUs – watch it crunch code live in a browser

Torben Mogensen

Re: Conditional execution

Conditional execution was in Thumb2 replaced by an if-then-else instruction that specifies which of the following up to four instructions are executed when the condition is true and which are executed when the condition is false. Specifying ahead of time is better for pipelining, ARM64 has, IIRC, done away with generalized conditional execution entirely, except for jumps. I suspect this is to make implementation simpler and because branch prediction can make jumps almost free, so all you would save with conditional instructions is code space.

0
0
Torben Mogensen

Re: MLA

IIRC, the MUL and MLA instructions took four bits per cycle from the first operand, so a multiplication could take up to 8 cycles. This also meant that it would be an advantage to have the smallest number as the first operand, so multiplication terminates early.

Expanding a constant-multiply to shifts and adds speeds up the computation only if the constant is relatively large and has few 1-bits (a bit simplified, as you can handle many 1-bits if you also use subtraction, so it is really the number of changes between 1-bits and 0-bits that count). But multiplying by, say, 255 or 257 was indeed faster to do by shift-and-add/subtract.

0
0
Torben Mogensen

Re: "...[Acorn] imploded..."

AC wrote: 'Code density is a good benchmark of the "goodness" of an ISA that doesn't basically boil down to "it's good because I like it, that makes it good".'

Code density is only one dimension of "goodness", and it is one of the hardest to measure. If you measure compiled code, the density depends as much on the compiler (and optimisation flags) as it does on the processor, and if you measure hand-written code, it depends a lot on whether the code was written for compactness or speed and how much effort the programmer put into this. So you should expect 10-20% error on such benchmarks. Also, for very large programs, the difference in code density is provably negligible: You can write an emulator for the more compact code in constant space, and the larger the code is, the smaller a proportion of the code size is taken by the emulator. This is basically what byte code formats (such as JVM) are for.

I agree that the original ARM ISA is not "optimal" when it comes to code density, but it was in the same ballpark as 80386 (using 32-bit code). The main reason ARM made an effort to further reduce code size and Intel did not was because ARM targeted small embedded systems and Intel targeted PCs and servers, where code density is not so important. Also, Thumb was designed for use on systems where the data bus was 8 or 16-bits wide, so having to read only 16 bits per instruction sped up code execution. The original ARM was not designed for code density, but for simplicity and speed.

3
0
Torben Mogensen

Re: "...[Acorn] imploded..."

Asdf wrote: " Intel has tried repeatedly to kill their abomination but the market won't let them"

That is mainly because the processors that Intel designed to replace the x86 were utter crap. Most people vaguely remember the Itanium failure, but few these days recall the iAPX 432, which was supposed to replace the 8080. Due to delays, Intel decided to make a "stop-gap" solution called 8086 for use until the 432 was ready. While Intel managed to make functional 432 processors, they ran extremely slow, partly because of an object-oriented data model and partly due to bit-level alignment of data access. Parts of the memory-protection hardware made it into the 80286 and later x86 designs, but the rest was scrapped. Itanium did not do much better, so Intel had to copy AMD's 64-bit x86 design, which must have been a blow to their pride.

If Intel had designed a simple 32-bit processor back in the early 1980s, ARM probably would not have been. Acorn designed the ARM not because they wanted to compete with x86 and other processors, but because they were not satisfied with the current commercial selection of 16/32 bit microprocessor (mainly Intel 8086, Motorola 68000, Zilog Z8000 and National 32016). If there had been a good and cheap 16/32-bit design commercially available, Acorn would have picked that.

6
0

Let's NUKE MARS to make it more like home says Elon Musk

Torben Mogensen

Comets!

In Kim Stanley Robinson's Mars trilogy (which is highly optimistic in terms of technology, BTW), they send comets to skim the atmosphere of Mars, shedding water vapour as they go. This seems like a safer way to add water vapour (which is also a greenhouse gas) to the atmosphere. It would require a lot of comets, but it is still better than nukes.

But I agree that terraforming Mars will always be rather iffy, because it is small, far from the sun, and inactive geologically.

0
0

Silicon-happy ARM engorges its profits by a third – so its shares dip

Torben Mogensen

Share prices

Given today's focus on profit from short-term fluctuations in share prices (even down to milliseconds), share prices are highly volatile and has very little to do with the profitability of the company. Since trading in share prices is a zero-sum game, the main effect is that the clever (and fast) take money from the not-so clever (and not-so fast). The society as a whole gains zip from this. Quite the opposite, in fact, as we have to bail out banks that made the wrong bets, while the banks that make the right bets channel their profit to huge bonuses to its CEO, CFO etc, who immediately send it to the Cayman Islands.

So, IMO, shares should only be traded at par, so the only potential gain from shares would be payment of dividends. This is, by its nature, not a zero-sum game, and millisecond trading will not profit from it.

I don't see this happening, though. Not only will many financial institutions do what they can to prevent it, but they will find ways around a law that requires shares to be sold at a fixed price: Rather than trading the shares themselves at varying prices, they will trade papers that promise to buy or sell shares (at the fixed price) at a specified later date. These papers will be subject to price fluctuations, unless the laws forbid these too. And if they do, the banks will just find some other form of derivative to trade.

0
0

F# earns Syme top Royal Academy of Engineering award

Torben Mogensen

Cross-platform

"Cross-platform? Up to a point. F# seems to be tied to Visual Studio".

I use Emacs for F# programming. Also, MS is releasing an open-source, cut-down version of Visual Studio for Linux and MacOS, so even if you want an IDE, you are not tied to Windows.

My main gripe with F# is that they based on O'Caml instead of Standard ML. This makes the syntax (especially for pattern-matching) a bit clumsy in places. But, overall, F# is a big improvement over C#, Java, C++ and a host of other mainstream languages. If Apple's Swift is made truly cross-platform, it may rival F#, though.

0
0

JavaScript creator Eich's latest project: KILL JAVASCRIPT

Torben Mogensen

Clean slate

IMO, the idea of a low-level language supported efficiently by all browsers is a great idea. But it should be designed from a clean slate instead of being based on Javascript. That would allow such things as verifiable code (that carries proof hints to speed up verification), vector parallelism that can be executed on the graphics processor, and several more things that the baggage of Javascript hinders. Also, Asm.js does not (as far as I know) support garbage collection, so every language needs to roll its own. Since nearly every high-level language these days uses GC, this ought to be standard on a virtual machine.

0
0

Apple to tailor Swift into fully open-source language – for Linux, too

Torben Mogensen

Re: thoughts on Swift as a general language?

JLV wrote: "And on a more general note, what are the design features that you disagree with?"

I admit that I may not be entirely up to date with the newest developments, but from what I remember from reading about it a while back:

- The choice of reference counting GC. It is slow and it necessitates using weak pointer if you create cyclic structures such as doubly-linked lists. There are concurrent GC algorithms that would be much better.

- That only objects are boxed. This makes it impossible to create a recursive enumerate without using objects.

- A rather verbose syntax for enumerates, as well as a few other odd syntactic choices.

1
0

Hubble spots Pluto's moons are a chaotic mess of tumbling rock

Torben Mogensen

Re: "We are learning that chaos may be a common trait of binary systems,"

Actually, the three-body problem IS chaotic in the modern, mathematical sense. There are non-chaotic three-body configurations (for example, when several small bodies orbit a much larger mass in near-circular orbits), but the general problem is chaotic. Smaller moons closely orbiting two large co-orbiting bodes are almost bound to be a chaotic system.

10
0

Singapore's prime minister releases source code for his hand-coded Sudoku-solver

Torben Mogensen

Haskell

He mentioned wanting to learn Haskell. Here is a link to a small Haskell program for solving Sudoku: http://web.math.unifi.it/users/maggesi/haskell_sudoku_solver.html

1
0

FOCUS! 7680 x 4320 notebook and fondleslab screens are coming

Torben Mogensen

Wall displays

That resolution only makes sense for wall displays, but a display port could drive one such.

This drive for higher resolution resembles the similar drive for digital cameras, where resolutions on most cameras are now much higher than the accuracy of the lenses. What is needed for digital cameras is better light sensitivity instead.

On a laptop or tablet screen 4K is more than enough (3K is IMO the useful limit for less than 17" screens). Like in cameras, what is needed is not more pixels. On screens what is needed is better colour reproduction and better visibility is sunlight. Reflected-light screens (like Qualcomm's Mirasol, once fully developed) may be the future.

7
0

Your anonymous code contributions probably aren't: boffins

Torben Mogensen

Obfuscation

Most code obfuscation is done at the lexical level: whitespace and comments are eliminated, variables and procedures are renamed, macros are expanded, and so on. As mentioned in the article, such tools can not hide coding style, as this goes far beyond lexical details. So a good obfuscation tool must work on the semantic level of the program: It must replace code with semantically equivalent code using more than just local syntactic or lexical transformations. This is very difficult to do, especially if the language semantics is loosely specified (*cough* C *cough*). Writing such a tool is (at least) as complicated as writing a compiler, which is why it is rarely done. But there is research that points the way: http://dl.acm.org/citation.cfm?id=2103761

2
0
Torben Mogensen

Time versus code length

That competitors who complete more tasks in code competitions have, on average, longer programs than those who compete fewer tasks is not surprising. Mark Twain is attributed for ending a letter with "I apologize for the length of this letter. If I had had more time, it would have been shorter". The same is true for programming; It takes more time to write shorter code. It is often faster to cut-and-paste and do local modifications than to make a parameterised procedure to cover all cases, and sometimes it is faster to special-case on different inputs than to make a general solution, which often requires insights that take too long to obtain when you are pressed for time. And you certainly don't want to spend time on simplifying code that works. Good competition programmers also often have a standard skeleton program that they modify for each task, because it is faster than starting from scratch. So there will often be procedures that the programmers do not bother to remove even if they don't use them. They don't harm, so why use time to remove them?

Coding competitions are very different from normal programming: The problems are small and self-contained, so you don't have to worry about modularisation or readability of the code (in a few hours, nobody will ever look at the code again), and the process is more explorative than normal coding. So you can't draw conclusions about general coding style from such competitions.

14
0

Languages don't breed bugs, PEOPLE breed bugs, say boffins

Torben Mogensen

Erlang and more

The article mentions three factors that (somewhat) improve code quality: Strong typing, static typing and managed memory. Erlang has strong typing and managed memory, but it is dynamically types. So by the (somewhat weak) conclusions in the paper, it is no surprise that Erlang is close to the average.

What would be interesting is factoring out the number of years the programmers have worked with their language: C and C++ programmers have at least potential to have worked longer with their language than Erlang, TypeScript and Haskell programmers, and it is very likely the case that programmers who know their language intimately will make fewer errors. This also makes a case for languages that are sufficiently simple that you can actually manage to learn all of it.

Also, these days, huge libraries mean that you quickly can produce useful code in almost any language, as long as you stay within the scope of the libraries. This makes the actual properties of the language itself largely irrelevant, again if you stay within the scope of the libraries. So a true test of language (isolated from library) productivity/quality would require giving programmers a task where they can not make any significant use of non-trivial library functions, or where you deliberately forbid use of anything but the most basic libraries, e.g., by limiting the total library code used to, say, 1000 lines.

4
0

AMD-AMMIT! Hundreds face axe at chip maker as PC, graphics crash

Torben Mogensen

Sell to ARM?

If they split off the PC-processor and graphics department in a separate unit, it is possible that they could sell it to ARM. Not so much for the products, but for the patents and the technology.

1
0

Is that a 64-bit ARM Warrior in your pocket? No, it's MIPS64

Torben Mogensen

Re: RISC, not IRONIC

While it is true that these features are what is generally seen to distinguish RISC from CISC, the original MIPS design has a large part in that definition: It was (alongside the Berkeley RISC processor, which is the forefather of SPARC) basically what defined the concept.

I have long thought that ARM should have moved the PC out of the numbered registers when they moved the status register to a separate, unnumbered register. While you save a few instructions by not having to make separate instructions for saving/loading the PC, PC-relative loads, etc., most instructions that work on general registers are meaningless to use with the PC. And in all but the simplest pipelined implementations, it complicates the hardware to make special cases for R15 (the PC). So this move is hardly surprising. I'm less sure about the always-0 register. I think it would be better to avoid this (gaining an extra register), and make a few extra instructions for the cases where it would be useful, e.g., comparing to zero.

And while code density is less of an issue now than ten years ago, I think ARM should have designed a mixed 16/32-bit instruction format. For simplicity, you could require 32-bit alignment of 32-bit instructions, so you would always use 16-bit instructions in pairs, and branch targets could likewise be 32-bit aligned. For example, a 32-bit word starting with two one-bits could signify that the remaining 30 bits encode two 15-bit instructions where all other combinations of the two first bits encode 32-bit instructions.

0
0

NVIDIA claims first 64-bit ARMv8 SoC for Androids

Torben Mogensen

Re: Microcode

Though the 64-bit ARM instruction set is vary simple (looks more like MIPS than 32-bit ARM), and could easily be implemented directly on a simple pipelined 80's style CPU, most modern CPUs are superscalar, which means that they internally are variants of dataflow machines: Instructions are executed when their operands are available and not in the order they are written in the code, and they use a much larger internal register set than the visible register set, renaming visible registers to internal registers on the fly. Compiling blocks of ARM code to the dataflow machine and storing this makes sense, as you can skip the decode, schedule and register-renaming stages of the execution pipeline. In particular, that would make mispredicted jumps run faster, as you don't get quite as large pipeline stalls.

3
0

Four-pronged ARM-based Mac rumor channels Rasputin

Torben Mogensen

Reason #5: Control

Apple has (almost) always wanted as much as possible control over their hardware platform, both to tune hardware and software to each other but also, equally important, to prevent people running their software on machines not made by Apple.

By making their own System-on-Chip (SoC), they can pretty much ensure that only computers made by Apple can run their software. As for performance, the gap between ARM and Intel is dwindling now that ARM has a line of 64-bit processors. And, as the article said, MacBooks are not known as power houses anyway.

Somebody mentioned migration as an issue, but this is much less an issue than it was at the previous processor switches (from 68K to PPC and from PPC to x86), as most software is now written in high-level languages that can easily be compiled for other processors. Also, MacOSX and IOS themselves already share a large code base that is just compiled for the different platforms.

So, technically, I see no major hindrance. The main reason to stay with x86 would be if Apple could pressure Intel to give them really good prices by threatening to switch if they don't.

1
0

Game of Thrones written on brutal medieval word processor and OS

Torben Mogensen

Word bad, raw text editor good

Apart from not really needing formatting when writing a novel (apart from chapter headings and occasional blank lines and, if you write like Jonathan Stroud or Susanna Clarke, footnotes), Word takes up a lot of screen estate for menus and similar stuff, so you see relatively less of your text when writing.

A raw text editor (VI, Emacs, gedit, ...) shows more text (and often more legibly) than Word, it loads faster, it scrolls faster and the text files are much smaller, so you can keep every previous version around even on a tiny machine. And raw text files can easily be imported into whatever software the publisher uses for the final typesetting.

0
0

The weird and wonderful mind of H.R Giger is no more

Torben Mogensen

Dune influence

Giger do not seem to have influenced Lynch's Dune film much, if at all. Giger did, however, make a lot of concept art for Jodorowsky's (sadly uncompleted) Dune project, in particular designs for the Harkonnen palace and also some designs for another uncompleted Dune adaptation by DIno de Laurentis.

1
0

Software needs meaty cores, not thin, stringy ARMs, says Intel

Torben Mogensen

Keeping with horse-drawn carriages

While Intel is correct in saying that most software these days is written for single-core, sequential processors, and that it is, indeed, easier to do so, there is little doubt that the future belongs to massive parallelism from many small cores rather than speedy single cores: At a given technology, doubling the clock speed will roughly quadruple power use, because you both need more power to make the transistors switch faster and because every switch costs power. For the same power budget, you can get four cores, which gives you twice the total compute power. It is true that there are inherently sequential problems, but these are fairly rare, and the jobs that require most compute power (cryptoanalysis, data mining, image processing, graphics, ...) are typically easy to make parallel.

Intel's strength is in making fast cores, but they are also power-hungry and expensive. The former because that didn't matter much for desktop PCs and servers up through the 90s and 00s, and the latter because Intel had a de-facto monopoly on x86 processors for PCs and servers, and most 3rd-party software was written exclusively for x86. These days, power matters more: Desktop PCs are more or less a thing of the past (excepting with a few hardcore gamers) and power use is increasingly an issue in data centres. Intel is trying to adapt, but it fears to lose its dominant position before the adaptation is complete. Hence, these bombastic claims.

5
2

How bad WAS the parking situation in Middelfart* in 2013?

Torben Mogensen

REALLY unfortunate Danish town names

There are some towns in Denmark that even the locals find embarrassing: Tarm (intestine, though originally used for any long and narrow passage), Hørmested (smelly place, origin probably from "horn"), Bøvl (trouble, originally "bend"), and Lem (member, originally "barrow place").

Then there are some that are just mildly funny, such as Sengeløse (without beds), Springforbi (jump past), Tappernøje (taps liquid precisely), Bagsværd (back sword, though originally back sward) and Middelfart (middle speed, originally middle ferry passage), though we can see why some English speakers find that name a bit embarrassing.

0
0
Torben Mogensen

Middelfart

I can't see how that name is unfortunate. In Danish the meaning is roughly "Middle seafaring" and alludes to the fact that there used to be ferry services from Middelfart to Jutland. Now there's a bridge, but you do pass Middelfart if you go from the island Fyn to Jutland. "Fart" can also mean movement or speed in general, so there is a joke that goes like this: "Q: Why are there so many speeding tickets between Odense and Fredericia? A: Because you have to go over Middelfart." (middle speed).

By the same reasoning you call Middelfart unfortunate, Middlesex is downright disastrous.

4
1

AMD tries to kickstart ARM-for-servers ecosystem

Torben Mogensen

Software

Unlike PC software, a lot of server software are written portably, at least across multiple versions of Unix/Linux. This is partly because the server landscape already supports several processor architectures: x86, x64, Sparc, and even Itanium, but also because server software doesn't use machine-specific GUI APIs. So it is relatively painless to port server software from one Unix/Linux/BSD platform to another. There may be differences in how compilers handle corner cases (due to the woefully underspecified C standard) and implicit assumptions about byte order and how unaligned access is handled, but it is still a lot easier than, say, porting Windows software to Linux or MacOS.

So, while software pretty much locked desktop users to the Windows/x86 platform, there has never been quite the same adscription to a single platform in the server world.

6
0

Page:

Forums

Biting the hand that feeds IT © 1998–2018