Pike-devel

pike-devel@lists.lysator.liu.se

3 participants
3048 discussions

Start a nNew thread

Whee!
by David Hedbor ＠ Pike developers forum 17 Jan '03

17 Jan '03

First successful icc build of Pike 7.5 just finished. :)

2 3

-O3
by David Hedbor ＠ Pike developers forum 16 Jan '03

16 Jan '03

Is there a reason while '-O2' is the "max" -Ox flag and not -O3? I.e have there been any specific problems or are there other reasons?

4 6

Re: signed integer division
by Johan Sundstr�m (a hugging punishment!) ＠ Pike (-) developers forum 16 Jan '03

16 Jan '03

Excellent documentation material for `/ and `%, Niels; thanks. I'm taking the liberty of incorporating parts of that discussion to the refdocs. / Johan Sundström (a hugging punishment!) Previous text: >2003-01-15 11:41: >Subject: Re: signed integer division >-------------------------------------------------------------------- >Rene van Rueschen <rueschi(a)berit-broese.de> writes: > >> There is a big difference between C/Pascal/LPC and Pike in signed integer division: >> In Pike, results are rounded down, while in all other languages the results are >> rounded towards 0. > >This behaviour was argued about and decided several years ago. As I >was one of those who argued strongly for the current behaviour, I >should perhaps explain why I prefer that: > > 1. It means that a % b always have the same sign as b (typically b > is positive (array size, rsa modulo, etc), and a varies a lot > more than b. > > 2. That means that the function f(x) = x % n behaves in a sane way, > as x increases, f(x) cycles through the values 0,1, ..., n-1, 0, > .... Nothing strange happens when you cross zero. > > 3. Furthermore, the function f(x) = x/n behaves in a sane way. When > you increase x, f(x) will jump one step for each n:th increment. > For all x, (x + n) / n = x/n + 1. Zero is not special. > > 4. The % operator implements the binary "mod" operation, as defined > by our god Donald Knuth (see the Art of Computer Programming, > 1.2.4) [1]. > >> (Results of the modulo operation are 'correct' referring to this >> unusual rounding style.) > >It's important that / and % are compatible, so that a = b*(a/b) + a%b >for alla and b. > >Also note the recent 15-20 years of history of the % operations. >Traditionally in C (i.e. at least up c89 ANSI C), the rounding >behaviour of % for negative numbers was left as implementation >defined. If there was a machine code instruction for division, C >typically did whatever the machine code did. > >It's unfortunate to have a basic operation like % not well defined. >When the Pike developers were annoyed about it, the question was >argued and in the end Pike chose the, in my opinion, sanest convention >for how it ought to work. Then java came a long, and choose the >round-towards-zero convention, which in my opinion is brain damaged. >I'm not sure what c99 says, perhaps it specifies the same behaviour as >java. > >Anyway, as you compare to C, you should be aware that a portable >programs can't make any assumptions about the rounding conventions of >%, it's all up to the compiler implementation (at least if you don't >require a c99 compiler). So any C program that depends on that % >behaviour is *broken*. I guess the same is true for LPC, at least >older versions of Pike and ulpc used to inherit the %-behaviour from >the C compiler that was used for compiling it, which in turn inherited >it from the corresponding machine code instruction. > >> This strange behavour makes it extremly difficult to port algorithms >> written in other languages to Pike. > >Can you give some examples of the extreme difficulties? > >/Niels > >[1] Ok, Knuth's definition also says that x mod 0 = 0 for all x. > That's not true for Pike's %; it treats %-by-0 as an error. But > that's really a border case. > > > > / Brevbäraren >

6 8

Intel C++ / gcc 2.95.4 comparisions
by David Hedbor ＠ Pike developers forum 15 Jan '03

15 Jan '03

Thought these results are interesting. Note that compilation with gcc-3.2 probably would generate better code, especially with arch-dependent data. The binary is compiled with arch-specific code for multiple platforms (i.e -march but for multiple platforms at once - rather nice). I'm also using multi-file Interprocedural optimizations (takes quite a long time to link Pike). arch is Athlon - Pentium probably would get even better results. gcc version 2.95.4 20011002 (Debian prerelease): test total user mem (runs) Pike start overhead........ 0.228s 0.001s 3352kb (22) Ackermann.................. 1.669s 1.453s 3532kb (3) Array & String Juggling.... 1.026s 0.808s 3660kb (5) Clone null-object.......... 0.488s 0.273s 3340kb (11) (12100000/s) Clone object............... 0.909s 0.692s 3340kb (6) (2602410/s) Compile.................... 1.975s 1.760s 3504kb (3) (41148 lines/s) Compile & Exec............. 1.790s 1.577s 3520kb (3) (1144313 lines/s) GC......................... 1.269s 0.925s 3468kb (4) Matrix multiplication...... 0.862s 0.643s 5144kb (6) Loops Nested (local)....... 0.578s 0.362s 3324kb (9) (416857184 iters/s) Loops Nested (global)...... 0.899s 0.642s 3324kb (6) (156877872 iters/s) Loops Recursed............. 1.442s 1.225s 3324kb (4) (3423922 iters/s) Intel(R) C++ Compiler for 32-bit applications, Version 7.0 Build 20021021Z: Pike start overhead........ 0.191s 0.000s 3760kb (25) Ackermann.................. 1.068s 0.864s 3956kb (5) Array & String Juggling.... 1.007s 0.804s 3968kb (5) Clone null-object.......... 0.426s 0.237s 3728kb (12) (15157895/s) Clone object............... 0.816s 0.626s 3728kb (7) (3356164/s) Compile.................... 1.594s 1.405s 3916kb (4) (68726 lines/s) Compile & Exec............. 1.667s 1.397s 3884kb (3) (1291790 lines/s) GC......................... 1.068s 0.880s 3876kb (5) Matrix multiplication...... 0.746s 0.556s 5680kb (7) Loops Nested (local)....... 0.727s 0.534s 3760kb (7) (219808464 iters/s) Loops Nested (global)...... 1.083s 0.894s 3760kb (5) (93832312 iters/s) Loops Recursed............. 0.784s 0.594s 3760kb (7) (12351014 iters/s) Note the slowdowns in the two nested loop tests though.

2 2

GTK and new libpng
by Martin Nilsson (�skblod) ＠ Pike (-) developers forum 15 Jan '03

15 Jan '03

It appears that the new libpng that up2date installed on mahoro don't work too well with the GTK linking. Has anyone got a fix for this?

1 0

Pike with icc (Intel C++, Linux)
by David Hedbor ＠ Pike developers forum 15 Jan '03

15 Jan '03

Aha, figured out the dynamic linking issue - don't link with -lc. I'm going to check in fixes to 7.5 once my test compile finishes. / David Hedbor Previous text: >2003-01-16 00:15: >Subject: Pike with icc (Intel C++, Linux) >-------------------------------------------------------------------- >Ok, a first compilation with icc is now finished. It doesn't work :-) > >Fails with: >/home/neotron/src/xenofarm/client/pike-7.4/stellar.home.hedbor.org/buildtmp/Pike7.4-20030115-205830/src/object.c:577: Fatal error: >Couldn't load master object. >No stack - no backtrace. > >I had do compile --without-dynamic-modules because currently I don't >have that working (not Pike specific). Ah well. :) > > / David Hedbor >

1 0

xenofarm build failure
by David Hedbor ＠ Pike developers forum 15 Jan '03

15 Jan '03

Hmm. I'm getting xenofarm build failures on my x86 box: /home/neotron/src/xenofarm/client/pike-7.4/stellar.home.hedbor.org/buildtmp/Pike7.4-20030115-190328/src/interpret.c:1296: undefined reference to `QUICK_FIND_LFUN' interpret.o(.text+0x866b):/home/neotron/src/xenofarm/client/pike-7.4/stella…: undefined reference to `QUICK_FIND_LFUN' collect2: ld returned 1 exit status make[5]: *** [tpike-real] Error 1 What's up with that? Both pike 7.4 and 7.5 I should add. It seems like the blame goes to this: revision 1.284 date: 2003/01/15 19:03:26; author: mast; state: Exp; lines: +12 -10 Before invoking the trampoline magic, check properly that it's the `() lfun in the trampoline object that is to be called.

4 8

FreeType
by Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum 15 Jan '03

15 Jan '03

I found the problem with FreeType on my machine. The pike module never selects any CharMap, and in this freetype version the default seems to be "no charmap", i.e. FT_Load_Char() will interpret the argument as a glyph number. This patch fixed the problem for me, could somebody who _already has a working FreeType module_ try it out and see if it breaks anything for them? Index: src/modules/_Image_FreeType/freetype.c =================================================================== RCS file: /pike/data/cvsroot/Pike/7.4/src/modules/_Image_FreeType/freetype.c,v retrieving revision 1.13 diff -u -r1.13 freetype.c --- freetype.c 2002/11/29 20:56:46 1.13 +++ freetype.c 2003/01/15 13:45:03 @@ -199,6 +199,8 @@ static void image_ft_face_create( INT32 args ) { int er; + FT_Encoding best_enc = ft_encoding_none; + int enc_no, enc_score, best_enc_score = -2; if( !args || sp[-args].type != T_STRING ) Pike_error("Illegal argument 1 to FreeType.Face. Expected string.\n"); er = FT_New_Face( library, sp[-args].u.string->str, 0, &TFACE ); @@ -206,6 +208,22 @@ Pike_error( "Failed to parse the font file %s\n", sp[-args].u.string->str ); else if( er ) Pike_error( "Failed to open the font file %s\n", sp[-args].u.string->str ); + for(enc_no=0; enc_no<TFACE->num_charmaps; enc_no++) { + enc_score = 0; + switch(TFACE->charmaps[enc_no]->encoding) { + case ft_encoding_symbol: enc_score = -1; break; + case ft_encoding_unicode: enc_score = 2; break; + case ft_encoding_latin_1: enc_score = 1; break; + } + if(enc_score > best_enc_score) { + best_enc_score = enc_score; + best_enc = TFACE->charmaps[enc_no]->encoding; + } + } + er = FT_Select_Charmap(TFACE, best_enc); + if( er ) + Pike_error( "Failed to set a character map for the font %s\n", + sp[-args].u.string->str ); pop_n_elems( args ); push_int( 0 ); }

1 0

sscanf?
by Peter Bortas ＠ Pike developers forum 13 Jan '03

13 Jan '03

Where if http://david.hedbor.org/pikeman/docs/tutorial_7.html#sscanf hiding in the new manual?

3 6

GC improvement
by Martin Stjernholm, Roxen IS ＠ Pike developers forum 13 Jan '03

13 Jan '03

I've developed the gc strategy a bit so that it also takes the time spent in the gc into account. There is now a low and a high garbage level. The gc tries to keep the low one as long as the total cpu time spent in the gc doesn't get too large, then it resorts to the higher one. I thought that could be useful since the gc otherwise can take a lot of time in a process that both has many nongarbage objects and generates a lot of garbage. I've also added a function Pike.gc_parameters to make it possible to tune these parameters. The current defaults are: Low garbage ratio: 20% of all allocated things is garbage. GC time ratio: 5% cpu time spent in the gc. High garbage ratio: 50% of all allocated things is garbage. These are set on feeling only and hardly tested at all. It's therefore very appreciated if someone could do some tuning with a big and busy pike process. (The function Debug.gc_status is useful to get info about the gc performance.)

5 13

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pike-devel