2024-05-18 11:04:27 let's say in the stack i have a very long string, now i want to calc hash, say sha512 which is computationally intensive, should i pop the big string or just peek data from it? sometimes an user wants the original data along with an hash digest to compare/sign and so on, what are your thoughts? 2024-05-18 11:06:45 I wouldn't have a long string on the stack itself, I'd store it in memory and just have a pointer to it on the stack 2024-05-18 11:08:54 GeDaMo, that's not how my Forth works 2024-05-18 11:08:56 it hasn't pointers 2024-05-18 11:10:49 Is the stack all of memory? 2024-05-18 11:11:38 the stack in my Forth is a Vec 2024-05-18 11:11:47 where Atom are strings, integers, floats 2024-05-18 11:11:58 its an higher level Forth 2024-05-18 11:14:02 So you can just dup the whole string? 2024-05-18 11:14:39 yep, and its reference counted 2024-05-18 11:14:41 so its cheap 2024-05-18 11:36:12 you can't expect high peformance and never go into the low level 2024-05-18 11:38:16 not even C is capable of that 2024-05-18 11:39:17 seems to me you need a new data type called "chunk" or aperators/words for it 2024-05-18 11:39:41 Whole array/string operations like map and fold/reduce 2024-05-18 11:41:29 is't the whole idea of optimizing compilers about expecting high performance and never going into the low level? 2024-05-18 11:42:26 Compilers aren't magic, they can only perform transformations implemented by the compiler writer 2024-05-18 11:44:01 I don't disagree with that statement (although it does not contradict what I've said above) 2024-05-18 11:44:52 i.e it is possible to write high performant program in a high level language without caring about low level details /under certain circumstances/ 2024-05-18 11:45:03 True 2024-05-18 11:45:27 i.e sometimes it is not possible to prove, that a certain optimization would be semantically valid (because high level code drops a ball with signaling some programmer intent) 2024-05-18 11:45:40 but that's not always the rule 2024-05-18 11:46:53 nobody said it wasn't. The truth remains that a competent assembly programmer will always beat the compiler 2024-05-18 11:48:50 I don't share this sentiment about truth! :) 2024-05-18 11:49:13 compiler may come up with things that look very unnatural to any competent programmer, yet they may be more friendly to the cache (for example) 2024-05-18 11:50:00 there's a big difference here between an optimizer and a programmer 2024-05-18 11:50:30 there's cases where performance is so primary that the compiled binary is used only as a reference 2024-05-18 11:52:26 patching the resulting assembly as you go 2024-05-18 11:52:32 that's off-topic, optimizing optimized program is compiler+programmer vs compiler alone, not programmer vs compiler; 2024-05-18 11:53:28 I like this optimization https://blog.regehr.org/archives/320#example7 2024-05-18 11:53:53 its not off topic at all, you said that the idea of an optimizing compiler is to never go low level. 2024-05-18 11:54:25 now, maybe we might never have to go low level but I'm not that interested in performance 2024-05-18 11:55:11 hell, sometimes optimizing does the wrong thing https://research.swtch.com/ub 2024-05-18 11:55:22 which is why you should always compile in -02 2024-05-18 11:55:37 its always programmer vs compiler 2024-05-18 11:55:40 what are you even 2024-05-18 11:57:47 I think that you have a very strong opinion about things, so well, OK - I don't see a point in arguing over opinions 2024-05-18 11:57:59 sorry 2024-05-18 13:29:26 rendar: i would pop it. the user may already have it stored some other way, so if you leave it, then all you've done is force them to nip 2024-05-18 15:43:08 zelgomer, i see, thanks 2024-05-18 17:22:27 I think there's no doubt that compiler optimization has gotten very good, and will likely get better as time goes on - both in approaching optimal performance and in avoiding functional mistakes. But I don't see any reason a "good enough" programmer who invested sufficient time wouldn't get results just as good. What the optimizing cmpiler really buys you is that time - it would take the human programmer 2024-05-18 17:22:29 longer to approach the optimal result. Also, since the human programmer needs to be a really good one, the compiler can allow a greater number of people to get the good result, even ones who might not be able to do it by hand. So the compiler won't produce results that are "better" than those of the BEST programmers, but likely will outdo the AVERAGE programmer. 2024-05-18 17:23:08 I do think there might be special cases, where the programmer might "know something" about what the inputs are going to look like that you can't derive from the algorithm. That might let him or her use optimizaitons not eveident to the compiler. 2024-05-18 17:23:40 We could probably invent ways to convey those input restrictions to the compiler, though. 2024-05-18 17:25:59 The compiler doesn't know what you want, it only knows what you tell it :P 2024-05-18 17:26:14 Right. 2024-05-18 17:26:43 you might get worried if the compiler is asking for more resources and nuclear launch codes 2024-05-18 17:26:44 We have done something like that in that case where we can give the compiler hints about which way conditional branches are more likely to go. 2024-05-18 17:27:04 +KipIngram> Also, since the human programmer needs to be a really good one 2024-05-18 17:27:12 in my experience this is demonstrably false 2024-05-18 17:28:08 oh, NEEDS to be a really good one. for some reason i read TENDS to be a really good one. nevermind 2024-05-18 17:30:40 objectively more performant program may be unreadable one, and even best programmers would not implement things in such a way unless forced to by constraints 2024-05-18 17:31:05 sure, I share the sentiment; groking how things work under the hood is one of hacker joys 2024-05-18 17:31:44 The problem with relying on the compiler is that sometimes the compiler doesn't do what you want and updates can change behaviour 2024-05-18 17:32:31 E.g. the only way you can know if a C compiler has vectorized your code is by looking at the asm output 2024-05-18 17:32:32 Yes, your tools are controlled by others. 2024-05-18 17:32:35 there are plenty of counter-examples though where a human writing better code than the compiler actually runs slower. the intricacies of modern x86 that the compiler is programmed to know about are not things even the best programmer would just know 2024-05-18 17:32:43 but after they did, I don't think there is much reason to always roll implementation of a thing from scratch; not trusting abstractions is a dead end (and not understanding them is another dead end) 2024-05-18 17:32:52 Great thing about a Forth you've written yourself is precisely that you know exactly what it's going to do, all the time. 2024-05-18 17:33:14 KipIngram: that;s true of unoptimized C code too :) 2024-05-18 17:34:03 Up to a point I guess. You usually didn't write that compiler. 2024-05-18 17:34:19 But I agree that with optimizaiton off it's generally more reliable. 2024-05-18 17:34:43 Those parts of it are nlikel to go changing on you much. 2024-05-18 17:34:57 unlikely 2024-05-18 17:36:09 "k/simple a tiny k interpreter for educational purposes by arthur whitney" https://github.com/kparc/ksimple 2024-05-18 17:36:09 The ref directory contains the code as originally written by Arthur Whitney, I think he might be allergic to spaces :P 2024-05-18 17:39:10 lol I guess you would write C like that if you learned apl first 2024-05-18 17:46:53 I like concise but that's a little too terse for me :P 2024-05-18 21:53:23 i still think the results of /mod are backwards from what they should be. i screw this up every time.