copy` has quit [Quit: Connection closed for inactivity]
jemc has quit [Ping timeout: 252 seconds]
mrkishi has quit [Ping timeout: 240 seconds]
rurban has joined #ponylang
Matthias247 has joined #ponylang
rurban has left #ponylang [#ponylang]
nyarumes has quit [Read error: Connection reset by peer]
nyarum has joined #ponylang
Matthias247 has quit [Read error: Connection reset by peer]
Candle has quit [Ping timeout: 276 seconds]
Candle has joined #ponylang
hibnico has joined #ponylang
Candle has quit [Ping timeout: 276 seconds]
Candle has joined #ponylang
Candle has quit [Ping timeout: 260 seconds]
Candle has joined #ponylang
trapped has joined #ponylang
trapped has quit [Read error: Connection reset by peer]
trapped_ has joined #ponylang
Candle has quit [Ping timeout: 252 seconds]
Candle has joined #ponylang
trapped_ has quit [Read error: Connection reset by peer]
trapped has joined #ponylang
Matthias247 has joined #ponylang
Candle has quit [Ping timeout: 258 seconds]
Candle has joined #ponylang
M-hrjet has quit [Remote host closed the connection]
hibnico has quit [Quit: hibnico]
M-hrjet has joined #ponylang
unbalancedparen has joined #ponylang
<sylvanc>
TwoNotes: you can just say `this`
_andre has joined #ponylang
Perelandric has joined #ponylang
trapped has quit [Read error: Connection reset by peer]
trapped has joined #ponylang
trapped has quit [Ping timeout: 260 seconds]
michael_campbell has joined #ponylang
rurban1 has joined #ponylang
TwoNotes has joined #ponylang
<TwoNotes>
My program is using a lot more CPU time than I think it should. Are there any profilig tools?
rurban1 has quit [Quit: Leaving.]
rurban has joined #ponylang
<SeanTAllen>
your standard c ecosystem tools
Applejack_ has joined #ponylang
<TwoNotes>
Well, gprof depends on a special file that gcc generates. Can ponyc's generator create that file?
_andre has quit [Quit: leaving]
<TwoNotes>
With nothing going on, just waiting for external events, the programs use 5-30% CPU. Something is waking them up
<sylvanc>
`instruments` on osx works very well
<sylvanc>
or linux perf tools
<sylvanc>
or vtune, which is excellent
<sylvanc>
i think you were off-channel btw for:
<sylvanc>
TwoNotes: you can just say `this`
<TwoNotes>
Thanks, I did find that after a few tries.
<TwoNotes>
But I had to give up on that because I realized that if I call an FFI that never returns, the Pony scheduler gets blocked from delivering further messages, doesn't it?
<sylvanc>
an FFI that never returns consumes a scheduler thread
<sylvanc>
which is Not A Good Thing :)
<TwoNotes>
It is not actually CPU bound, but it does not return.
<sylvanc>
not sure what you mean by CPU bound
<TwoNotes>
Thats OK - I currently have that library running in a detacched mode where I communicate with it over TCP. Lots more overhead is all
<TwoNotes>
It is not in a loop. It is waiting for external I/O
<sylvanc>
oh, ok. but it still consumes the thread.
<TwoNotes>
yes
<sylvanc>
if the library has to do that, you could spin up a new thread for the library.
<TwoNotes>
I was willing to have it do that, but it would also be impossible to communicate with that actor wouldn't it?
<sylvanc>
yes, it would. consuming a scheduler thread is not a good plan :)
<TwoNotes>
I know that this FFI library already uses pthreads itself internally
<sylvanc>
then you could definitely spin up another pthread
<sylvanc>
and call the "never return" function from there
<TwoNotes>
But then how does stuff running in that pthread send and receive Pony messages?
<sylvanc>
depends on how you write it
<sylvanc>
if you write it in C, you can use the calls in pony.h
<sylvanc>
you might also be able to write it in pony
<sylvanc>
(by "it" i mean the function that the pthread executes)
<sylvanc>
since the signature in C is: void* (*fn)(void*)
_andre has joined #ponylang
<sylvanc>
which is ABI compatible with a method on a Pony object that takes no arguments
<TwoNotes>
The never-return call does call back to some functions of mine - that works. And I suppose they could somehow make them send messages to other actors
<sylvanc>
indeed they could
<TwoNotes>
But if it is in a separate pthread, the Pony scheduler would not see it, would it?
<TwoNotes>
Wouldn't it be in a separate pony-universe?
<TwoNotes>
And I would not be able to send messages *in* to the pthread, which is also necessary
<TwoNotes>
oh well. I will stay with the TCP method
<TwoNotes>
I use the new ProcessMonitor routines to spin up the external process
copy` has joined #ponylang
<sylvanc>
you can indeed send messages both out and in to the pthread
<sylvanc>
pony has the concept of unscheduled actors for this
<TwoNotes>
Where can I read about this? Are there examples of using pthreads i Pony?
<sylvanc>
i'm afraid not - the primary use has been in a closed source project
<sylvanc>
you would be a brave pioneer :)
<sylvanc>
the C header pony.h has limited info in it
<sylvanc>
and i can try to answer questions of course
rurban has left #ponylang [#ponylang]
<sylvanc>
the previous use was for using Pony to write a loadable DSO inside an existing C process
<TwoNotes>
I see a 'trace' hook mentioned in pony.h
<TwoNotes>
And a 'dispatch' function.
<TwoNotes>
Maybe I could use those to find out what is waking up my code
<sylvanc>
trace and dispatch functions for types are generated by the compiler
<sylvanc>
what OS are you using for development?
<TwoNotes>
Linux
<TwoNotes>
Linux on both x86_64 and ARMv7
<TwoNotes>
Oh, that 'tracing' mentioned in pony.h probably has something to do with how GC works
<sylvanc>
yes exactly :)
<sylvanc>
vtune would be the best way to profile your application
<sylvanc>
intel gives free licenses to open source contributors