🚀 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 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

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

> > [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