00:10 <hobomatic> is there a general way to pass flags to the linker from ponyc, or should I instead just do linking seperately if i need to pass custom flags?

00:12 <muhajir> Hi everyone

00:12 <hobomatic> hello

00:17 <muhajir> Ah, I thought nobody is online. I just found pony lang yesterday. And it seems really fun. So what's reason making pony object oriented, well you know some other lang like rust and golang not going to object oriented, I know that oo in pony does favor composition rather than inheritance. Note that I am against object oriented and not golang nor rust developer. I just want to know why?

00:17 <muhajir> I am sorry , I mean : * I am not against Object Oriented

00:18 <hobomatic> the way in which pony is object oriented isn't really that far off from how go and rust are object oriented

00:19 <hobomatic> and they are all object oriented (loosely speaking)

00:22 <hobomatic> i guess that doesn't actually answer you question, but i don't actually know why, just how its concept of OOP relates to other things

00:25 <muhajir> Ah, I thought they're far. Thanks for the answer brother. I'll explore more on pony.

00:26 <muhajir> And btw, what is the state of pony for web development right now?

00:30 <hobomatic> I don't know much of anything about the library ecosystem, but there are packages in the standard library related to HTTP and TLS. As far as frontend goes, I am not sure there is much of anything at all

00:31 <hobomatic> you should stick around and wait for better answers from more experienced people, but i figure I can give some vague probably wrong answers in the mean time

00:32 <hobomatic> IRT the way that pony is object oriented, one important aspect is that classes don't fill the role of supertypes at all. Compared to rust, for instance, classes are more like Impl's than Traits

00:33 <hobomatic> and then you have traits and interfaces to act as supertypes

00:34 <hobomatic> traits are sort interfaces and abstract classes in most languages, and interfaces are like golang interfaces, not requiring subtypes to declare that they implement them

00:44 <muhajir> Hmm, many thanks for exploring the topic

00:59 <hobomatic> my impression of the over-all direction that the language is going is that its trying to be a language for writing distributed systems, but along the way it has stopped to get local concurrency right

01:01 <hobomatic> so, more like erlang with a strong static type system and native code generation, rather than something like rust or golang

01:21 <muhajir> I've tried elixir few weeks ago, and I like it. And was looking for static & native lang too. So when saw pony, It really "clicks" haha

01:40 <hobomatic> I just like good type systems, and languages that prioritize being able to isolate some part of your code from certain resources (so that you can use untrusted code)

01:43 <codenoid> Hi, how I can print an array

01:45 <muhajir> Hello Mr. rubi.

01:47 <codenoid> hei,

01:48 <codenoid> I still can't find the method to print an array,

02:02 <hobomatic> i don't think there is one. It does not implement stringable

02:26 <codenoid> Oh, ok

04:22 <hobomatic> hmm, I am guessing the reason there is no string() method for Array (or Seq or List) is that there is no good way to put a constraint on a type variable in the receiver's type expression

04:23 <hobomatic> and if there is a way, its not at all obvious to me

04:24 <hobomatic> well never mind

04:24 <hobomatic> thats not right

04:28 <hobomatic> nope, can't just reuse the type variable in the method's type arguments

11:24 <SeanTAllen> hobomatic: because the items in a list or an array might not be Stringable. You can write your own utility primitive that takes an Array[Stringable] and then does the printing.

11:26 <SeanTAllen> hobomatic: --help will show you all the ponyc options including --linker

11:27 <SeanTAllen> muhajir: what is it you were interesting in knowing about OO and Pony?

11:28 <SeanTAllen> codenoid: you cant print an array because the items in an Array might not be Stringable. You can write your own utility primitive that takes an Array[Stringable] and then does printing.

16:17 <BUD1> Hi Good evening

16:22 <BUD1> Just tried http server from https://github.com/ponylang/ponyc/blob/master/examples/httpserver/httpserver.pony and do some local "hello world" benchmark test.

16:22 <BUD1> Activity monitor show 4 threads but i got middle performance compared to another language (Crystal)

16:23 <BUD1> which use only single core

16:25 <SeanTAllen> BUD1 that http server was not written with performance in mind, merely to be able to do basic http serving

16:25 <SeanTAllen> There are numerous performance issues with it

16:27 <SeanTAllen> I'd also point out that 4 threads is far from guaranteed to get better performance than 1. Depending on workload, 1 cpu/thread will often out-perform 4. That said, the http server was not written with performance in mind.

16:28 <SeanTAllen> I pointed to specific issues in this email thread: https://pony.groups.io/g/user/topic/pony_did_poorly_in_a_recent/5411536?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,40,5411536

16:28 <SeanTAllen> You can read more about writing high-performance Pony code here: https://www.ponylang.org/reference/pony-performance-cheatsheet/

16:29 <SeanTAllen> Lastly, setting up benchmarks to get "accurate" results can be notoriously hard. Especially if you don't really understand the system under test and how it utilizes resources.

16:29 <SeanTAllen> But again, in this case, I would go back to "the Pony http server in the standard library wasnt written with performance" in mind.

16:31 <SeanTAllen> If you or anyone else is interested in writing a high-performance http server in Pony, I'd be happy to help guide efforts. One of the reasons I wrote the Pony performance cheatsheet was so that others could assist in writing high-performance Pony libraries including things like HTTP parsers and what not.

16:47 <BUD1> I'm still new to pony and need a lot of experiences.

16:49 <BUD1> Doing Performance stuff is not on my task at the moment.

16:50 <BUD1> Thank you for pointing the issue

16:52 <SeanTAllen> Quite reasonable BUD1. I'm here in general to help with things.

16:54 <BUD1> I'm curious about "4 threads is far from guaranteed to get better performance than 1", can you please explain?

16:55 <SeanTAllen> if you have enough work to max out 1 thread, but not more than that

16:56 <SeanTAllen> then the overhead of sharing work between multiple threads is going out weigh the non-existent benefit you are getting from having more than 1 thread

16:57 <SeanTAllen> to use an analogy. imagine for a moment that there is 8 hours of work to do. you can either do it by yourself in 8 hours or you can split it with another person but while you are splitting it, you have to constantly communicate about who should do what. odds are, having that extra person to "help" is going to slow things down

16:58 <SeanTAllen> going back to computers for a moment, using more than 1 cpu, depending on the job, you could end up ruining per cpu caching, introduce context switching and what not.

16:59 <SeanTAllen> Pony scheduler threads by default run as 1 per cpu

16:59 <SeanTAllen> So, in theory, anything that stays on the same scheduler is going possibly benefit from cache advantages.

16:59 <SeanTAllen> Imagine if you will, 2 actors that send messages back and forth.

17:00 <SeanTAllen> Actor A send message 1 to Actor B who sends reply 1 back to Actor A

17:00 <SeanTAllen> if this is all done with 1 scheduler, that is 1 thread, then when Actor A send message 1 to actor B, the CPU running the scheduler should already have message 1 cached when actor B goes to retrieve it.

17:01 <SeanTAllen> This is going to be faster than if Actor A is one on scheduler thread (and CPU) and Actor B is on another.

17:01 <SeanTAllen> "CPU caches" are huge for providing improved performance

17:01 <SeanTAllen> Are you familiar with the various CPU caches BUD1?

17:02 <SeanTAllen> I'm going to post a couple resources:

17:02 <SeanTAllen> https://mechanical-sympathy.blogspot.com/2013/02/cpu-cache-flushing-fallacy.html

17:02 <SeanTAllen> https://mechanical-sympathy.blogspot.com/2012/08/memory-access-patterns-are-important.html

17:03 <SeanTAllen> https://gist.github.com/understeer/4d8ea07c18752989f6989deeb769b778

17:03 <SeanTAllen> https://mechanical-sympathy.blogspot.com/2011/07/memory-barriersfences.html

17:03 <SeanTAllen> There's a ton more stuff out there, but, I'm going to stop there.

17:04 <SeanTAllen> My point with all of this is merely to support the statement that more threads, more concurrency, more parallelism, doesn't automatically mean better performance. It can often hurt performance.

17:06 <SeanTAllen> This is all very handwave-y because we aren't even talking about a specific program or a part of a program. For example, how does Crystal do scheduling? How does Pony do scheduling? Does having more threads than required for the workload add overhead? How much?

17:06 <SeanTAllen> Performance can be very complicated and benchmarking is wicked hard.

17:06 <SeanTAllen> Sadly most benchmarks are worthless or presented as proving something they don't.

17:09 <SeanTAllen> That was a lot of information to dump on your BUD1. Hopefully it was helpful.

17:09 <BUD1> What an explanation. Thank you.

17:10 <BUD1> In context of http server, will it make different when it run multiple process rather than multiple thread/parallelism?

17:10 <SeanTAllen> You're welcome.

17:11 <BUD1> for example running http server 4 times and reuse the http port

17:11 <SeanTAllen> at the least, that would depend on the workload

17:11 <SeanTAllen> but i dont have an answer for you, its something that would need to be tested.

17:12 <SeanTAllen> how you share the port amongst processes is going to have a large impact.

17:13 <SeanTAllen> my suspicion based on http servers in general is that multiple threads will do better than multiple processes.

17:14 <SeanTAllen> but at this point its pure intution and there's a ton of details that arent covered in the question that could have a large impact.

17:14 <SeanTAllen> i've never reused addresses across TCP listeners and measured what the performance implications are.

17:14 <SeanTAllen> that would vary across TCP implementations

17:15 <SeanTAllen> but going back to the initial point, if there is only enough work to power that one CPU, then adding more parallelism is probably going to hurt, rather than help performance.

17:16 <SeanTAllen> actually that is wrong, what i said, adding more parallelism might hurt.

17:16 <SeanTAllen> it really depends on the workload, the application and a ton of other factors. the only way to find out is to devise good benchmarks and then you will know for a specific workload, run in a specific way in a specific environment what the impact is.

17:20 <BUD1> "if there is only enough work to power that one CPU, then adding more parallelism is probably going to hurt, rather than help performance." i should remember this :)

17:21 <SeanTAllen> i overstated that initially

17:21 <SeanTAllen> it really depends on the workload

17:21 <SeanTAllen> however, people often see more parallelism as always good, which is not true.

17:22 <SeanTAllen> also people have varying definitions of parallelism and concurrency so, i should probably be more precise with my terms.

17:34 <BUD_1> Sorry, connection problem

17:38 <SeanTAllen> welcome back BUD_1

17:38 <SeanTAllen> if you missed anything, you can check the IRC logs: http://irclog.whitequark.org/ponylang

17:39 <BUD_1> Yes, i already checked. Does not miss so much :)

17:39 <BUD_1> Now i'm wondering how pony distribute actors to schedulers, will it push all to one CPU core first?

17:40 <BUD_1> To get benefit of the cache?

17:43 <SeanTAllen> The rules are currently very straightforward

17:43 <SeanTAllen> Lets assume just two actors for a minute

17:43 <SeanTAllen> When actor A sends a message to actor B one of two things will happen

17:44 <SeanTAllen> If actor B is currently scheduled to run on a scheduler, it will stay with that scheduler

17:44 <SeanTAllen> If actor B is unscheduled, it will be scheduled to be run by the same scheduler that is running Actor A

17:44 <SeanTAllen> which could possibly get cache benefits

17:44 <SeanTAllen> Then there is work stealing

17:45 <SeanTAllen> a scheduler that has no actors to run will attempt to steal actors from other schedulers

17:46 <SeanTAllen> the code for how work stealing current works starts around here: https://github.com/ponylang/ponyc/blob/master/src/libponyrt/sched/scheduler.c#L231

17:53 <BUD_1> When a scheduler steal from another schedule, let says actor C. This will still possible to hurt performance when C call actor D? Or D also get stolen with C?

18:01 <SeanTAllen> only a single actor is stolen at a time

18:01 <SeanTAllen> they aren't stolen as groups