| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Comments:
<0> hows it goin
<1> history
<2> Hello Mr. New International Version. :)
<0> hehe
<0> someone said needle in vain 8)
<3> Teckla: if the majority of my thread loop is a lock/access/unlock var, while 99.9% of the time no other thread is accessing the variable, is there a bit of overhead on that lock/unlock?
<3> cause i can't group this with another mutex, or i would, to avoid two mutex locks
<4> feti_: you can try to declare this variable volatile.
<4> sometimes, volatile vars can be accesses w/o mutex
<4> but not for increment/decrement
<4> only for asignment
<3> ah dang. cause i am incrementing
<2> feti_: A bit of overhead, yes. But, mutxes are very, very fast these days.
<3> that's all this var is for ;(
<2> If your thread did nothing but lock/access/unlock, it could probably do that millions of times per second.
<3> oh ok
<3> no worry then
<4> we used to have atomic_inc() which mapped to asm something on intel
<4> 1 instruction, with lock
<4> and mutex,++,mutex on other platforms
<4> actually, if you time ++ vs (lock,unlock), there will be thousand-time difference
<4> hehe
<4> or maybe there will be not
<4> depends on the platform
<4> on intel, mutexes are fast
<3> what about opterons
<3> i'm ***uming it's not gonna make a difference to me if i'm only using 2 mutexes per client request
<3> per loop
<3> 1 to accept the connection from fastcgi, the other to increment thread-based stats
<4> opterons are ok, too
<5> Aha.
<6> opterons seem to rock at everything
<3> all i use here for this client
<3> and i'm happy with them
<5> I couldn't afford an Opteron =(
<5> So I got an Athlon64
<6> aedinius: how many bogomips do you get?
<5> I don't know.
<6> bogomips: 6016.20
<5> Never ran Linux on it, so it was never easily available.
<3> man, my kids/wife ****ered me into getting arby's for lunch
<5> Not that bogomips means anything at all
<3> now i feel all jiggly
<6> it's a nicer number than mhz
<5> zid, wow, you can do 6000 nops per second.
<5> 6000 million nops.
<5> zid, I'm sure it is.
<4> zid_: are you same as LordZid ?
<6> no
<7> how do you mean no
<6> I'm his imaginary friend
<4> which one is better ?
<6> me
<4> aha
<0> hmm
<6> eww, a niv
<0> i should write a quick program to test the bogomips on this ultra60
<0> gross, a zid
<0> 8)
<6> sorry, I forgot to bath
<3> i have a struct where i want to have a mutex stored, but i'm ***uming i can't if i use PTHREAD_MUTEX_INITIALIZER since the struct can't have a static member?
<4> i always thought that bogomips stand for 'bogus mips'
<3> do i have to initialize the mutex separately?
<4> feti_ pthread_mutex_init is your friend
<5> WeirdMish: They do.
<3> heh
<5> WeirdMish: IT's how many millions of nops your box can do per second. =]
<5> ne
<4> BILLIONS
<5> billions?
<5> mips is millions.
<6> 1 cycle for a nop on x86, I have 3000000000hz
<4> very fast architechures can do millions of nops per cycle ?
<4> BILLIONS
<0> not per cycle
<0> per second
<3> fhqwhgads!
<6> 0x909090909090909090909090909090909090909090909090 save that as .com and run it! ;)
<5> Err.
<5> That's the timer thing in c?
<8> 2.8ghz roughly means 2.8 billion nops per second
<5> sigalrm
<0> dont forget to mov ah, 4Ch int 21h (i think that's DOS terminate program)
<6> aedinius: 0x90 == bop
<6> 0xc3 = ret
<0> c9 = leave
<6> 909090909090909090909090C3 should work fine
<9> bop?:P
<5> zid, What?
<0> nah, zid, you gotta terminate the program
<0> in DOS
<6> ret works fine in DOS
<0> really? i don't think that's normal
<6> yes, it is
<6> the PSP contains an int 20h, and the stack is set to uit
<6> iirc
<0> how does the PSP contain an int 20h?
<0> the program segment prefix?
<6> yes
<6> 128 bytes of header
<6> has the command line and some other nice stuff
<0> what does int 20h do again?
<6> returns to DOS int he end
<6> in the*
<0> oh
<6> it's the easier way of doing the 4C thing
<6> ret / int 20h / mov ... int 21h/
<0> i thought everyone used ah=4Ch/int21h
<0> ah
<6> all do the same thing
<0> me too.. it's been a while though
<8> ret only works in .com files though and not .exes. (or is it vice versa?)
<8> to end the program
<6> ret works in .com
<6> I know that for a fact
<0> alipha: i think you might be right, because .exes could cloobber the stack
<0> since they change SS
<0> or, are likely to
<6> retn :P
<6> if your stack is fscked
<6> niv: i take it I know you from #asm and I didn't just make you up and inject you into reality
<0> yah i think so
<0> i havent been there in a bit
<6> I haven't been in years, it's full of tards now
<6> major ***hole tards
<0> hehe
<0> lots of channels like that now
<5> Hm. My bogomips doens't work right.
<5> My T2400 comes out at 298 bogomips
<0> aedi: did you write your test in asm? or in C + inline asm and verify it's code in a debugger like dbx
<0> hmm
<5> I don't know Intel asm
<6> 'nop'
<6> :P
<0> what's the best way to count each bogomips
<0> since you're supposed to only be doing nops
<0> you really shouldnt be incrementing anything
<0> *count each nop
<5> I'm counting adds
<6> adds are costly
<6> do an xor
<10> how can I synchronize between processes in Linux ?
<6> /exec -o cat /proc/cpuinfo | grep "bogo"
<10> do semaphores work?
<5> Heh
<5> my SPARC gets 15.66
Return to
#c
or
Go to some related
logs:
duotix
#debian
#politics
pfctl -s info Debug: urgent
#winxp
how to build an Airbus A380 in 7 minutes.*
yum install rebuild
#gamedev
#politics
#politics
|
|