Linux Getting Extensive x86 Assembly Code Refresh 209
jones_supa writes: A massive x86 assembly code spring cleaning has been done in a pull request that is to end up in Linux 4.1. The developers have tried testing the code on many different x86 boxes, but there's risk of regression when exposing the code to many more systems in the days and weeks ahead. That being said, the list of improvements is excellent. There are over 100 separate cleanups, restructuring changes, speedups and fixes in the x86 system call, IRQ, trap and other entry code, part of a heroic effort to deobfuscate a decade old spaghetti assembly code and its C code dependencies.
Debt (Score:5, Insightful)
Technical Debt haunts you.
Re:Debt (Score:5, Insightful)
Yes, if it weren't for the idea that I could change jobs if I needed to, I'd have been full of hopless dread at just about most places I've worked. The sad thing is, in some places the majority of technical debt is creating in the first year of the company's existence, during the hurry-up-already startup phase.
Re: (Score:3)
Re: (Score:3)
Thats not really the debt though. The debt is when you get a giant wad of funding and dont take the time to greenfield your cludge app.
No, that is debt, and in many cases it is the biggest single source of debt, as Darinbob said. Failing to rewrite your kludge app is just failing to pay down your debt. Whether or not the moment you get a giant wad of funding is the right time to do that depends on the context.
Re:Wouldn't a re-write be more fruitful? (Score:4, Insightful)
I don't really know why.
Users will say "But it works, we don't want to change waaagh scary" while simultaneously reporting 237 bugs all of which are OMG critical. Management will assume that it's cheaper, because existing stuff is already there so it's wasteful not to use it.
Now it's true that once a load of crufty business rules have built up with 17 levels of nested conditionals it can be risky to try and replicate it for fear of missing some obscure case that's bound to occur at an inconvenient time for a key customer. There's no documentation, of course. Or if there is it's the source code, six revisions behind, pasted into a word document with three screenshots taken as BMPs so the whole thing is 1.5G. This alone can make you say "sod it".
I can't find the correct phrase but maybe it's just a false analogy with physical things. Like reusing wood from an old shed to build a deck possibly is cheaper.
Reroofing is close analogy (Score:2)
Building codes generally allow homeowners to install a second layer of asphalt shingles over an existing layer of same. But once you're considering a 3rd layer, building codes generally require the entire roof to be stripped and redone.
Software should be the same way.
Re: (Score:3)
I don't really know why. Users will say "But it works, we don't want to change waaagh scary" while simultaneously reporting 237 bugs all of which are OMG critical.
Because if you did it wrong the first time, there's no chance that you're going to do it better the second time. You'll end up leaving out crucial functionality or something.
If you don't know how to clean up a codebase in-place by rewriting a little at a time, then you aren't skilled enough to do a rewrite from scratch.
Re: (Score:2)
Why are you assuming the person fixing it is the one who originally wrote it?
Re: (Score:2)
Re: (Score:3)
Worst of all is when they embark on a rewrite and give up half way through. I was involved in a project to port a C++/ActiveX based system to .NET forms. They ported most of the major views but left a lot of the minor s
Re: (Score:2)
Worst of all is when they embark on a rewrite and give up half way through.
I saw something similar happen at my employer. A newer employee was sent on a mostly solo project to rewrite some of the core of our product, to make it easier to make some planned enhancements. Things didn't immediately work perfectly, and some of the founding employees fought the changes. Since they were necessary for the next release, and there wasn't another option for the features that we were required to make available, we ended up with two parallel sections of code that did basically the same thing b
Re: (Score:2)
Answer to both questions: Management (Score:2)
Management pressure forces even good developers to produce. Sometimes, against your better judgement, you have to go for the quick fix to meet a deadline (or not exceed a deadline by too much). Or, developers make a proof-of-concept or prototype, and management says "ship that".
Once management has its grubby hands on existing codebase, it ignores the accrued technical debt, poo-poos developers warnings to rewrite some stuff that was thrown together in the heat of battle, and never funds general background c
Not with a bad set of requirements (Score:2)
Wouldn't a total re-write be the right thing to do instead?
Yes, if you can get the proper requirements. (This does not apply to the current article, since I assume that the requirements for these syscalls, etc. are well described.)
On most business systems, especially one that us written over the course of a few months, the requirements are just as spaghetti as the code, so rewriting the system from scratch might also rewriting the requirements from scratch, which is a monumental task if it already have customers with different configurations.
On a more humorou
Re: (Score:2)
Because it's always cheaper and faster to kludge the next feature on to make the next shipment or put out the current fire than it is to rewrite. If they would take a step back, look at what they want to be in a year or two they'd realize that the time invested would pay for itself over and over. But most places don't have that kind of foresight, or the manpower to do that while also dealing with all/ the short-term crises arising from the current codebase.
Can we be sure there are no exploits? (Score:2, Insightful)
We live in interesting times these days. With a changeset so big, and involving assembly code that isn't as easy to understand as C code, how can we really be sure that no exploits have been introduced? How extensively have these changes been reviewed to ensure there are no exploits or potential exploits being sneaked in?
Re:Can we be sure there are no exploits? (Score:5, Insightful)
The only way to truly understand C code is to read the disassembly. Otherwise you are only assuming what the compiler is emitting.
Re: (Score:2, Funny)
That does not fit in with the concepts of 'abstraction' that are fashionable. No 'coder' should really need to understand the actual code the hardware runs. It's all rife with gotos and other icky things. Pointers (physical memory addresses) and stuff get revealed.
No! Mommy! Make the bad hardware go away!
Re:Can we be sure there are no exploits? (Score:4, Insightful)
Javascript guy meanwhile regards the C guy as a primitive, bearded man from the hills who labors all day on some stupid library that is ten layers of stack between that mortar and pestle and the awesome browser-art he's creating.
Systems administrators wish everyone would run off and die because they are all irritating, stupid whiners.
DBAs are just smug because nobody else understands their schemas and, hey, this is where it all happens.
Networking would rather be back below the hold, No, the network isn't broken, your app is buggy or the stupid website you're trying to load is just slow..
Help desk guys meanwhile consider themselves the cocks of the walk because, generally, their camaraderie and opportunity to interact with more regular people means their souls haven't been totally crushed.
Re: (Score:3, Funny)
Jokes on you. I'm building a VM language in ASM.js and VM bytecode. I get to deal with memory management and multiprocessing issues that are unique to ASM.js. Since the code compiles to opcode which can then be output as "native" ASM.js (which is then mostly compiled to machine code by browsers) or it can run blazing fast on the C VM implementation with its (native) JiT optimizations. Since the platform is meant to be an extremely portable high level and systems level language I'm currently implementing
Re: (Score:3, Funny)
That was the most single most hipster post I've read on /. all year.
Re: (Score:2)
Re: (Score:2)
Chorus:
"Well, It's Simple! All You Have To Do Is..."
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
In general, SAs are a dying breed. Yes there's some still around and there will be in the future, but many of them are being folded into 'DevOps' which is really developers that use short-term instances to do the job they need. Since each single instance does one job, does it well, then gets destroyed there's no need to have someone handle the long term care and feeding. Since you block everything in a VPC and you don't have users connecting directly there's no security or user administration issues. S
Re: (Score:2)
I program in logic gates you insensitive clod?
Re: (Score:3)
Signal levels are another abstraction. Come back when you care about electron band gaps.
Re: (Score:3)
Because a physics model isn't an abstraction?
Obligatory https://xkcd.com/435/ [xkcd.com]
Re: (Score:2)
You were supposed to reply with a lower level abstraction. Please keep up.
Re: (Score:3)
Re: (Score:2)
Get yourself a 65CE02. Every opcode is well defined and supported. 8B is STY abs,X
Re: (Score:2)
It isn't really hard? Big job = lots of people involved.
Re: (Score:3)
Well... basic procedures using only MOV/CMP/JMP is not something that even linux really needs to code in assembly. What is being talked about here is primarily the trap, exception, syscall, signal trampoline, and interrupt entry and exit mechanisms. Also thread switch code can get pretty complex because there is a lot more hardware state involved than just the basic register set. When you start having to deal with SWAPGS and MSR registers, you've really gone down the rabbit hole.
-Matt
Re:Can we be sure there are no exploits? (Score:4, Interesting)
The first instruction in the Intel Architecture Reference (Part 2: Instruction Set Reference) is AAA, which is named after the noise made by people forced to read x86 assembly. It is short for 'ASCII Adjust After Addition' (yes, that should be AAAA, but that would be too consistent for Intel). This instruction exists to convert the result of binary addition into the result of the corresponding BCD addition.
Or, to put it in simpler terms: Anyone who thinks x86 assembly is not that difficult to understand is certifiably batshit insane.
Re: (Score:2)
Yeah, yeah, All You Have To Do, yada yada.
Unlike the old dinosaur mainframes, modern microprocessors run internal pipe lines and what instructions follow what other instructions can make a big different.
Aside from that, one reason that raw assembly is no longer the cult favorite it used to be is that the average C statement is probably going to produce 5-10 machine-language instructions. More instructions means more work to create or replace them, more places for potential bugs, and less flexibility to make
Re: (Score:3)
Because, among other things, compilers (such as C) can automatically generate pipeline-friendly machine language. All that extra bookkeeping is trivial for an automated process.
And a compiler can re-optimize the entire module every time they compile.
Hand-optimized assembly lost it when IBM introduced Pascal/VS. I COULD optimize code as good or better than it did, but considering that it was doing large-scale register reassignments, the equivalent amount of hand optimization for just one minor source change/
micro vs. mono (Score:3)
Risk of regression (Score:3)
> There's a risk of regression when exposing the code to many more systems
The risk of regression is due to refactoring, not due to testing. Ironic, given that the post cites de-obfuscation as a reason for doing this. Or perhaps our submitter just got an MBA and is learning to think and speak [c2.com] in management-ese [dilbert.com].
It's only a modest refresh (Score:5, Insightful)
It's not a major refresh, only a modest one, and it doesn't really fix the readability issues (which would require a complete rewrite). Linux assembly is a mostly unreadable, badly formatted, macro-happy mess. The assembly in the BSDs is much more elegant and minimalistic.
-Matt
Re:It's only a modest refresh (Score:4, Informative)
+5 Informative / Insightful for parent
For background, the parent comment is Matthew Dillon, compiler and kernel hacker on Amiga/BSD/Linux and founder of DragonFly BSD (fork of FreeBSD).
http://en.wikipedia.org/wiki/D... [wikipedia.org]
Re:It's only a modest refresh (Score:5, Interesting)
It is a modern thing, primarily for two reasons:
(1) As you mentioned, optimization trumped cleanliness. It's not just that a given coder couldn't be bothered wasting his time writing it cleaner: it's that often the choice was between a guy who can write clean code and a guy who can write very messy but highly-optimal code, and the latter would win in the marketplaces (the software, hardware, and programming-job ones). Writing optimal assembly code and organizing a modern large clean codebase in a HLL don't have a ton of skill overlap, all things considered.
(2) As you rewind the clock on programming history, keep in mind that further back there were simply far fewer total programmers in existence, and far fewer working on any given codebase, by orders of magnitude. When you look back far enough, you see major companies launching major projects with a total programming staff of like 1-3 guys. Most of the code ever written in the older decades was the result of heroic one-man efforts. Why bother optimizing for others being able to read your code where there's unlikely to be many of them, and they're all likely to be crazy like you anyways?
So that is how it happens (Score:4, Funny)
Re: (Score:2)
Re: (Score:2)
XNU contains thousands upon thousands of lines of assembly code for both x86 and ARM. Being a microkernel does not preclude the presence of assembly code
Re: (Score:3)
Linux has been obsolete since introducing assembly code. Minux touches the hardware in just 100 lines of code and macosx is a micro kernel as well.
It is 2015 and not 1985
Better not use Minix then, because it also [github.com] has assembly.
Re: (Score:3)
All C code ends up as assembler, anyway. It just gets deleted, most of the time, before you see it.
Re: (Score:2)
Besides, 'assembler' is a part of the toolchain. The language(s) are called 'assembly'.
Re: (Score:3)
Re: (Score:2)
Yep, XNU is a hybrid kernel. It has microkernel parts and monolithic kernel parts.
XNU?!? (Score:2)
Is apple powered by scientology?
Re: (Score:2)
To add your claim that XNU does not follow any microkernel rules is simply false. XNU uses microkernel-style message passing.
Re: (Score:3)
To add your claim that XNU does not follow any microkernel rules is simply false. XNU uses microkernel-style message passing.
XNU has system calls to allow messages to be sent between processes, including sending large amounts of data by page flipping.
It just doesn't happen to use that to implement very much of the UNIX API; it's not used to implement file I/O (that goes through ordinary BSD system calls to in-kernel file systems that are called through a BSD-style VFS) or network I/O (that goes through ordinary BSD system calls to in-kernel networking stacks that are called through a BSD-style kernel socket layer) or much of the
Re:Should be micro kernel (Score:5, Interesting)
Nobody does message passing for basic operations. I actually tried to asynchronize DragonFly's system calls once but it was a disaster. Too much overhead.
On a modern Intel cpu a system call runs around 60nS. If you add a message-passing layer with an optimized path to avoid thread switching that will increase to around 200-300ns. If you actually have to switch threads it increases to around 1.2uS. If you actually have to switch threads AND save/restore the FPU state now you are talking about ~2-3uS. If you have to message pass across cpus then the IPI overhead can be significant... several microseconds just for that, plus cache mastership changes.
And all of those times assume shared memory for the message contents. They're strictly the switch and management overhead.
So, basically, no operating system that is intended to run efficiently can use message-passing for basic operations. Message-passing can only be used in two situations:
(1) When you have to switch threads anyway. That is, if two processes or two threads are messaging each other. Another good example is when you schedule an interrupt thread but cannot immediately switch to it (preempt current thread). If the current thread cannot be preempted then the interrupt thread can be scheduled normally without imposing too much overhead vs the alternative.
(2) When the operation can be batched. In DragonFly we successfully use message-passing for network packets and attain very significant cpu localization benefits from it. It works because packets are batched on fast interfaces anyway. By retaining the batching all the way through the protocol stack we can effectively use message passing and spread the overhead across many packets. The improvement we get from cpu localization, particularly not having to acquire or release locks in the protocol paths, then trumps the messaging overhead.
#2 also works well for data processing pipelines.
-Matt
Re:Should be micro kernel (Score:4, Interesting)
You'd presumably need to add new CPU functionality to allow fast context switches. If I remember correctly, a 20MHz Transputer took about one microsecond to switch threads, because that was one of the primary design goals. Of course, that lead to them building a stack-based CPU where almost nothing had to be saved on a context switch...
Re: (Score:2)
The major problem is not the performance of the CPU.
To pass a message across a protected barrier, it means that you can't use two references to the same data. You must actually make a copy of the data. Everybody thinks that the time spent making the copy is a problem with microkernels that needs to be addressed. But the real problem is not the time to make a copy. The real problem is that you now have two different copies of the same data. And when you modify one copy of the data, to update some of the stat
Re: (Score:3)
As I understand it, NeXT / OSX started with a micro-kernel philosophy and then introduced some monolithic kernel concepts to address the performance bottleneck of messaging between true micro modules.
Meanwhile Linux starts as a monolithic kernel, but introduced (un)loadable modules to address maintainability and extendability.
So if we described it as a continuum with 'pure microkernel' being a '1' and pure monolithic kernel being a '10', then OSX would be something like a '3' and Linux would be a '7'.
Loadable kernel modules have nothing to do with microkernels. A truly micro microkernel wouldn't need loadable kernel modules because all the loadable functionality would run in userland; plenty of monolithic kernels have loadable kernel modules.
And OS X is a lot further from "pure microkernel" than 3. The "monolithic kernel concepts" include "running the networking stack in the kernel, standard BSD-style", "running the file systems in the kernel, standard BSD-style", and "implementing most process and V
Re:Should be micro kernel (Score:5, Insightful)
I'm sure you're right, though they have something to do with micokernels. There was Linus interview from a few years back explaining his preference for the monolithic approach, and he explained that modules were introduced to give most of the benefits of the microkernel, without the drawbacks.
I'd have to see that interview to believe that's exactly what he said. In this essay by him [wccnet.edu], he says
but doesn't at all tie that to microkernels.
Loadable kernel modules in UN*Xes date back at least to SunOS 4.1.3 [unixdev.net] and AIX 3.0 [bitsavers.org] in the early 1990's. I'm not sure they were introduced to compete with microkernels.
Re: (Score:2)
I can't find the article now. It was years ago. Perhaps I misunderstood it. But I think it meant something like:
That's more like "mechanisms X or Y both allow Z to be accomplished"; the only thing that says X and Y have to do with one another is that they both allow Z to be accomplished, which isn't that much.
Re: (Score:2)
though they have something to do with micokernels
Which isn't that much.
Great, can we agree now that not much is something and not nothing?
Sure, if we'll also agree that "[introducing] (un)loadable modules" to a monolithic kernel "to address maintainability and extendability" does not in the least make that kernel any closer to a microkernel (because, in fact, it doesn't).
In other news Thylacines and Jackals have nothing to do with each other, except they both look like canids and fill similar ecological niches. Apples and oranges . . .
In other other news, Felis catus and Loxodonta africana have nothing to do with each other, except that they have four legs and bear live young.
Srsly, "both are kernels" and "both let you load and unload stuff" isn't much of an ecological niche. True microkernels (not "hybr
Re:Should be micro kernel (Score:4, Interesting)
Just because Minux has only 100 lines of assembly doesn't mean anything about Darwin, even if Darwin has microkernel components, so your association there is a bit fallacious. Unless it's changed recently, Darwin does have microkernel (mach in fact) underpinnings, but a complete FreeBSD subsystem is grafted onto that. So if anything Darwin is a hybrid kernel. Like most real systems out there, it's not a complete microkernel system.
Re: (Score:2)
Micro kernel is not necessarily better. There was a period of time when everyone felt that way, but the fad wore off quickly when no one managed to actually create a micro kernel that ran rings around the competition. Yes, micro kernel is great for adaptability and debugging but in practice the actual consumers don't care about those features.
It's like software layers. You'll see some groups that are utterly adamant about keeping things strictly in layers, yet there are often very noticeable barriers bet
Re: (Score:3)
Micro kernel is not necessarily better.
No, micro kernels are plain worse. The biggest problem with micro kernels is the synchronisation problem you get with distributed state. Imagine a file system that is split up in different tasks, instead of one monolithic blob. Now, one task makes a change, like removing a file. Before the other tasks can make changes to the filesystem, they first need to synchronize to get the latest state. This becomes either terribly inefficient, or a huge mess, and most likely both at the same time.
Minix, for example, s
Re: (Score:2)
Well yes, normally you'd keep related functionality in the same task. In many RTOS environments everything's in a task anyway, it's the normal way to do things. There's isn't necessarily much synchronization of state, as each task maintains its own state (you don't need the file system's latest state in order to interact with it).
The distinction between kernel and application is blurred in many embedded systems. Similarly, the difference between a microkernel and a monolithic kernel can get blurred as a
Re: (Score:2)
I wouldn't say minix is a good example here, performance wise, as it's intended primarily to be an educational tool.
Still, it's worthwhile to examine the problems, and think about how to solve them. Minix has a clear and serious problem with the single threaded filesystem, and its lack of performance. If you want to scale it up to a general purpose computer system (not a small embedded, single purpose design), you're either going to have to a) keep it as a single task but make it smarter, or b) split it up in multiple tasks. Keeping a filesystem as a single task is problematic. For instance, a request comes in that requi
Re: (Score:2)
In a monolithic kernel, none of these problems exist. Every application request that enters the filesystem layer automatically continues in its own independent thread. When it hits an area that requires synchronisation, it briefly acquires a lock (usually without contention), does the work, and releases the lock. This is a much simpler design, with higher performance.
Any particular reason you couldn't do the same thing in a microkernel? I'm envisioning some form of IPC primitive that automatically spawns a lightweight thread to handle each incoming message, which isn't too different from the monolithic kernel approach apart from not having a fixed 1:1 correspondence between the client and server contexts. You would be able to use your shared data structures and locks just as you would in a monolithic kernel, at least within the filesystem code. For anything else, of cou
Re: (Score:2)
It's like software layers. You'll see some groups that are utterly adamant about keeping things strictly in layers, yet there are often very noticeable barriers between the layers that are inefficient both in run time and in developer productivity
Everyone builds things in layers. At a minimum, you have the layer between the CPU and assembly language, between the kernel and userland, and between storage and the 'file' abstraction. There are plenty of other layers because they are helpful.
If the layers get in the way instead of helping, it means that the layers were designed poorly.
Re:Should be micro kernel (Score:5, Funny)
Sometimes theory doesn't live up to reality.
Yes, I've hurd [gnu.org] that before.
Re: (Score:3, Interesting)
I've never seen a true microkernel that has the performance of a monolithic kernel. Nobody wants to buy a new computer and drag it down to a craw
Did you ever use OS-9 [wikipedia.org] from Microware? (not to be confused with OS 9 from Apple)
Back in the day I ran OS-9 on a Tandy Co-Co and had a fully multi-user, pre-emptive multitasking system* running on a 6809E, 8 bit, sub 2MHz CPU. Later on I worked with a variety of industrial computers running OS-9 on 68K based systems and they worked just fine.
* I will give you that I only ever fired up the graphical desktop all of once just to see if it worked. After that I stayed in the command line.
Re: (Score:2)
I implemented Transputer drivers for OS9 running on a 68k in a VME rack back in the day.
It was a clean, simple and well designed OS.
Re: (Score:2)
Re: (Score:2)
The chicklet keyboard was horrible. There were a few 3rd party replacement keyboards that worked pretty well.
Re: (Score:3)
It was a monolithic kernel. One of the interesting features were devices drivers were modules and there was a small device node module which would say stuff like "used module 'serial driver', call it tty4 at IRQ 2 and address 0x454040". The kernel would deal with all IRQs in the hardware and then run the IRQ callback funtion in the proper module. That allowed user level device drivers back in the early 1980s.
Another cool feature was each software module had a CRC so it could detect bad binaries. There
Re: (Score:2)
I've never seen a RISC processor that can match the performance of the best CISC processors. You know, nevermind the fact that tons of money has been poured into CISC processors making them faster and faster.
I hate to be pedantic (I'm lying, I love to be pedantic), but for what measure of performance? For out right single threaded MIPS/FLOPS and Flops/W in certain situations, they do win. For other measures of performance, not so much.
Re: (Score:2)
I wasn't intending on saying that CISC was superior to RISC... what I was more saying is that there has been more money put into CISC processors, and so they develop faster.
It's just a simple fact of money == better access to stuff to make more money.
Re: (Score:2)
I've never seen a RISC processor that can match the performance of the best CISC processors. You know, nevermind the fact that tons of money has been poured into CISC processors making them faster and faster.
Sometimes, it's just a matter of where the attention has been placed.
That's b'cos active development of RISC processors stopped in the last decade, most of them sunk by the hype around the Itanic. Otherwise, the last time you had the big 3 RISC processors - POWER2, PA-RISC and Alpha 21264, they were heavily ahead of the Pentium. Except that most people don't run Dhrystones or SPEC## or other such benchmarks - they run real software, which just wasn't available for most of the above CPUs.
Two things happened since the demise of the PA-RISC, Alpha and MIPS III & IV: fi
Re: (Score:2)
The main reason CISC is faster today is probably more related capital investment needed in production. Intel just have so much more.
This was basically what I was trying to say. More capital investment typically means better outcomes.
Re: (Score:2)
That's cheating.
And inside, a modern x86 processor is actually a giant hardware emulation of x86 instructions with a RISC/VLIW core... You call it cheating, and I call it optimizing.
They second you try a cool trick like migrating a thread to another machine...
But this would happen with a macrokernel as well... you can't just magically make networking overhead disappear...
Re:obfuscation mk2 (Score:4, Funny)
Not replaced, you dummy.
Elevated to a new level.
Re: (Score:3)
I find your signature incredibly relevant to your post.
Re: (Score:3, Interesting)
Re:Cruft (Score:5, Informative)
For some time now, Mark Russinovich at Microsoft has been talking about just how bad the Windows kernel was/is in his blog.
I think you are confused. It was not Mark Russinovich, but rather Linus Torvalds, and he was talking about the Linux kernel [theregister.co.uk], not the Windows kernel.
"I mean, sometimes it's a bit sad that we are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse."
Glad I could help.
Re: (Score:3, Insightful)
if they want to audit those stale old things for correctness and performance, and make them more readable for future generations, and
do the testing and review to make sure they haven't fucked them up
then good for them. i mean really good for them.
any code - especially the kernel - isn't a concrete artifact, its a process. an organism.
heathy organisms eliminate their wastes
and a 2% performance bump in system call overhead isn't anything to sneeze at
Re: (Score:2)
Re: (Score:2)
Re:If It Ain't Broke, Don't Fix It! (Score:4, Insightful)
I am "in Software" since ~25 years. I also hold a degree as a Software Engineer.
People who obsess about rewriting old code just because it's old tend to forget that in that old code are many bug fixes for edge cases found over the years. It was well documented and part of my education to know and understand that rewriting often caused those same bugs to surface again.
Best practice is to run both the old and new software in tandem for a while and verify the results. In reality no organization besides NASA will do that.
Re: (Score:3)
Re: (Score:2)
"unless a mistake"
"should be preserved"
= best practice is to know and understand that the old bugs will resurface. I.e, there's a cost to do the rewrite (no matter if you call it refactoring or not) that will affect the business for some time after deployment.
Your Software Engineering education seems to be a bit lacking.
Re: (Score:3)
... thus "very few organizations besides NASA".
A lot of people seem to miss the point on how the ideal lab condition doesn't carry over into real world organizations.
Re: (Score:2)
It always disappointing to me when inexperienced software developers confuse the meanings of "refactoring" and "rewriting."
Re:If It Ain't Broke, Don't Fix It! (Score:4, Insightful)
You're operating on the mistaken assumption that code that works now will always work and never need to be modified. You can't leave anything but the simplest things alone forever, because changes to the context/world will eventually require changes to it. If it's spaghetti code, that's going to be causing future bugs that are going to be non-obvious and difficult to discover.
Re:Speedups? (Score:4, Informative)
> There are over 100 separate ... speedups
The last time I looked, which was quite a few years ago TBH, the BSDs have, IIRC, less than 100 lines of x86 assembly, in the bootstrap.
From relatively-recent FreeBSD:
It's about 45,000 lines in Linux 3.19's arch/x86. A fair bit of that is crypto code, presumably either generally hand-optimized or using various new instructions to do various crypto calculations.
Re:Speedups? (Score:5, Interesting)
Re: (Score:2)
If you consider that the C compiler itself uses assembly to make the basic operations work in the libraries, and that all C code is built on assembly libraries, then it makes the whole argument kind of silly, doesn't it?
ALL the kernel code is assembly on Linux and BSD, some of it is just raw assembly, and other bits of it are assembly encoded in "C".
The couple in that most languages and VMs are written in C ... as well as all the libraries that these things depend on to actually get something else done ...
Re: (Score:2)
>> ALL the kernel code is assembly on Linux and BSD, some of it is just raw assembly,
Yes, but the compiler is a few orders of magnitude more reliable than a human when generating assembly
Re: (Score:3, Insightful)
Who can sight read assembly anymore?
Everybody who is interested in "How Things Work" can read assemblly code. Those who depend on hopes and prayers do not.
Re: (Score:2, Informative)
Who can sight read assembly anymore?
Anyone who reasonably calls themselves a programmer.
Re: (Score:2)
this is going to mean a *big* hump for everyone
Giggity.
Re: (Score:2)
I'm waiting for Intel to integrate systemd in the next core update.
Re: (Score:2)