00:43:08 -!- nooga has quit (Ping timeout: 248 seconds). 00:50:30 kmc: I joined #python earlier and they were making fun of how stupid those static languages and people who use them are. 00:51:18 shachaf, do they ever think about what the most common implementation of Python is written in? 00:51:41 Vorpal: that's a silly argument 00:51:45 Vorpal: "I hate making hardware." 00:51:48 shachaf: like bizarro world #haskell, eh? 00:51:55 "Are you aware what your software runs on?" 00:52:02 kmc, true, but so is the idea that static languages are stupid 00:52:18 shachaf: ahahaha 00:52:20 shachaf, hardware is awesome though not easy. 00:52:23 Vorpal: It's a silly idea but that counterargument isn't very valid. 00:53:13 hardware afaik is mostly long to design :D 00:53:36 optimised assembler is like 10 times slower to write than C++ for instance 00:53:53 though it's partly processor dependent 00:55:52 anyway some good reasons to use statically typed languages: Better error checking at an early stage (compile time errors are much better than runtime errors) 00:55:52 kmc: Did I just troll-by-proxy? 00:55:52 another good reason is that it provides the optimiser with much more information 00:55:52 Vorpal: You don't need to tell me about advantages of statically-typed languages. 00:55:53 I think a statically typed language with some support for dynamic typing if you really want to (and where the dynamic typing would be easy to spot for someone reading the code) would be the optimal way to go. Something like a (static!) type Dynamic that can be contain any type or such. Wasn't there something for haskell kind of doing that? 00:56:29 that would probably be nice yes 00:56:45 madbr, I have written some VHDL. And that isn't even on the level of designing transistors and so on. Presumably doing ASIC development is even harder than just working against an FPGA 00:57:07 Also with std::string, vector and map as basic types instead of half grafted on things 00:57:34 no 00:57:39 fewer baked in things is better 00:57:53 Vorpal: that Dynamic type is part of the GHC Haskell standard library, yes 00:58:02 yeah but the base weakness of C/C++ is the lack of built in types 00:58:04 uh 00:58:09 C/C++ 00:58:09 ahaha that makes no sense 00:58:12 kmc, really haven't worked that much with haskell, only the basics 00:58:12 yep 00:58:22 yeah but the base weakness of C/C++ is the lack of variable size structures 00:58:37 Vorpal: oh, well, wishing for a static language with a feature Haskell already has is a common enough occurrence 00:58:45 everything is fine as long as none of your strings or arrays ever change size 00:58:49 I'm not sure a string should be a fundamental type. Sure there are some good arguments for it. It definitely shouldn't be handled as an array of chars. But I think a linked list of chars (in a language having the linked list as a fundamental type, like Erlang or Scheme) is a good representation. 00:59:06 What does "fundamental" mean? 00:59:12 Vorpal: that has terrible performance though 00:59:19 vorpal: that's kinda impossible to parallelize 00:59:21 A language should let you make your own abstractions. 00:59:28 i think you need some general purpose type for things contiguous in memory 00:59:33 and you can apply that to characters 00:59:35 That's probably the most important thing in a high-level language. 00:59:36 abstractions? 00:59:40 shachaf, I presume kmc meant "baked into the syntax of the language, and is more than just syntax sugar for something else" 00:59:41 I don't need abstractions 00:59:46 I need arrays of floats 00:59:49 and shit like that 01:00:08 i think you need some general purpose type for things contiguous in memory and you can apply that to characters <-- you can create a binary containing a string in erlang as well 01:01:00 purely functional data type though (can sometimes be optimised to be mutable if the compiler can be sure it won't be visible elsewhere though), so there are some interesting things to be aware of. 01:01:25 mutable types are nice 01:01:41 A language should let you make your own abstractions. <-- so something like lisp? 01:02:07 Vorpal: are there popular implementations which do that? 01:02:08 Vorpal: That's one kind of abstraction. 01:02:17 kmc, hm? 01:02:29 optimize data structures to be mutable locally 01:02:38 kmc: Languages with uniqueness typing, maybe? 01:02:42 the problem is the aliasing caused by pointers 01:02:43 kmc, popular implementations of erlang? 01:02:47 of anything 01:02:50 whatever you were talking about 01:02:50 kmc, there is just one Erlang implementation 01:03:00 I guess it is the most popular Erlang implementation 01:03:02 XD 01:03:02 "is that a thing at all" 01:03:05 is what i'm asking 01:03:19 it's a common misconception about GHC and Haskell 01:03:21 kmc: It's a thing that they tell young Haskell programmers to get them to go to sleep. 01:03:26 yeah 01:03:32 to my knowledge GHC does not really do that 01:03:34 I believed it for a while! 01:03:42 but it does eliminate intermediate data structures entirely, sometime 01:03:43 kmc, oh yeah, erlang can optimise certain appending style operations to mutate the data in certain cases 01:03:58 afaik it is fairly restricted, but it is documented in the efficiency section of the manual 01:03:59 the nice thing about pure functional data structures isn't some weird compiler trick 01:04:20 it's that they *fundamentally* support efficient non-destructive update 01:04:33 if you implement a binary search tree in the most naive way in Haskell with a stupid naive Haskell compiler 01:04:38 pikhq, why are there no Tcl "data structures" that map cleanly to a bunch of Tcl commands? 01:04:39 and you add a new node into a tree 01:04:40 "give your compiler this one weird tip to make your data structures support efficient non-destructive update" 01:04:48 the "new tree" will share most of its storage with the old one 01:04:57 Lists are good for one Tcl command, thus making construction with [list ... ] simple 01:05:04 There seems to be nothing for multiple commands 01:05:05 kmc, well binaries are fairly efficient anyway. A lot of operations on them will do stuff like "this is a view of byte 8 to byte 83 (plus 3 extra bits) of this underlying binary" 01:05:06 kmc: Not with a naïve implementation that copies everything! 01:05:09 won't that have a zillion tiny allocations? 01:05:14 Which might be the most obvious implementation. 01:05:19 -!- monqy_ has joined. 01:05:20 -!- monqy has quit (Quit: Reconnecting). 01:05:23 honqy_ 01:05:24 (yeah binaries don't have to be whole byte sizes) 01:05:41 madbr: sure, but a typical Haskell runtime uses an allocator where allocation is vastly cheaper than malloc() 01:05:41 -!- monqy_ has changed nick to monqy. 01:06:01 heh really 01:06:01 though you pay for it later in the garbage collector 01:06:04 well yes 01:06:09 kmc, anyway LISP style linked lists support prepending for example without copying 01:06:10 allocation in GHC is just a matter of incrementing a pointer 01:06:15 what does it do, just increment a pointer? 01:06:23 Vorpal: that is an example of my fundamental property, not of some compiler trick 01:06:24 or tail without copying 01:06:42 but what does it do later when half the data in the array is alive and half is not 01:06:50 recompact everything???!?? 01:06:53 compacting garbage collector 01:06:53 yes 01:07:00 which is also good for cache utilization 01:07:13 ???!?? 01:07:31 yeah provided you can lock the whole program for like 200ms once in a while 01:07:37 yeah 01:07:47 allocation in GHC is just a matter of incrementing a pointer <-- like a stack then? 01:07:51 can't do that in the kind of code I write :D 01:07:55 if you have realtime constraints then the story is different 01:07:56 (games, software synths) 01:07:59 sure 01:08:16 hm real time haskell, is there any hard realtime haskell variant? 01:08:19 both of which are traditionally programmed in C++ 01:08:23 Vorpal: ask in #haskell 01:08:30 Vorpal: yes, like, a stack, but you never pop either 01:08:44 you just accumulate objects in this region, in order, until it's full 01:08:46 then you run the GC 01:08:47 btw, I'm going to be working with hard realtime systems pretty soon 01:08:50 "like, a stack, but you never pop" 01:08:52 whoa, dude 01:08:53 ie you leak until the GC runs 01:09:05 got a job at Atlas Copco, starting the end of this month 01:09:10 madbr: uh, yes 01:09:17 that is how a GC works 01:09:31 Not a reference-counting "GC"! 01:09:35 using the word "leak" there is disingenuous 01:09:41 I guess that's not really a GC. 01:09:52 shachaf: since when did words in CS mean anything? 01:10:01 "like, a stack, but you never pop" <-- you could make your address space cyclic and use that as a cache kind of thing maybe?? 01:10:04 kmc: Good point. 01:10:18 you need some way to detect overwritten references though 01:10:48 really it's not disingenuous, just false 01:10:56 a leak is an dead object which will never be freed 01:11:09 well, I guess it's a hyperbole 01:11:18 you say "hyperbole" i say "wrong" 01:11:21 it's not really a leak 01:11:25 anyway i'm not saying GC is the answer to anything 01:11:29 but it is more efficient in some ways 01:11:32 and less efficient in others 01:11:37 leak: Sometimes a leak is an object which has been freed despite best efforts to keep it hidden! 01:11:45 s/lea(.)/\1mc/ 01:11:47 people who don't like GC tend to paint it as strictly less efficient and for lazy programmers only 01:11:50 that's simply not true 01:12:06 since when was reference counting considered a GC? You could have a GC that detect and take care of cycles in such a system though (lol python) 01:12:13 compacting garbage collection gives you faster allocation and better cache utilization, at the expense of periodic pauses 01:12:29 I'm not convinced about better cache use 01:13:14 ok 01:13:18 well i don't have any numbers handy 01:13:24 this isn't an area i know in depth 01:13:31 what about non compacting GC? 01:13:45 madbr: Sucks. 01:14:04 It gives you all the downsides of GC with most of the downsides of malloc. 01:14:07 madbr: Better cache use than what? 01:14:21 pikhq, I'm pretty sure many VMs use those for small collections 01:14:30 with bigger, compacting collections more rarely 01:14:36 unless I missremember 01:14:45 misremember* 01:14:56 shachaf: than traditional malloc-using C++ code I guess 01:15:04 you shouldn't be using malloc in C++ 01:15:09 Vorpal: The smaller your heap the cheaper compacting GC is. 01:15:14 you should use new, preferably with smart pointers 01:15:18 pikhq, hm true 01:15:21 kmc: same as malloc 01:15:31 i guess by "C++" most people mean "C with whatever C++ features i feel like understanding" 01:15:42 pikhq, well if you have a pool for very large allocations it might not be a good idea to compact that too often I guess 01:15:48 except for the smart pointer thing 01:16:04 Vorpal: Yes, you'd probably be best trying to split it into small and large object pools. 01:16:12 kmc, what are C++ smart pointers? 01:16:15 Compacting large allocations is really rather painful. 01:16:26 a smart pointer is a class which wraps a pointer, but provides some nicer semantics and/or guarantees 01:16:27 vorpal: reference counted objects AFAIK 01:16:29 pikhq, combined with a generational GC as well 01:16:33 they aren't always reference counted 01:16:39 you can have a reference-counted smart pointer 01:16:52 And besides which, you'll probably want to make it so that space contains objects that don't reference other things. 01:16:55 a smart pointer is a class which wraps a pointer, but provides some nicer semantics and/or guarantees <-- like that which more higher level languages do? 01:17:03 (because most large buffers won't be giant pointer buffers) 01:17:17 anyway what, apart from reference counting could they usefully provide in C++ 01:17:17 you can construct a shared_ptr from a T*, or copy-construct it from another shared_ptr 01:17:35 Vorpal: They basically are reference counting... 01:17:39 it records somewhere the number of shared_ptr's holding that particular T* 01:17:43 pikhq, " they aren't always reference counted" 01:17:47 pikhq, so he is wrong then? 01:17:49 the destructor for a shared_ptr decrements the count 01:17:52 let me finish 01:17:54 god 01:17:55 Vorpal: No, he's merely being more accurate. 01:18:00 hm okay 01:18:03 when it drops to 0, it calls delete on the original pointer 01:18:04 anyway 01:18:08 that's a reference-counted smart pointer 01:18:12 but you can also make other kinds 01:18:20 i guess by "C++" most people mean "C with whatever C++ features i feel like understanding" -- which is actually fine so long as you don't have to read anyone elses code 01:18:26 kmc: such as? 01:18:30 like unique pointers 01:18:55 Yeah. They also can be used to give you guarantees like "delete this when it falls out of scope". 01:18:58 kmc: How do you catch a unique pointer? 01:18:59 kmc, how does it keep track of shared_ptr though? What if I pass a function a reference to a shared_ptr? Or are they small enough that you usually pass by value and invoke copy constructors all over the place? 01:19:07 A: Unique up on it 01:19:08 Vorpal: the latter 01:19:27 Vorpal: the compiled representation of a shared_ptr is probably the same as a T* 01:19:39 dunno 01:19:42 kmc, plus a reference count surely? 01:19:44 the reference counting is done in some global hidden structure 01:19:49 ah... 01:19:51 no, the reference count has to ba global 01:19:52 well 01:19:54 kmc, so are they thread safe? 01:20:03 if each shared_ptr had their own count, then they would all have a count of 1... 01:20:07 it should be in the structure that is getting counted no? 01:20:12 madbr: you can build those too 01:20:15 "intrusive shared pointers" 01:20:22 more programmer effort, somewhat more efficient 01:20:39 Vorpal: I don't know about the thread saftey guarantees of Boost's or C++11's implementations of this idea 01:20:45 doing it without having it in the structure being counted sounds very much like a kludge 01:20:50 in general yes, you can make a thread-safe shared pointer 01:20:58 doesn't seem like a kludge to me, really 01:21:07 only a little bit 01:21:13 At least, no more so than anything else in C++. 01:21:20 pikhq, touche 01:21:27 thread-safe shared pointer? what, by locking a mutex to it every time you manipulate it? :D 01:21:56 madbr: well first of all, it would only be when you create/destroy a shared_ptr, not dereference one 01:22:00 madbr, implementing an atomic counter isn't that hard targeting most ISAs 01:22:15 implementing a hash table of atomic counts is harder 01:22:20 but still quite doable 01:22:29 why a hash table? 01:22:35 given that this is a piece of core library code which is hopefully not re-implemented in every project 01:22:38 oh right, if it doesn't have anything except the pointer 01:22:39 though knowing C and C++, it likely is 01:22:44 a pointer pair seems better 01:22:46 Vorpal: you need a map from T* to reference count 01:23:03 Vorpal: pointer to T and also pointer to its count location in the table? 01:23:04 you'd need atomic count+value no? 01:23:05 yeah maybe 01:23:07 i don't know how it's done 01:23:26 You could also maybe use a per-thread count for some things. 01:23:46 otherwise your count may be accurate but it can still change whenever no? :D 01:23:54 madbr, x86 provides atomic increment/decrement iirc. And there is always CAS 01:24:14 you need atomic [inc/dec PLUS value read/write] 01:24:17 I *think* 01:24:27 of course if they are in a table, that is going to play hell with the cache line ownership between the CPUs 01:24:30 shachaf: yeah 01:24:57 i think the Linux kernel uses per-CPU reference counting for some objects 01:25:15 don't remember the exact semantics 01:25:16 the linux kernel uses a lot of snazzy data structures 01:25:34 kmc: It's a fun performance issue when you have per-thread counters for something (not referece counts, just integers) and you put them all in one array, so that each thread does arr[tid]++; 01:25:54 shachaf, that is just going to kill the performance XD 01:25:56 Vorpal: Well, yes. A kernel is fundamentally no more than a pile of allocators and schedulers. :) 01:26:24 pikhq, a lot of device drivers too (unless a micro kernel, in which case it is just some device drivers) 01:28:28 how real time are real time OSes these days? 01:28:43 uh, completely? 01:29:03 well, what latency can you get :D 01:29:08 ok 01:29:10 that is a different question 01:29:18 1ms? 100us? 10us? :D 01:29:19 madbr, you misunderstood the meaning of a real time OS 01:29:26 "real time" does not mean "super low latency" necessarily 01:29:30 it means that you care what the latency is 01:29:40 you can have a "hard real time" system where the latency bound is 60 seconds 01:29:50 it's still hard real time because if you miss that deadline, the plane blows up or whatever 01:29:54 It's not all that /likely/, but it fits the definition :) 01:29:59 i think it is pretty likely 01:30:02 "A key characteristic of an RTOS is the level of its consistency concerning the amount of time it takes to accept and complete an application's task;" 01:30:04 planes take a while to blow up 01:30:11 that's latency 01:30:14 it means that you can work out guarantees that the latency running a specific set of software on it will be within specific limits 01:30:21 yes, it is about predictable and guaranteed latency bounds 01:30:27 madbr: Yes, CONSISTENCY, not BREVITY. 01:31:30 hi Gregor 01:31:33 I confused you with Vorpal 01:31:42 what 01:31:42 but then if your guaranteed time is 100ms... that's still not so cool :D 01:32:00 that depends on the application 01:32:06 you can have a "hard real time" system where the latency bound is 60 seconds <-- I'd hate to draw the timing diagram for that, given that most other stuff will probably be in the millisecond range 01:32:09 you really do not seem to be getting this idea 01:32:13 shachaf: Capital letter, five more letters. 01:32:28 Gregor: Right. 01:32:29 but yeah was asking for irl values 01:32:35 * Vorpal is now known as Vergor 01:32:40 oops 01:32:43 * Vorpal is now known as Vregor 01:32:50 I wonder if capital letters are "actually" easy to distinguish without reading them. 01:33:06 If you gave someone who can't read English a text with capital and lower-case letters, would they be able to pick out the capitals? 01:33:23 Capital thorn is smaller than lowercase thorn! 8-D 01:33:36 shachaf, well the rest of the word shape is different too, r is half the height of l 01:34:03 shachaf, if they know the latin script, sure? 01:34:04 kmc: just say that you don't know the values and don't care, jeez 01:34:39 madbr, your question made no sense. 01:34:43 madbr: Come on, don't troll kmc. :-( 01:35:05 it's dumb that you keep badgering us over t his 01:35:14 when it's probably plastered all over the front page of anyone marketing a RTOS 01:35:26 madbr, most real time systems are probably slower than your average PC in average response time. But the thing is, you don't know the maximum response time on your OS. It might suddenly swap trash for example 01:35:39 shachaf: at least I haven't still got Virgil in here ;) 01:37:43 hm 01:37:54 seems more for military usage then yeah 01:38:04 and planes 01:38:19 madbr, your car probably contains at least one if it isn't too old 01:38:32 The ABS brakes for a start 01:38:39 any ESP system 01:38:41 mhm 01:38:53 because if those took too long. Yeah would be bad 01:38:59 realtime control systems outnumber "computers" by a huge factor 01:39:05 not all of them use an "operating system" though 01:39:18 many are just simple microcontrollers running a single program at a deterministic speed 01:39:19 kmc, control systems in general outnumber what we normally think of as computers 01:39:26 yeah 01:39:44 true 01:39:54 dishwasher, freezer, TV, washing machine. Doubt any of those run RTOS. 01:40:04 or well maybe they though (not the TV though) 01:40:13 s/they/they do/ 01:40:28 most digital TVs run Linux 01:40:29 no idea what they put in TVs these days 01:40:41 as did set top boxes during the analogue->digital transition 01:40:51 vxworks is probably convenient to put in a dishwasher even if you don't use the real time properties. 01:40:58 either that or it runs on bare metal 01:41:07 in which case it is most likely not real time in any way 01:41:18 huh? 01:41:26 that's about as real time as it gets. 01:41:27 hm? 01:41:32 if you're the only program running on the chip... 01:41:49 kmc, you have to design that program so you can be sure it won't ever enter an extra long loop though 01:41:51 and the chip has no cache and out of order execution? 01:41:53 otherwise it isn't real time 01:41:59 Vorpal: sure 01:42:09 vorpal: some people do that afaik :D 01:42:14 or you do everything time sensitive in a timer interrupt 01:42:19 madbr, sure, I done it at university 01:42:20 but yeah 01:42:27 using vxworks was much easier though 01:42:30 simple microcontrollers give you totally deterministic execution 01:42:34 no cache, no out of order execution 01:42:38 since then you knew the scheduler would prioritise the right thing 01:42:43 each instruction takes a known number of clock cycles, always 01:42:49 without a scheduler, well you have to get everything perfectly right 01:42:56 kmc: ie too long :D 01:43:04 madbr, not really 01:43:16 madbr, they work fine for what they are designed for 01:43:26 well, not too long for a microcontroller application where there's little data to crunch through 01:43:33 madbr: that's fucking annoying, stop asserting that things are "too slow" without knowing what the application is 01:43:43 you strike me as one of those people who programs in C because it means your e-penis is so big 01:43:49 kmc, he is obviously trolling you 01:43:52 yeah 01:44:06 don't feed the troll (I know that can be hard) 01:44:22 kmc: don't be silly. He obviously writes direct to machine code. In binary. With butterflies. 01:44:40 with e-penis 01:44:48 eheh 01:44:48 soundnfury, you make me laugh. He loads customised microcode into the processor 01:45:03 i shit trains, what now 01:45:05 don't be silly, he doesn't use processors with microcode, they're "too slow" 01:45:13 XD 01:45:25 hardwired logic 4 lyfe 01:45:38 it's the kind of system that doesn't have cache miss because essentially every memory access is a cache miss :D 01:45:42 Why am I still looking at Tcl instead of Lisp? 01:45:48 so you have deterministic time 01:45:50 TTL logic is kind of fun. 01:46:00 madbr: no, it's more like every memory access is a cache *hit* 01:46:05 AVR microcontrollers have all SRAM 01:46:07 What about time-loop logic? 01:46:10 or it has like 1k ram so it doesn't have cache misses yeah :D 01:46:12 kmc, hm do AVR processors even have a pipeline? 01:46:19 in fact there's not much distinction between registers and RAM 01:46:25 I guess some might have a 2 stage pipeline or something simple like that 01:46:44 Vorpal: isn't "TTL logic" a PIN-number-ism? 01:46:45 the registers are just the first n locations in RAM, they have a special addressing mode but show up as normal memory too 01:46:50 soundnfury: oh god 01:46:52 soundnfury, yeah and? 01:47:00 that is the dumbest thing to care about 01:47:13 kmc: what can I say? I'm a pedantic dickweed 01:47:19 soundnfury, it is also a CD disc thing. It is not quite a Personal PIN Number-ism though 01:47:24 saying "TTL is kind of fun" is more ambiguous and awkward 01:47:29 language exists to serve the needs of communication 01:47:35 not to satisfy the arbitrary rules of pedantic dickweeds 01:47:38 Vorpal: my eyes my eyes it burns 01:47:41 do you also object to "all OK"? 01:47:41 Ah, kmc. 01:47:49 the wires very quickly ends up being tricky to keep track of though 01:48:10 I remember doing a binary->2 digit BCD converter in a lab at university 01:48:11 kmc: the rules aren't arbitrary, they exist to serve the needs of communication 01:48:23 after all OK might be (nobody's quite sure) an initialism for "oll korrect", an intentional misspelling of "all correct" 01:48:24 the mess of wires, aiee 01:48:27 so "all OK" is ambiguous 01:48:31 -!- ais523 has quit. 01:48:31 er redundant 01:48:33 just like "ATM machine" 01:48:35 am i right 01:48:45 kmc: Oh no! 01:48:57 We don't *know* whether it's redundant or not! 01:49:05