🚀 go-pugleaf

On 6 Okt., 22:23, TCLfri...@googlemail.com wrote:
> Witajcie!
>
> Miałem ostatnio potrzebę przekodować prostą operacją XOR dość duży
> plik (kilkaset MB). Przy okazji porównałem wydajność analogicznego
> kodu napisanego w Tclu, perlu i javie i niestety musze stwierdzić, że
> wydajność Tcl'a pozostawiła tu wiele do życzenia :-( Oczywiście test
> ten nie może być uznany za obiektywny, jednak dotyczył realnego
> zagadnienia przez co jego wynik uważam za szczególnie istotny. Nie
> chcę zaśmiecać grupy, szczegóły tego 'testu' opisałem tutaj:http://tclmentorpl.kocjan.org/2007/10/krtka-rozprawa-midzy-panem-wjte...
> , natomiast chciałbym się spytać innych użytkowników Tcla, jak wy
> znajdujecie wydajność tego języka w odniesieniu do innych?

Tak. To jest dobry przykład do czego nie powinno się używać Tcl
bezpośrednio.
Tcl został wymyślony jako tzw. jezyk klej. Klej dla kodu napisanego w
C.
Tcl to tak naprawdę duża biblioteka napisana w języku C.
W tym przypadku najbardziej racjonalne jest napisanie tej procedury w
C
jako biblioteki (extension) dla Tcl.
Tcl ma bardzo dobry API dla języka C jest on o niebo łatwiejszy od
Perl, PHP, Python i Java.
Dobrą obcją może być też critcl, który pozwala na pisanie w C
bezpośrednio w Tcl.
Tą drogę wybrał też Perl i dlatego wygrał. Jedyna różnice to to, że
akurat ta procedura nie
należy do standartowych funkcji w Tcl.

Oczywiście można by było trochę tę kod optymować ale wielkich
rezultatów nie można się spodziewać.
może zamiast lappend używać append. Jeśli wyobrażę sobie co Tcl robi w
tym czasie aby to wykonać i
co jest robione z pamięcią to to nie może być szybkie.

To podaję kod biblioteki w C dla Tcl.
Nie sprawdzałem z braku czasu chodzi tu tylko o ideę.
Według mnie pisanie bibliotek w C dla Tcl to także część Tcl.

static int stringxor(ClientData clientData, Tcl_Interp *interp, int
objc, Tcl_Obj *const objv[])
{
  if (objc!=2) {
      Tcl_WrongNumArgs(interp, 1, objv, "proceduro atendas du
argumentojn");
      return TCL_ERROR;
  }
  int stringlen,xorlen,t=0
  char *string = Tcl_GetStringFromObj(objv[0], &stringlen);
  char *xor = Tcl_GetStringFromObj(objv[1], &xorlen);

  for (int x=0;x<stringlen;x++) {
      string[x] ^= xor[t];
      t++;
      if (t>=xorlen) t = 0;
  }

  return TCL_OK;
}


#ifdef _WINDOWS
__declspec( dllexport )
#endif
int Stringxor_Init(interp)
    Tcl_Interp *interp;
{

  if (Tcl_InitStubs(interp, "8.1", 0) == NULL)
    return TCL_ERROR;
  if (Tcl_PkgRequire(interp, "Tcl", "8.1", 0) == NULL)
    return TCL_ERROR;
  if (Tcl_PkgProvide(interp, "stringxor" , "1.0") != TCL_OK)
    return TCL_ERROR;

   Tcl_CreateObjCommand(interp,"stringxor",stringxor,NULL, NULL);

   return TCL_OK;
}

Szybciej byłoby tylko może w assemblerze (operacje na całych wyrazach
32 bit)
możliwe że kompiler to zoptymuje.

Artur

Dnia 07-10-2007 o 20:10:18 Artur <mail@xdobry.de> napisał(a):
> On 6 Okt., 22:23, TCLfri...@googlemail.com wrote:
>> Miałem ostatnio potrzebę przekodować prostą operacją XOR dość duży
>> plik (kilkaset MB). Przy okazji porównałem wydajność analogicznego
>> kodu napisanego w Tclu, perlu i javie i niestety musze stwierdzić, że
>> wydajność Tcl'a pozostawiła tu wiele do życzenia :-( Oczywiście test
>> ten nie może być uznany za obiektywny, jednak dotyczył realnego
>> zagadnienia przez co jego wynik uważam za szczególnie istotny. Nie
>> chcę zaśmiecać grupy, szczegóły tego 'testu' opisałem  
>> tutaj:http://tclmentorpl.kocjan.org/2007/10/krtka-rozprawa-midzy-panem-wjte...
>> , natomiast chciałbym się spytać innych użytkowników Tcla, jak wy
>> znajdujecie wydajność tego języka w odniesieniu do innych?
> Tak. To jest dobry przykład do czego nie powinno się używać Tcl
> bezpośrednio.
> Tcl został wymyślony jako tzw. jezyk klej. Klej dla kodu napisanego w
> C.

Tu akurat się zgadzam.

> [ciach]
> static int stringxor(ClientData clientData, Tcl_Interp *interp, int
> objc, Tcl_Obj *const objv[])
> {
>   if (objc!=2) {
>       Tcl_WrongNumArgs(interp, 1, objv, "proceduro atendas du
> argumentojn");
>       return TCL_ERROR;
>   }
>   int stringlen,xorlen,t=0
>   char *string = Tcl_GetStringFromObj(objv[0], &stringlen);
>   char *xor = Tcl_GetStringFromObj(objv[1], &xorlen);

Zależnie od tego co autor miał na myśli (a raczej miał na myśli dane  
binarne) to pewnie chodziło o Tcl_GetByteArrayFromObj().

Zastanawiam się nad czymś innym - czy nie można tego problemu trochę  
uogólnić i np zaimplementować w oparciu o C i Tcl_ExprObj(). Na przykład:

manipulatedata byte data $datastr byte key $keystr {$data ^ $key} <-  
ostatnie to formuła matematyczna.

O ile takie coś pewnie nie znajdzie się w samym Tcl, to pewnie mogłoby  
znaleźć się w Tcllib wraz z wersją critcl (jak np md5 w tcllib).

-- 
Wojciech Kocjan

Dnia 06.10.2007 TCLfriend@googlemail.com <TCLfriend@googlemail.com> napisał/a:

> , natomiast chciałbym się spytać innych użytkowników Tcla, jak wy
> znajdujecie wydajność tego języka w odniesieniu do innych?

Odnośnie szybszej Javy: to jeszcze zależy, której wersji Tcl użyto do testu;
ktoś na liście angielskiej niedawno "zapodał", że 8.5 jest ok. 2-krotnie
wolniejsza od 8.4 (sam nie sprawdzałem; i tak nic przecież na to nie
poradzę). Więc gdyby (ha, gdyby...) w wersji finalnej podregulowano
wydajność tak, żeby wrócić do stanu z 8.4, nie byłoby znowuż tak źle.
-- 
ZB

> > [ciach]
> > static int stringxor(ClientData clientData, Tcl_Interp *interp, int
> > objc, Tcl_Obj *const objv[])
> > {
> >   if (objc!=2) {
> >       Tcl_WrongNumArgs(interp, 1, objv, "proceduro atendas du
> > argumentojn");
> >       return TCL_ERROR;
> >   }
> >   int stringlen,xorlen,t=0
> >   char *string = Tcl_GetStringFromObj(objv[0], &stringlen);
> >   char *xor = Tcl_GetStringFromObj(objv[1], &xorlen);
>
> Zależnie od tego co autor miał na myśli (a raczej miał na myśli dane
> binarne) to pewnie chodziło o Tcl_GetByteArrayFromObj().
>
> Zastanawiam się nad czymś innym - czy nie można tego problemu trochę
> uogólnić i np zaimplementować w oparciu o C i Tcl_ExprObj(). Na przykład:
>
Rzeczywiście to było zbyt szybko (niem. Schnellschuss) i niepoprawnie.
Tak naprawdę nie wolno modyfikować danych objektów w ten sposób
poniewąż Tcl użwywa Copy on Write. Tzn dane mogę być używane przez
wiele objektów (sharing).
Poprawnie by było zwracać wynik jako nowy objekt, ja chiałem
modyfikować parameter przez referencję.
Problemem jest też to, że Tcl używa wewnętrznie UTF-8 (z kilkoma
modyfikacjami) tzn.
Tcl_GetByteArrayFromObj() i Tcl_NewByteArrayObj są jedynie dobrym
rozwiązaniem.

Tak na marginesie. Przez UTF8 Tcl nadaję się bardzo dobrze do
tworzenia rozwiązań wielojęzycznych i do obróbki tekstów ale obróbka
czystych danych binarnych jest trochę trudniejsza, wolniejsza i
mozolna.

Tcl_ExprObj() ciekawę to może było by najbardziej eleganckie
rozwiązanie.

Artur