Search logs:

channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present


http://bespin.org/~qz/search/?view=1&c=osdev&y=18&m=11&d=10

Saturday, 10 November 2018

02:54:44 <graphitemaster> Mutabah, https://github.com/mehcode/guerrilla
02:54:47 <graphitemaster> HAHA
02:55:40 <Mutabah> Ah, so that's what Moznet#rust-offtopic was talking about
02:55:42 * Mutabah reads
02:56:35 <Mutabah> ... oh sweet jesus
02:57:41 <Mutabah> Oh dear lord
02:57:51 <Mutabah> This is fucking evil
02:57:55 <Mutabah> ... I _like_ it
02:58:40 <graphitemaster> :D
02:59:41 <graphitemaster> Mutabah, at least you can't patch anything in the std crate
03:01:39 <Mutabah> I'm not sure why that's the case?
03:02:16 <graphitemaster> Mutabah, #[inline]
03:02:37 <Mutabah> Ah, well, yeah, anything inline you can't monkey patch like this
03:03:02 <graphitemaster> reminds me a bit of https://github.com/graphitemaster/libpartial
03:03:12 <graphitemaster> this at least solves a problem
03:03:17 <graphitemaster> that I think needs to be solved
03:03:36 <graphitemaster> a C like language with proper enclosures would be nice
09:55:34 <aalm> .roa
09:55:34 <glenda> 19 Satisfaction is not guaranteed.
09:55:39 <aalm> .theo
09:55:39 <glenda> You don't listen well either.
10:27:16 <geist> https://www.anandtech.com/show/13544/why-intel-processors-draw-more-power-than-expected-tdp-turbo interesting article
10:37:48 <lkurusa> thanks for the link, that was interesting indeed
10:48:02 <geist> i figured something like that was going on, definitely in laptop and ultrabook space
10:48:14 <geist> but didn't know that it was actually showing up on desktop world
11:31:27 <bauen1> wand tcp has yet another checksum, i swear the people designing arpanet where high ...
11:46:58 <mrvn> bauen1: wifi adds another one
11:48:00 <mrvn> graphitemaster: a C like language without char* (strings should be length+data) and range cheks on pointers would be nice.
11:48:30 <mrvn> The later wouldn't even violate the C standard
11:48:42 <graphitemaster> I can live without range checks but we really badly need a native language with enclosures
11:48:54 <graphitemaster> and then async/await using the node.js event loop as a runtime
11:50:52 <mrvn> graphitemaster: would enclosures be pass by value or pass by reference?
11:51:44 <graphitemaster> I'm thinking every object would have an implicit reference count and an enclosure would increment it and take it by reference
11:52:13 <graphitemaster> you could do manual free and delete on the objects but if their ref counts are not zero that would just enqueue them to be freed later by the event loop
11:52:16 <mrvn> Then you quickly have memory leaks because someone makes a cycle.
11:52:41 <graphitemaster> don't allow cycles
11:52:58 <mrvn> then you don't have doubly linked lists or graphs. bad.
11:53:15 <graphitemaster> not really
11:53:29 <mrvn> how do you even test for that at compile time?
11:53:35 <graphitemaster> same way Rust does
11:53:50 <mrvn> Rust doesn't reference count
11:53:52 <graphitemaster> only allow one owner of an object at a time
11:55:41 <mrvn> FYI: reference counting uses up extra memory and isn't faster than garbage collection.
11:57:57 <mrvn> graphitemaster: have you used enclosures in C++ much?
11:59:59 <mrvn> In C I think you could make your own closures with cpp macros using typeof, assign and such. Should work with gcc and clang but probably not other compilers.
12:04:57 <bauen1> mrvn: but referenece counting is predictable (mostly anyway) and should be faster than GC (you only have to check / free when a reference is "lost" and don't periodically have to check everything)
12:05:09 <bauen1> as far as i understand gc atleast
12:07:45 <mrvn> bauen1: you have to check every time a reference is decremented. It averages out.
12:08:11 <mrvn> bauen1: a modern GC is considered as fast as malloc/free
12:08:21 <bauen1> well, reference counting is still predictable
12:08:39 <graphitemaster> right but you're proposing reference counting for the purposes of automatic memory management, I'm proposing reference counting to prevent early explicit memory management from occuring
12:08:44 <mrvn> bauen1: only if you know the count is zero.
12:08:51 <graphitemaster> mine is cheaper because the reference count is only checked on an explicit free
12:09:05 <graphitemaster> it's just to prevent the situation where you extended the lifetime of an object into an enclosure
12:09:10 <mrvn> graphitemaster: and constantly in the event loop
12:09:18 <graphitemaster> no
12:09:31 <mrvn> "to be freed later by the event loop"
12:09:50 <graphitemaster> the event loop contains a set of queued functions, in this case "free", they will attempt to call and on failure they get pushed back onto the queue
12:10:05 <mrvn> so: and constantly in the event loop
12:10:20 <graphitemaster> yeah but not every reference and not constantly
12:10:42 <graphitemaster> because first they need to be put on the queue to begin with and second if they exist long enough on the queue to become a problem (checked many times)
12:10:47 <graphitemaster> then that signifies a bug in your code
12:11:03 <graphitemaster> in terms of memory management
12:11:39 <mrvn> So when you have a long lived colsure then the closure has to call free instead of the function that called new?
12:12:07 <mrvn> graphitemaster: I think you are combining the worst of both worlds.
12:12:20 <graphitemaster> of course, what will most likely happen is someone will write like "int *x = new int; pin(x); delete x;"
12:12:29 <graphitemaster> and be like "look this language has automatic GC"
12:12:33 <mrvn> graphitemaster: excatly my thought.
12:12:55 <graphitemaster> in which case they should be taken out back and shot in the head
12:13:03 <mrvn> graphitemaster: and you have to do that unless you have a pin(x) and pin_calls_free(x)
12:13:20 <graphitemaster> C++ already has this exact problem with enclosures
12:13:35 <graphitemaster> if you want to extend the lifetime into them (other than by copy) you basically are forced to use a shared_ptr
12:13:40 <mrvn> In cc+ that would be a uniq_ptr or shared_ptr.
12:14:12 <graphitemaster> well if you're extending the lifetime of something into an enclosure and you're using a unique_ptr to do it that's considered a copy
12:14:20 <graphitemaster> or at the very least a move
12:14:38 <mrvn> graphitemaster: a move. Otherwise your code is crap (or the object tiny enough to copy)
12:14:53 <graphitemaster> the underlying data may not be copied or moved but the wrapped context into the unique_ptr is being done as a transitive move
12:15:08 <mrvn> the move is the point of uniq_ptr.
12:16:37 <graphitemaster> sure
12:16:48 <graphitemaster> but that doesn't extend the lifetime of an object
12:17:04 <mrvn> no, it moves the ownership
12:17:11 <graphitemaster> that transfers ownership over to someone else that happens to have a longer lifetime
12:17:22 <graphitemaster> if you just want to extend it the only option is shared_ptr
12:17:43 <mrvn> if you yourself still need it then shared
12:18:56 <graphitemaster> there's no such thing as extending the lifetime of an object where the thing handing it off no longer needs it
12:19:15 <graphitemaster> if the thing handing it off no longer needs it than the lifetime of the object is by definition done
12:19:33 <graphitemaster> if the thing that wants it wants ownership then yeah you move it
12:19:53 <graphitemaster> but in the context of the current owner, if you don't need to extend it then the object's lifetime is over
12:20:24 <mrvn> I believe a uniq_ptr does exactly that. If someone still needs it they have ownership of the uniq_ptr. Otherwise it gets freed when it leaves the scope of the last owner.
12:20:47 <graphitemaster> that's why when you implement a move constructor you have to "empty" out the original owner
12:20:52 <graphitemaster> because the destructor is still called
12:20:55 <graphitemaster> the lifetime is up
12:22:29 <mrvn> graphitemaster: that's how the parent functions uniq_ptr looses ownership, the internal pointer gets cleared.
12:22:45 <graphitemaster> right
12:22:55 <graphitemaster> I'm just saying in general for any object that implements a move constructor
12:23:20 <mrvn> the uniq_ptr is just a wrapper to add move semantic to a generic pointer.
12:23:26 <graphitemaster> you still need to clear out the movee's data or set a flag in such a way that the work the destructor does for the movee doesn't actually free resources that were now moved to some other object
12:23:48 <graphitemaster> otherwise you didn't move shit, you made a shallow-copy operator
12:24:08 <mrvn> and thinks would quickly blow up
12:24:08 <pZombie> hello friends
12:24:10 <graphitemaster> and the destructor will cause all sorts of chaos on the newly created moved object
12:30:29 <pZombie> just when you thought you got it stable...
12:31:44 <pZombie> After i tweaked my system for max performance, i am now trying to tweak it towards low power consumption
12:32:21 <pZombie> i turned 5 out of 8 cores off in the BIOS, giving me 3 cores and 6 logical cores
12:33:15 <pZombie> set the voltages to the lowest possible for the CPU in its default frequency and the RAM to 1.07v from 1.2 default
12:34:20 <pZombie> but i came to realize, that i cannot really do all that much. The most important factor for a low energy consumption system seems to be its ground state. When you are basically doing nothing, other than having it powered on
12:34:42 <olsner> on linux you can disable CPUs at runtime using files in /sys/, should be a bit easier to manage than rebooting into bios
12:35:06 <olsner> now get powertop and look at the rest of the hardware, which probably used more power than your idle cpus anyway
12:35:23 <pZombie> olsner, good to know. However, as i use the computer currently, i don't really need more than 3 HT cores.
12:36:13 <pZombie> even fortnite, the only game i play currently, gives me the same 100 fps at 1440p with AA turned off in mid settings, same as before with this undervolted and slightly underclocked 7970 dinosaur in the system still
12:36:59 <pZombie> but this x99 5960x system will nevertheless draw a minimum of around 40w when doing nothing
12:37:45 <pZombie> there is a monitor program called hwinfo which seems to be extremely powerful at reading sensors
12:38:05 <pZombie> here is a screenshot of the most important sensors on my system, using hwinfo https://i.imgur.com/BaOzV2T.png
12:38:55 <pZombie> it is the only monitor which can read my motherboard's VRM input/output and my RAM temperatures. Did not even know they have the sensors for it
12:40:08 <pZombie> I was wondering if the 31w the VRM readings this monitor shows me is the total power consumption of the whole system, sub the graphics card
12:40:23 <pZombie> might have to get a watt-o-meter to confirm
12:41:00 <pZombie> the monitor shows me the detailed power consumption of my GPU as well. (not sure if real or estimate)
12:46:08 <pZombie> So basically, if i wanted a real energy efficient system, i would have to look for a system which runs at extremely low watts when in its ground state (doing nothing) AND consumes a small amount of kilojoules/energy when faced with a number of pipelined/tasks in sequence which would constitute the average workload profile of I
12:47:36 <bcos_> pZombie: What's your PSU rated for?
12:48:18 <pZombie> bcos - it's a 1050w seasonic gold efficiency. Don't need that many watts anymore
12:48:23 <bcos_> Heh
12:49:04 <bcos_> The efficiency of PSU isn't linear - might be 90% efficient at 1050W, 50% efficient at 500w and 20% efficient at 10W
12:49:27 <pZombie> actually, the rating is for a 50% load
12:49:46 <bcos_> ..so by saving power at CPU (and RAM and GPU) a lot of the saved power gets gets wasted due to less efficiency PSU
12:50:49 <mrvn> a major factor is also the sleep mode the idle thread uses and how often/long.
12:50:59 <mrvn> GPUs have sleep modes too
12:51:47 <mrvn> a power saving CPU can even power off induvidual function units cycle by cycle.
12:52:56 <pZombie> well, no matter what i do with this system, it has become a dinosaur now when compared to highly efficient intel NUCs with a J5005 quad core CPU that draw about 5 watts in their idle state and only about 10 watts when fully utilized
12:53:20 <pZombie> yet the J5005 is fully capable of running all every day tasks sub gaming i guess
12:54:01 <pZombie> my motherboard alone probably consumes more than the whole J5005 NUC
12:54:10 <pZombie> same as with my GPU
12:54:24 <mrvn> games are the only thing that really use those
12:56:35 <pZombie> bcos the unit is quite efficient even if 1050w sounds much. It even turns off the fans for less power/noise when under about 300w (don'T remember the exact value)
12:56:43 <mrvn> and games are still notoriously bad at multithreading
12:56:49 <pZombie> bcos_, http://www.jonnyguru.com/modules.php?name=NDReviews&op=Story4&reid=401 here you can see an efficiency table of the unit reviewed
01:02:07 <mrvn> I wonder: Should I even have a malloc/free syscall? It's not like C code returns memory to the kernel on free() most of the time. And with demand page loading why have malloc()?
01:02:42 <klange> neither malloc nor free are or should be system calls
01:03:17 <mrvn> klange: obviously I mean the syscalls that the malloc/free implementation uses internally
01:03:29 <bcos_> mmap/munmap?
01:03:40 <mrvn> bcos_: for example
01:03:59 <mrvn> (s)brk traditionally
01:04:46 <mrvn> I don't have mmap for files and no swap. So adding them just for malloc() wouldn't be free.
01:05:18 * bcos_ would just have a "change type of pages in the range starting at <start> and ending at <end> to <type>", where "<type>" is anything (e.g. unallocated, allocate on write, allocated, memory mapped file, ...)
01:05:30 <bcos_> ..without kernel attempting to find a suitable virtual address
01:05:50 <pZombie> mrvn, can you connect a usb monitor to the NAS and run it as a desktop?
01:05:57 <klange> You need some way to request memory - just paging in anything the application asks for means you can't have traps on bad memory accesses... and it's generally a good idea to be able to relinquish memory to the system (though not necessarily required)
01:06:02 <bcos_> ..and with user-space library using that to implement mmap, munmap, (s)brk, whatever
01:06:09 <mrvn> pZombie: pretty sure. It has 2 USB3 connectors
01:07:00 <mrvn> klange: well, don't write buggy code. :) But yeah, the ability to segfault on random memory access is the only reason I can think of for havving syscalls to change memory mappings.
01:08:49 * bcos_ would also have "hints" - whether you want "secure" or "fast" (e.g. with/without encryption on modern CPUs), whether you want bandwidth or latency (e.g. for NUMA optimisation), whether you want volatile or non-volatile, ...
01:09:10 <bcos_> ..whether you want write-back or write-through or write-combining or..
01:09:15 <mrvn> bcos_: I trying to keep this KISS.
01:09:53 <bcos_> Ah - for KISS, a system where every task gets 2 MiB of RAM and never more or less would be very simple..
01:10:09 <mrvn> bcos_: exactly. Except I was thinking 2GB.
01:13:51 <mrvn> I kind of do have a free() syscall. The kernel uses message passing and the physical memory behind a message transfers on call. So to free memory I only need a NOP syscall that eats all messages.
01:14:55 <mrvn> So the app could say "I don't need these pages anymore" and on the next access to the virtual address it gets blank pages again.
01:25:28 <pZombie> the idle power draw of the hades canyon gaming NUC is impressive. 13.5 watts only http://www.legitreviews.com/intel-hades-canyon-nuc8i7hvk-nuc-review-radeon-rx-vega-m-gpu_204024/5
01:27:01 <SopaXorzTaker> I've figured out that writing an efficient text editor is a non-trivial task
01:27:27 <SopaXorzTaker> like, you can of course have all your text as a big string, but then it's really inefficient to render and edit
01:29:07 <pZombie> even if you use asm to edit the string directly at its memory location?
01:29:18 <klange> a typical approach is to have each line as a flexible array
01:31:08 <klange> SopaXorzTaker: you can see how i do it https://github.com/klange/bim
01:31:35 <SopaXorzTaker> klange, I figured out my own approach
01:32:04 <SopaXorzTaker> I make a linked list of lines that can be operated upon (insert / remove / replace etc is very easy to do)
01:33:56 <mrvn> SopaXorzTaker: split the string at the place where the cursor is
01:34:15 <mrvn> SopaXorzTaker: and look at ropes
01:36:20 <klange> ropes are seriously overkill for an interactive text editor
01:37:43 <pZombie> mrvn sounds like dynamically creating a linked list
01:39:48 <lkurusa> that's a comonad
01:39:54 * lkurusa hides
01:41:20 <ybden> klange: no? ropes/gap buffers are a fairly common approach afaik
01:42:44 <klange> whether or not they are used or common has no bearing on whether they are overkill
01:46:02 <pZombie> if i was to write a text editor, i would use two 32bit sequences per character. One 32bit seq for the character itself and the other 32bit sequence for either the memory location to the next character or zero for if the next memory location is just next to it. Inserting a character would be a matter of setting this second 32bit sequence.
01:46:10 <pZombie> What would be wrong with my approach?
01:46:50 <klange> that's a lot of wasted space for next pointers for the vast majority of text, for one
01:47:01 <glauxosdever> What about moving up one line (or back one column)?
01:48:26 <pZombie> I guess you would have to program a text editor to really grasp the full complexity of the matter
01:48:31 <pZombie> learning by doing
01:48:58 <shakesoda> i have definitely always done my text editors as klange described
01:49:48 <shakesoda> not that i've ever really gone crazy with editor features/perf
01:49:55 <klange> i've written multiple line editors, and only one full text editor, but it's far more bogged down by inefficient redraws than any of its text operators
02:17:39 <mrvn> pZombie: 32bit don't hold a pointer
02:18:10 <bcos_> mrvn: It's a 16-bit segment and a 16-bit offset
02:18:22 <mrvn> bcos_: that's more like it. :)
02:18:25 <pZombie> well, maybe it won't be a pointer, but an offset within my reserved memory space
02:18:43 <mrvn> bcos_: but do we really need to support files larger than 65535 bytes? Seriously?
02:18:59 <bcos_> It's funny, because "edit.com" didn't
02:19:21 * shakesoda looks at this rather large source file...
02:19:28 <shakesoda> nope... definitely... not
02:33:55 <pZombie> some news on linux on dex (running full linux on specific samsung phones/tablets) https://www.notebookcheck.net/Samsung-s-Linux-on-DeX-will-let-you-run-desktop-Linux-on-your-Android-phone.358061.0.html
02:34:08 <pZombie> there is apparently a beta program one can sign up for until the 14th dec
02:37:44 <mrvn> every android phone already runs linux
02:38:15 <pZombie> yes, but i am talking about installing any linux distro capable of running on ARM
02:38:53 <mrvn> The hard part is: Can you still make a phone call after that?
02:38:53 <pZombie> not being restricted by what android OS can do
02:40:02 <pZombie> that won't be an issue if you use the galaxy tab s4 to run linux on dex assuming it cannot be used as a phone
02:43:53 <pZombie> the galaxy tab s4 is more interesting it appears since you have a much larger screen for the stylus, plus you can turn it into a notebook with the keyboard attachment
02:48:16 <asymptotically> mrvn: a phonecall on a smartphone? that's crazy, nobody does that
03:01:32 <pZombie> asymptotically, that is actually almost true in my case. I don't use my smartphone, except when i am on the road for emergency calls if required. Other than that, i just need it for taking photos and use it as a gps nav. But i am pretty sure that the custom tailored ubuntu samsung is preparing for linux on dex will allow you to accept phonecalls while using a full linux desktop
05:33:54 <rakesh4545> Hello
05:37:57 <rakesh4545> What does cache penalty consists of?
06:05:38 <rakesh4545> Does any one knows how to calculate average memory access time for a cache mem with given hit and miss ratio and cache and memory access time?
06:11:12 <rakesh4545> This kind of silence is creepy. Is everyone okay?
06:11:53 <eryjus> all good here! Just don't have a valid answer for you.
06:12:29 <rakesh4545> That is fine. I thought aliens abducted everyone.
06:12:52 <eryjus> or maybe you were abducted...?? lol
06:13:50 <rakesh4545> No no. Not yet
06:15:45 <rakesh4545> Maybe I asked my question in wrong place. This is more architecture based question than os.
06:29:02 <lava> depends on memory and cache timing
06:46:57 * geist yawns
06:47:15 <geist> good morning folks
06:48:20 <rakesh4545> What is the time there?
06:48:20 <glauxosdever> YAWN!
06:48:45 <rakesh4545> Goodmorning.
06:49:25 <geist> you said it
06:49:50 <glauxosdever> geist: YAWN! is the new meme. ELTORITO! is the old one
06:50:25 <aalm> .theo
06:50:26 <glenda> In that situation, you would probably want to be left in piece.
06:50:35 <aalm> .roa
06:50:35 <glenda> 121 Everything is for sale, even friendship.
06:50:50 <glauxosdever> And THREADRIPPER! is almost as old as ELTORITO! but 256x more obsolete.
06:50:56 <rakesh4545> we live on opposite ends of this world.
06:52:08 <geist> EL TORITO!
06:53:34 <rakesh4545> Good night.
06:56:09 <geist> nite!
08:25:02 <mra90> when I try to connect from gdb to remote gdb_deamon, it receives few command then after a while prints "Bad register packet; fetching a new packet"
08:25:06 <mra90> then "Timeout". What is wrong?
08:27:43 <geist> beats me. are you on x86? what are you debugging?
08:29:37 <mra90> geist: I am on ubuntu and run gdb, connect to remte target by tcp:ip:port
08:30:07 <mra90> that remote target is python deamon run on Windows 7
08:30:21 <geist> then i have absolutely no idea what your problem is
08:30:52 <geist> my only thought is it's a mismatch between x86-32 and x86-64
08:31:09 <geist> which is a problem when using gdb with qemu. doesn't handle bitness transitions well
08:32:55 <mra90> geist: what is qemu?
08:33:19 <mra90> I think it should not be a problem
08:33:22 <geist> a system emulator that people write operating systems on
08:34:00 <mra90> right after I establish communication with deamon gdb sends "Sending packet: $Hg0#df...Ack"
08:34:24 <geist> i assumed since you came to an osdev channel that you're writing bare metal kernel code
08:34:28 <geist> sice that's usually why people are here
08:35:00 <mra90> Not true.
08:35:19 <geist> okey dokey
08:35:47 <mra90> going back to the problem, it exchanges several mesages with deamon
08:35:55 <mra90> with the last OK one: "Sending packet: $p2b0#34...Ack"
08:36:11 <mra90> right after that: "Bad register packet; fetching a new packet" and then "Timeout"
08:36:15 <mra90> does it make any sense?
09:16:21 <mrvn> does the python daemon agree about the "fetching new packet"?