Slashdot Mirror

← Back to Domains

Domain: nekovm.org

Stories and comments across the archive that link to nekovm.org.

Comments · 14

  1. Re:I run Debian, and I run FreeBSD. by chrysalis · · Score: 1 · on Debian Gets FreeBSD Kernel Support

    FreeBSD can run Linux apps, but this is only through system calls translations. And that system is far from being perfect. FreeBSD-specific bugs and specific behaviors will remain for emulated executables.

    Want an example? The Neko VM ( http://www.nekovm.org/ ) is in the FreeBSD ports tree, but never worked. It crashes with a segfault on any MP system as soon as you create a thread. Why? Because FreeBSD threads have a different behavior than OSX/Linux/Windows/OpenBSD. Neko VM is extremely reliable on Linux. But if you run the Linux version on FreeBSD, it will crash the same way as the native version.

    Running userland software with another kernel is fun, and sometimes it can be useful in order to run blobs (Flash, RAID tools, etc). But it can only be less reliable than what the tools were originally designed for. Plus it lacks testing, and you can't expect upstream developpers of software to test their software on hybrid systems like that.

    Also, it all depends on your own definition of "distro", but PKGSRC supports a lot of operating systems for a long time, with a huge collection of software. But while it's technically polished for that task, software is actually used and tested only on NetBSD and DragonflyBSD. Other systems just receive minimal testing (basically "it compiles". And that testing is mainly automatic).

  2. Re:more important things by 0xABADC0DA · · Score: 1 · on Debating the Linux Process Scheduler

    Don't, however, expect a kernel dev to go off on a tangent that is going to require large amounts of the kernel, some of which he may not have any interest in, to be replaced just because you think it might be a good idea. I linked to the paper to show that other people have demonstrated that it is a good idea. Kernel developers shouldn't care what I think, they should care about facts and about improving their system. Instead they dithering over registers and cache lines when the whole approach is grossly inefficient to begin with in many cases.

    Programs need to take ~6000 cycles between system calls to have only a small 10% overhead just for making the calls, not even to mention the copying of data and setting up fault handlers and such. This is a crazy amount of overhead for some types of programs. And if you can switch a process in 100 cycles versus 2000 then the scheduler doesn't even need to be as fair.

    Mind giving me and installing an electric engine to put in [my truck] Here you go. It's your truck, you put it in.

    You act as if the entire kernel would have to be rewritten and maybe even userspace, but that is not so. They would need to make some changes like being able to do anything from an in-kernel thread that an application can, which is not too terribly far from the current Linux (as opposed to say FreeBSD which would require a *lot* of work to do this). Hell even just start with something simple like inotify (the design of which is absurd) and make it so programs can process events inside the kernel, making it actually be useful (see BPF).
  3. Neko by Anonymous Coward · · Score: 0 · on Beginning Lua Programming

    Neko's API is much more easier to use. What exactly does Lua have that Neko doesn't?

  4. Re:Amazing by Anonymous Coward · · Score: 0 · on Implications of the Mozilla/Adobe Partnership

    Lua is already faster than most dynamic typed runtimes, add a JIT to lua and it's register based VM becomes competitive with Java and Mono.

    I've seen a tamarin "typed" benchmark and heard people say it is slow on eval, ie: code as data in a dynamic language. From this I assume tamarin is stack based and that the VM is not suited to dynamic languages (like javascript). If I'm right, Mozilla have only chosen tamarin because Macrodobe are willing to donate engineering resources. I'd like to see a benchmark and comparison between neko JIT and tamarin, something similar to this comparison between neko and lua.

  5. Re:Say What? by mjbkinx · · Score: 1 · on Implications of the Mozilla/Adobe Partnership

    I bet on neko having AMD64 JIT first.

    I wouldn't be so sure, there will be many more working on Tamarin then on the Neko VM.
    But who cares which one will be first, haXe can be compiled for both. :)

  6. Re:Say What? by Anonymous Coward · · Score: 0 · on Implications of the Mozilla/Adobe Partnership

    I bet on neko having AMD64 JIT first.

  7. Should be much faster by mjbkinx · · Score: 4, Informative · on Flash 9 Beta for Linux Available

    Previous revisions of Flash Player for Linux preformed very poorly compared to the win32 versions (even the win32 verison in crossover office did a better job).

    Yeah, Tinic ranted about that on his blog a while ago, saying he used wine for Flash on Linux (before v9, obviously) -- and he's a FlashPlayer engineer. His entry about this beta release addresses performance. He says he's not happy with the current state of font rendering speed yet, but that it beats the Windows version by 20% with other stuff. They're still working on it.

    Over all, you should see better performance of existing content, thanks to the new rendering engine introduced in v8. This is especially true for SWFs (competently) written for v8 and using cacheAsBitmap -- not rerendering vectors every frame seems to improve performance. Who would have thought...

    The second performance increase will probably take a while to become common: FP9 comes with a new, JIT compiled VM. The old one is still included for backwards compatibility, but once FP9 has a good install base and is supported by developers making scripting-heavy stuff, you should definitely notice the performance increase -- it's much, much faster.

    If somebody feels like playing with it, there's the free (beer) Flex SDK on the Adobe site somewhere. However, I'd like to recommend haXe, a Free (capital F) compiler for a very fine language, with a great type system, that I really enjoy coding in. It supports Flash 6 to 9, the Free NekoVM, and can generate JavaScript (Yes! Typed!). Windows users can use the FlashDevelop plugin, for the rest of us there's Eclipse with EHX.

  8. Re:A question of style by 0xABADC0DA · · Score: 1 · on Great Programmers Answer Questions From Aspiring Student

    Maybe you picked up on the sarcasm that, yes, actually there has been good music made since 1980. And there have been improvements in kernel design since then too. And languages besides C. And licenses besides GPLv2.

    I actually think this is informative because pretty much anybody would have heard something good just visiting with their friends. I suppose Linus is that busy that he never gets out, or maybe he doesn't know people who expose him to new things like this.

    In any case, I think it's safe to say the chance of getting a neko or similar into a standard linux kernel is pretty much zero.

  9. Re:What are you missing? by 0xABADC0DA · · Score: 2, Interesting · on Advanced Data Structures?

    I find it fascinating that a kernel developer would be concerned with O() rather than the actual runtime. I thought kernel developers in general just put an arbitrary upper bound so their "O(n^2) && n -lt 1024" was faster than the "O(log n)" for any n.

    Now if what you are actually looking for is some fun how about embedding neko in the kernel, because while you can add some cool things like say tries (prefix trees) the real performance bottleneck is between apps and the kernel. Neko could safely call getpid() in the kernel 1000x more times than any user app could. This opens a lot of possibilites such as user code safely reading kernel structures directly with nearly zero overhead, functioning as event callbacks, etc.

    As an example, take something like beagle where it ideally gets notified of every file change and then, at some later time re-index the files. Do you really want every file modification doing a kernel-user-kernel switch? Or some hideous complicated caching API to specifically send these events all in a batch? (inotify I am looking at you...). Think a generic BPF.

  10. Re:Parrot by Anonymous Coward · · Score: 0 · on IronPython 1.0 is Born

    http://nekovm.org/

  11. There are plenty of sources already by mjbkinx · · Score: 1 · on Interview With Linux Flash Player's Lead Engineer
    There is an open reference by the sswf author, there is swfmill which supports almost all tags up to Flash 8, flasm which supports all action tags for the old VM (up to Flash 8) and haXe which can compile for both the old and the new one (plus, btw, it's a very nice language which can also generate JavaScript and Neko for the open source, JIT-compiling NekoVM). The player would have to support some proprietary protocols (e.g., to stream videos), for code see red5. And of course there's Gnash.

    That's just to name a few, there are others. There is plenty of code out there to generate and modify content, the official specification isn't needed for a player.

  12. Bring on the VM's by Anonymous Coward · · Score: 0 · on PHP and Perl in One Script?

    You'd never guess it from the moronic comments here but mixing dynamic languages will be common one day, until then:

    http://parrotcode.org/
    http://nekovm.org/

  13. Farewell PHP/Zend by Anonymous Coward · · Score: 0 · on Benchmarking 3 PHP Accelerators

    http://nekovm.org/

  14. Re:Rails zealots aren't hammers, they're just tool by Anonymous Coward · · Score: 0 · on What's the Secret Sauce in Ruby on Rails?

    Lighttpd embeds lua for use as a front end cache. There's also been a few attempts at a mod_lua for Apache. Lua is cool, one of my favorite languages and I much prefer it to ruby or python. If you haven't already, check out luajit and of course there's nekovm (& mod_neko) that looks like it's ready to deliver on some of parrots promises.