OSnews.PL

Second Life testuje skypty Mono

Linden Lab poinformowało o możliwości testowania skryptów Mono pisanych specjalnie dla Second Life. Aktualnie działają tylko skrypty LSL, ale docelowo będzie można pisać w dowolnym języku .NET wspieranym przez Mono.

Celem wdrożenia Mono jest zwiększenie funkcjonalności i szybkości działania skryptów.

Programiści mogą teraz testować skrypty LSL kompilowane w Mono łącząc się do specjalnego grida Second Life i teleportując się do regionu rozumiejącego te skrypty.

Miguel de Icaza na swoim blogu poleca prezentację programistów Linden Lab (niestety WMV), w której opisują oni hacki, jakie zastosowali podczas przystosowywania platformy Mono do wykorzystania w SecondLife.

Zainteresowanym polecam stronę Mono i Mono FAQ na wiki SecondLife.



PODOBNE WPISY:

żadnych reklam, sama wiedza.

Zarejestruj się na BEZPŁATNY NEWSLETTER i raz w tygodniu otrzymuj najważniejsze wiadmości
ze świata IT, nowych technologii i kryptowalut.

Bez reklam.

Zarejestruj się za darmo
20 odpowiedzi na „Second Life testuje skypty Mono”
  1. Awatar M
    M

    Second Life przypomina mi Matrix… Ale to dobra okazja, by nauczyć się C# ;).

    Odpowiedz
  2. Awatar Thar
    Thar

    Celem wdrożenia skryptów Mono jest zwiększenie funkcjonalności i szybkości działania skryptów.

    Taa, szybkości…

    Odpowiedz
    1. Awatar mario
      mario

      Języki uruchamiane w VM typu JIT są o wiele szybsze od tych interpretowanych.

      Odpowiedz
      1. Awatar Thar
        Thar

        Tak, ale akurat Mono jest b. słabo zoptymalizowane – developerzy starają się gonić Microsoft i jego .NET z implementacją funkcji (na razie są w trakcie pisania pełnego wsparcia dla 2.0). W związku z tym istnieją szybsze od niego maszyny wirtualne do języków interpretowanych, jak choćby Neko.

        Odpowiedz
        1. Awatar mario
          mario

          Ale zmusza Cię to do pisania w języku NEKO. Lepiej użyć otwartej, wieloplatformowej i szybkiej Javy, pod którą można pisać i kompilować programy w wielu językach (nie tylko język Java). Java jest też dużo lepiej przetestowana niż .NET, w dodatku jest projektowana od uruchamiania na zróżnicowanych platformach.

          Odpowiedz
        2. Awatar Thar
          Thar

          Ale wydawało mi się, że rozmowa dotyczy Mono a nie Javy…

          Odpowiedz
        3. Awatar mario
          mario

          NEKO przegrywa nawet z mono, bo wymaga stosowania konkretnego języka. Jeśli programy mają być pisane przez ludzi z całego świata, to nie można wymuszać na nich języka w jakim mają pisać – na pewno nie przyczyni sie to do powstania większej ilości dodatków. Wymuszanie jakiegoś egzotycznego języka tym bardziej nie przyniesie sukcesu.

          Odpowiedz
        4. Awatar Thar
          Thar

          Jak na razie w Mono można pisać tylko C# (no, Visual Basic ma jakieś szczątkowe wsparcie), które też swego czasu było językiem 'egzotycznym'.

          Zwróciłeś uwagę na Neko, a to był tylko przykład dobrze zoptymalizowanej vm pod język interpretowany, który posłużył do obalenia twojej tezy:

          Języki uruchamiane w VM typu JIT są o wiele szybsze od tych interpretowanych.

          Odpowiedz
        5. Awatar mario
          mario

          NEKO też kompiluje program (pliki *.neko) do byte-codeu (pliki *.n) i uruchamia program w VM typu JIT (neko ma kompilator JIT dla x86 od wersji 1.4). Nie rozumiem jaką tezę chciałeś obalić?
          –
          Aby porównywać (obalać tezy też), trzeba wykonać kilka różnych algorytmów zaimplementowanych w obu językach i zmierzyć czas ich wykonania (lub inny parametr jaki chcesz mierzyć, np. zużycie pamięci). Np. implementujesz mnożenie macierzy w PHP(język interpretowany) i Javie(VM typu JIT) w taki sam sposób i wykonujesz test.

          Odpowiedz
        6. Awatar Thar
          Thar

          Nie rozumiem jaką tezę chciałeś obalić?

          Tą, którą zacytowałem? To o czym piszesz w żaden sposób nie kłóci się z tym, że Neko pozostaje językiem interpretowanym. Python też jest takim językiem, mimo że po drodze kompiluje skrypty do bytekodu. A szybkość działania Mono oceniam nie na podstawie benchmarków, które mają być obiektywne a w praktyce dają wyniki odległe od rzeczywistych doświadczeń użytkowników. Po prostu porównaj prędkość działania choćby Paint.NET i MonoPaint. Poczujesz różnicę.

          Odpowiedz
        7. Awatar mario
          mario

          Ok jeszcze raz: skoro teza to:

          Języki uruchamiane w VM typu JIT są o wiele szybsze od tych interpretowanych.

          to zwrot

          Zwróciłeś uwagę na Neko, a to był tylko przykład dobrze zoptymalizowanej vm pod język interpretowany, który posłużył do obalenia twojej tezy

          Nie obala jej tylko ją potwierdza, bo Neko to wirtualną maszyna typu JIT. Jak już pisałem NEKO od wersji 1.4 ma JIT dla x86, a dokładniej od 1 sierpnia 2006 roku (http://nekovm.org/news).
          Mówiąc, że języki interpretowane są szybsze od VM JIT podajesz jako przykład VM typu JIT jakim jest NEKO.

          To o czym piszesz w żaden sposób nie kłóci się z tym, że Neko pozostaje językiem interpretowanym.

          Tutaj właśnie się mylisz – Neko nie jest językiem interpretowanym.

          Odpowiedz
        8. Awatar Thar
          Thar

          Ok, dla ciebie różnica polega na tym, że jeden kod przechodzi przez interpreter, a drugi przez vm. Dla mnie to też jest pewien rodzaj interpretacji – skryptu do bytekodu. Tak, w przypadku twojej Javy również.

          <a href rel="nofollow"&gt <a href="http://;http://en.wikipedia.org/wiki/Interpreted_language#Languages_usually_compiled_to_a_virtual_machine_code” target=”_blank”>;http://en.wikipedia.org/wiki/Interpreted_language#Languages_usually_compiled_to_a_virtual_machine_code

          Odpowiedz
        9. Awatar Thar
          Thar

          Sry, źle link wkleiłem.

          http://en.wikipedia.org/wiki/Interpreted_language…

          Odpowiedz
        10. Awatar mario
          mario

          Ehh już widzę na czym polega Twój problem.
          :
          Otóż wirtualna maszyna może rzeczywiście interpretować kod, ale jest wtedy powolna (tak robiły pierwsze wersje Javy, albo były od 20 razy wzwyż wolniejsze od analogicznego natywnego kodu), dlatego powstały kompilatory JIT (Just In Time), których zadaniem jest kompilowanie byte-codeu do natywnego kodu maszynowego. Dzięki temu Java dorównuje prędkością klasycznym językom kompilowanym (strata jest bardzo mała). Bytecode zazwyczaj jest skonstruowany tak, aby łatwo można było go przetłumaczyć na assembler.
          :
          Kiedyś były tylko 2 typy języków wysokiego poziomu – języki kompilowane i interpretowane. Języki kompilowane zazwyczaj miały tą zaletą, że program wynikowy był szybki, ale trudniej kontrolowało się wyjątki, dodatkowo program wynikowy nie był przenośny po skompilowaniu. Interpretery dużo lepiej informowały programistę o błędach, ale był bardzo powolne w porównaniu z analogicznym kodem skompilowanym, za to program można było przenieść w tej samej postaci na inną maszynę.
          :
          Aby skorzystać z zalet zarówno kompilatorów jak i interpreterów stworzono język Java i specjalne środowisko uruchomieniowe, tzw wirtualną maszynę. Program napisany w Javie najpierw kompilowany jest do specjalnego bytecodeu, który bardziej przypomina assembler, niż język wysokiego poziomu i w takiej postaci jest dystrybuowany. Potem użytkownik uruchamiając program musi mieć specjalne środowisko zwane wirtualną maszyną, które ładuje ten bytecode i KOMPILUJE ile tylko sie da do kodu NATYWNEGO maszyny na której jest ten program uruchomiony. W stosunku do czystych kompilatorów spadek wydajności jest niewielki a daje zalety jakie dawały interpretery, czyli kontrolę oraz przenśność. Niestety są też wady – programy uruchamiane w VM JIT zajmują sporo więcej pamięci, niż wersje interpretowane czy kompilowane.

          Odpowiedz
        11. Awatar stilgar
          stilgar

          To w takim wypadku C++ też przechodzi pewien rodziaj interpretacji przez G++

          Odpowiedz
        12. Awatar Thar
          Thar

          @mario

          Dobra, ale znów chcę przypomnieć, że rozmawiamy o Mono, a nie o Javie… To, że Mono jest jak żółw powolne to dowód na to, że generalizacja JIT = szybkość jest błędna. A tylko o to mi chodziło.

          Odpowiedz
        13. Awatar mario
          mario

          @stilgar: nie interpretacji tylko translacji – poczytaj o teorii translatorów i kompilatorów.
          @Thar: tutaj masz przykładowy wynik benchmarka – z mono nie jest tak najgorzej: http://www.shudo.net/jit/perf/Linpack-1000-P4.png… http://www.shudo.net/jit/perf/Sieve-P4.png. Rzeczywiście mono odstaje, ale i tak jest szybszy od interpretowanych języków.

          Odpowiedz
  3. Awatar michuk
    michuk

    Miguel de Icaza's w kolejnym wpisie zaprezentować screenshot ze swoim awatarem w Second Life wkraczającym do strefy Mono.

    Odpowiedz
  4. Awatar harijari
    harijari

    Te benchmarki dotyczą mono 1.1.3, wydanej gdzieś w zamierzchłym 2005 roku. Czy ktoś ma może dostęp do bardziej aktualnych wyników?

    @thar
    wydaje mi się, że języków jest jednak trochę więcej pod tym nemerle:
    http://www.mono-project.com/Languages

    Odpowiedz
    1. Awatar harijari
      harijari

      miało być mono -> jest nemerle. Plusy rannego wstawania.

      Odpowiedz

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *


media społecznościowe

ostatnie artykuły

Popularne tagi

android apple bezpieczeństwo biznes google hardware internet iphone kaspersky media microsoft mobile open-source press-release programowanie software UNIX windows Wydania Wydarzenia

Kategorie