>not using Unikernels

year of our lord 2014

http://anil.recoil.org/papers/2013-asplos-mirage.pdf

anil recoil

ANAL RECOIL

my ani has recoil

Breaking news: systems that perform all tasks using multiple threads in a single process outperform systems that use multiple processes and a kernel running atop a hypervisor. Film at eleven. (I think it's telling that many of the graphs don't bother to show include data for Linux running on the bare metal...)

High performance computing started fighting this battle a while ago. It turns out that maintaining infrastructure and porting applications to use these custom exokernels is a lot of work! Ultimately the guys at Scandia decided to put aside their scratch-written compute node kernels and replace them with yet another (heavily modified) Linux kernel. Last I checked they were still having problems achieving performance parity, though...

Processes are overrated. Real Lisp OS will run all threads in a single address space, achieving lightning fast speed. The only problem is making GC predictable.

>>5
As long as they have separate GC roots it wouldn't be that bad.

(If you want to share data, try weak references and inter-process leases.)

>>6

Single root can point to a lot of memory (gigabytes). Collecting it would produce noticeable pause (GUI would become unresponsive).

And you can't simply abandon GC, because manual memory management would break security and require protected address space again.

>>1
Fuck off with your pseudoquotations.

Did you know that unikernels existed since the birth of the electronic computer? In those early times, the application program had to directly program the computer i.e. the program was the kernel and the OS.

>>9
That's what you do for simple embedded systems. Boot from ROM directly into the app, there is no OS.

>>9

http://en.wikipedia.org/wiki/PC_booter

>>7
No kidding.

And you can't simply abandon GC, because manual memory management would break security and require protected address space again.

Both sides of that comma are wrong in isolation and in combination.

You don't need exposed raw pointers for non-GC, eg. Rust (linear types without needing raw pointers), Swift (autorefcount, weakrefs without needing raw pointers.)

>>12

autorefcount, weakrefs

this is GC too, just another kind of it

>>12,13
ARC is also incredibly slow. See this SO question:
http://stackoverflow.com/questions/24101718/swift-performance-sorting-arrays
Where turning off memory management allows Swift to have speed competitive with C, but leaving it on makes an ordinary int sort take over 7 minutes.

>>13
Without a cycle collector RC is not usually considered GC, and has great performance. There are arguments either way that get caught up in semantics, but the fact is RC is fundamentally different than GC in the large until you introduce a cycle collector.

>>14
That's a lie. -Ofast needed to bring the code up to speed has no effect on memory management. It does turn off most (all?) of the safety checks C doesn't have.

There's some precedent for linear types in Lisp:

http://home.pipeline.com/~hbaker1/LinearLisp.html
http://www.pipeline.com/~hbaker1/Use1Var.html

Philip Wadler has a lot to say about linear types:

http://web.archive.org/web/20030219075959/http://www.research.avayalabs.com/user/wadler/topics/linear-logic.html

Philip Wadler - JEW

>>17

Yeah. You can easily detect a CS kike by inspecting how useful is his work. For example, what practical problems Ray Kurzweil have solved?

>>18
None. He's a pop ``scientist'', on the same level as Michio Kaku and Nigger deGrasse Tyson.

>>18

he produced a synthesizer, which was very good for it's time:
http://www.youtube.com/watch?v=zpRA7S1auwc

>>20

"kurzweil is being misleading... these are not synthetic models or recreations... mike is spot on when he says he cant believe they didnt record the instruments... they DID record the instrument... they used digital samples... NOT modeling...when kurzweil says these are synthetic computer models and not recordings... hes lyng"

>>17-18
Say what you will about Wadler, linear types and monads are movers in modern language and library design.

>>20
I didn't realize that was the same Kurzweil. Turns out he's done something useful after all.

>>21
I don't doubt that sampling was involved, but it would be impossible to reproduce the instruments with sample playback in a standalone unit in 1984. It takes about 2GB to reproduce a single instrument convincingly over its entire range (maybe down to 500MB in the quality used in 1984.) Whomever said he's lying is being far more misleading, the implication being he had at least 30GB of storage, with at least 500MB of fast-access memory per active timbre. We could do that today, 30 years later, just barely.

It's more likely the instruments were sampled, the samples decomposed and used to re-synthesize the instruments. This is analogous to using samples to automatically program patches in a somewhat conventional synthesizer.

But that's all strawman bullshit because the K250 was astounding in its day.

>>22

You can download some old DOS game. They usually include BNK files under 64 kb, which include all General MIDI instruments, which get uploaded to soundboard together with settings on how to playback them.

>>22
take all your knowledge and cram it up my anus

>>23
Still fluffing the strawman? Why stop at 64kb? You can go lower if you want something that sounds awful.

>>24
Your throat seems to be full of shit, so that's probably a better idea, yeah.

>>25

That was really dependent on sample playback settings (not the sample size). For example http://www.youtube.com/watch?v=MVQTTBhuSkQ sound really good, despite using 8-bit samples.

>>26
It sounds nothing like the K250. In terms of authentic instrument quality it's utter garbage. The worst part is XG typically uses a similar process as described in >>22 and there's no excuse for it to sound so much like characteristic MIDI.

>>27
Wow, everybody on here just seems to know about everything.

I bet you could make a thread on the most obscure only somewhat related to computing topic and there will be people here posting accurately and knowledgeably about it. Too bad you're all still retards though.

>>28
We've even got a domain expert on retards!

>>22

It takes about 2GB to reproduce a single instrument convincingly over its entire range (maybe down to 500MB in the quality used in 1984.)
We could do that today, 30 years later, just barely.

Got any citations for these? Is there any reason why we don't algorithmically reproduce this information rather than capture such range of data for use in reproducing natural instruments?

for the Cloud

No, thank you.

>>30

Got any citations for these?

No, I get this from my experience with sampling. The good soundfonts with full range all start at 2GB.

The math is simple enough:

32bit audio (4bytes) * 48000 kHz sampling rate * 2 seconds * 88 notes * 2 channels (stereo) * 128 strike velocities = 8.583168e+09 bytes.

Feel free to tweak those numbers. Two second samples might be a bit high for some instruments, but one second isn't enough even for drums. You probably don't need stereo. Strike velocity is more important than you think.

Is there any reason why we don't algorithmically reproduce this information rather than capture such range of data for use in reproducing natural instruments?

We have been using it, just not everywhere. Why? Because not everyone knows how to do it. Because few samplers support it. Because it's time consuming, expensive.

For my part, I never wished my samplers had this feature. I don't want to painstakingly record something note for note at different velocities. I want to record sounds with an MPC and bang on the drum all day.

>>32
You don't need 128 strike velocities.

Also, 32bit audio, what the fuck.

>>32

my experience with sampling. The good soundfonts with full range all start at 2GB.

if it is bloated, it must be good

32bit audio (4bytes) * 48000 kHz sampling rate * 2 seconds * 88 notes * 2 channels (stereo) * 128 strike velocities = 8.583168e+09 bytes.

what about http://en.wikipedia.org/wiki/Physical_modelling_synthesis ???

The little faggot with the earring and the makeup —
Yeah buddy, that's his own hair —
That little faggot got his own jet airplane;
That little faggot he's a millionaire.

>>33
128 isn't enough in my opinion, but it's standard because that's what you get with MIDI.

32bit audio is the standard now. You can go down to 24 if you want, it's fine for storage. It's not like I'm pushing 96kHz audio here. You could drop the 48kHz to 44.1kHz too.

>>34
What about physical modeling? These are the numbers on sampling to support the claim that the K250 couldn't have been pure sampling. PM synthesis can sound pretty good but that's not at issue.

>>36

K250 used 10 bits samples.

How many of those 32 bits are pure noise?

>>37
Use the formula, Luke.