Page 112 of 173

Ubuntu Linux + Dell Latitude z technologią Optimus

Wstęp

Ostatnimi dniami stałem się (nie)szczęśliwym posiadaczem laptopa Dell Latitude, wyposażonego w dwie karty graficzne. Jak to w dwie? A no procesory i5 i i7 mają w sobie wbudowaną kartę graficzną Intela. Proces integracji coraz większej liczby elementów w jednej małej obudowie trwa od dawna, nic dziwnego, że nie ominął GPU. GPU wbudowane w procesor świetnie nadaje się do zastosowań takich jak przeglądanie internetu, czy też pisanie w Wordzie. Do gier i multimediów wciąż warto mieć zewnętrzny procesor graficzny.

Optimus, Optimus, Optimus

Na bardzi fajny pomysł wpadli inżynierowie w Intelu - dlaczego nie wziąć słabej karty kiedy wystarczy a mocnej kiedy potrzeba? Spadnie wtedy drastycznie zużycie prądu podczas normalnej pracy (zewnętrzne GPU będzie wyłączone), a kiedy będzie trzeba - przełączy się na mocniejszą "multimedialną" kartę. Rozwiązanie rzecz jasna działa świetnie na Windowsie...

Optimus jako Megatron

Niestety wygląda na to, że NVidia przestała ostatnio lubić się z Linuksem, ponieważ Optimus nie dostał sterowników dedykowanych dla Linuksa. Na domiar złego, jeśli włączymy w BIOSie samą technologię, nasz system będzie widział dwie karty, trzymał obie włączone ale używał tylko tej wbudowanej w CPU. Nie ma to jak mieć kartę która nic nie robi a zjada całkiem sporo prądu. W taki oto sposób (nie wydając sterowników) mamy z technologii Optimus bardzo złego Megatrona. Nic nie robi a zużywa zasoby.

Bumblebee na ratunek

Szybko znaleźli się jednak fanatycy, którzy postanowili sami zaimplementować Optimusa na Linuksy. Tak powstał Bumblebee. Instalacja jest całkiem prosta, sprowadza się do pobrania repozytorium i uruchomienia instalacji. Niestety wraz z instalacją Bumblebee pojawia się kilka problemów:

  • nie na wszystkich laptopach działa;
  • jeśli działa to nie zawsze prawidłowo;
  • psuje Unity (i ogólnie "ładność" - zostaje tylko taki podstawowy theme bez cieni, itd);
  • system nie chce się wyłączać;
  • nie działa panel administracyjny kartą NVidii;
  • po poprawkach w xorg.conf - przestają całkiem działać Xy.

Powyższa lista zastrzeżeń, na pewno z czasem się zmniejszy jednak póki co - nie jest zbyt kolorowo.

Nie ma to jak półśrodki

Jedynym sensownym (póki co) rozwiązaniem jest wyłączenie trybu Optimus w BIOSie swojego komputera. Po zrobieniu tego, w systemie widnieje tylko jedna (zewnętrzna) karta graficzna i to przez nią "lecą" wszystkie obliczenia.

Powiesz szczerze, że czuję się trochę zawiedziony poczynaniami NVidii która zawsze uchodziła za producenta wspierającego rozwiązania na Linuksy. Od niepamiętnych czasów było tak, że jeśli ktoś kupował komputer pod Linuksa - brał z kartą NVidii. W trybie "jednokartowym" sterowniki NVidii działają bez zarzutu.

Przyśpieszanie ładowania Railsów

Wstęp

Tytułem wstępu powiem, że artykuł nie jest mój. Ostatnio korespondowałem trochę z Xavierem Shay i pojawił się pomysł tłumaczenia co ciekawszych wpisów na język polski - tak z myślą o młodych Railsowcach - zawsze to łatwiej zrozumieć w swoim języku. Chciałbym zaznaczyć, że nie jestem profesjonalnym tłumaczem i nie wszystko może być idealnie. Oryginał artykułu możecie znaleźć tutaj.

Wolno, wolniej, najwolniej...

Szybkość ładowania plików maleje jeśli chodzi o kolejne wersje Rubiego. Można to zaobserwować na poniższym wykresie:

Dla przykładu, nasza średniej wielkości aplikacja wymaga około 2200 plików. Zaczyna być to problematyczne, ponieważ dla Railsów 1.9.2 start aplikacji trwa około 20 sekund, zaś dla 1.9.3 ponad 46 sekund. Obie te wartości są zdecydowanie zbyt wysokie.

Dlaczego tak się dzieje? Powodów jest kilka, niemniej jednak jednym z głównych powodów jest algorytm includowania plików, który wygląda mniej więcej tak:

def require(file)
 $loaded.each do |x|
   return false if x == file
 end
 load(file)
 $loaded << file
end

Jak nietrudno zauważyć, tego typu pętla zwalnia wraz z każdym nowym plikiem. Aby temu zaradzić napisałem patch do 1.9.3 który zmienia ten algorytm aby wyglądał tak:

def require(file)
  return false if $loaded[file]
  load(file)
  $loaded[file] = true
end

Po tej zmianie, prędkości ładowania prezentują się następująco:

Dużo lepiej.

Wprawdzie jest to tylko benchmark, jednak moja główna Railsowa aplikacja ładuje się około 10 sekund (20 przy Rubym 1.9.2). Pusta aplikacja ładuje się około 1.1 sekund. Jest to mniej niż w 1.8.7.

Instalacja poprawki

Oto krótka instrukcja jak zainstalować z wykorzystaniem RVMa (w zaledwie 10 minut) moją poprawkę.

# Benchmark testowy
cd /your/rails/app
time script/rails runner "puts 1"

# Instalacja spatchowanego Rubiego
curl https://gist.github.com/raw/996418/e2b346fbadeed458506fc69ca213ad96d1d08c3e/require-performance-fix-r31758.patch > /tmp/require-performance-fix.patch
rvm install ruby-head --patch /tmp/require-performance-fix.patch -n patched
# ... czeeeekamy :)

# Test porównawczy
cd /your/rails/app
rvm use ruby-head-patched
gem install bundler --no-rdoc --no-ri
bundle
time script/rails runner "puts 1"

Chcesz pomóc?

Zanim poprawka ta zostanie umieszczona w trunku, potrzeba jeszcze wiele wysiłku. Doceniłbym gdybyście:

  • sprawdzili ten kod i zostawili komentarz z wynikami
  • przejrzeli ten patch
  • sprawdzili to na Windowsie
  • zgłaszali ew. błędy

Co dalej?

Zdaję sobie sprawę, że do dołączenia tego do 1.9.3 jeszcze daleka droga. Niemniej jednak jest to pierwszy z wielu kroków w drodze do przyśpieszenia Railsów. Wciąż mamy Bundlera oraz RubyGems które robią... coś - coś co chciałbym sprawdzić. Chciałbym też przeportować ew. zmiany także do JRubiego.

Copyright © 2025 Closer to Code

Theme by Anders NorenUp ↑