256 possible order. What is the fastest code?

Index > Main > 256 possible order. What is the fastest code?

Goto page Previous 1, 2, 3, 4, 5, 6

Author

Thread

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20518
Location: In your JS exploiting you and your system

revolution 24 Aug 2022, 22:37

DimonSoft wrote:

Ha-ha, cool ad hominem case. Nothing said about the cost of writing and functionally testing multiple implementations chosen blindly before actually doing measurements (or do you always write code with no bugs for even corner cases, or measure performance for code that doesn’t yet work right?). I’d love to see the world where every boss is ready to pay for unlimited research, yet most (luckily not all) companies I’m aware of are more willing to release some good-enough-but-as-fast-as-possible-within-the-time-limits version.

That assumes a single use case. Your "release it" scenario doesn't apply to every situation.

It is possible to have code running on the systems which isn't yet optimised, but is good enough, for the meantime, and over time improve it. It might never be "released" since it isn't end user code.

24 Aug 2022, 22:37

DimonSoft

Joined: 03 Mar 2010
Posts: 1228
Location: Belarus

DimonSoft 25 Aug 2022, 06:07

revolution wrote:

That assumes a single use case. Your "release it" scenario doesn't apply to every situation.

It is possible to have code running on the systems which isn't yet optimised, but is good enough, for the meantime, and over time improve it. It might never be "released" since it isn't end user code.

That assumes the most common use case. Code is generally written to be released and used by its intended users to solve real-world tasks. Purely researching something is a corner case.

So, when someone asks for guidance it’s a perfectly valid assumption that they are going to release some day, and thus are eager to save some time looking for alternative implementations to try. When there’s no time limitations, there’s no need to ask for guidance, just brute-force all possible implementations and see if they work better.

BTW, one’s lifetime might also be a limitation. Whenever your algorithm contains a loop with variable iteration count, the number of tests that should be run to perform full testing becomes nearly infinite. Lifetime is not. (We don’t want solutions that are good with one iteration count but not the other, right?)

25 Aug 2022, 06:07

Fastestcodes

Joined: 13 Jun 2022
Posts: 75

Fastestcodes 25 Aug 2022, 09:40

macomics wrote:

Fastestcodes wrote:
L00 Lff does't compile. Why?
For example, because of Lea

The name of one or more labels matches the name of the command.

Yes.Thx.
"error invalid argument"only
I changed Lea to Lead.It works.

25 Aug 2022, 09:40

Furs

Joined: 04 Mar 2016
Posts: 2595

Furs 25 Aug 2022, 13:29

macomics wrote:

revolution wrote:
All sorts are slower than some other sort, and all sorts are faster than some other sort. It all depends on your usage.

The data set will dictate which sort works best.

I agree with that. I was talking about the choice when I had already come to the dilemma of which algorithm to choose, when it was already clear that a common method would have to be used for sorting. The advantage of tsort is that it performs fewer comparison operations compared to qsort and fewer permutations in general.

Yeah, I personally also like merge sort since it's also easy (and qsort has bad worst-case, which is something to keep in mind, if you don't know the data), it was just a hypothetical example don't fixate on it so much.

Anyway I agree with DimonSoft exactly here.

25 Aug 2022, 13:29

Furs

Joined: 04 Mar 2016
Posts: 2595

Furs 25 Aug 2022, 13:32

revolution wrote:

All sorts are slower than some other sort, and all sorts are faster than some other sort. It all depends on your usage.

The data set will dictate which sort works best.

OK, but if you don't know the data, you look at factors such as: worst-case, random data inputs, etc. There is no point in testing/optimizing for a particular data pattern if you don't know the data.

If you do know the data then optimize for the data accordingly, but hey, I'm moving goal posts if I'm suggesting stuff like RLE earlier, so... Rolling Eyes

Testing skewed data when you don't want to assume such data is just playing Devil's Advocate without doing anything useful. Unless you want to test the worst-case of course, that's totally fine to test.

This is super important for hash tables for example, which is why I tend to back them with binary trees, so it doesn't blow up on rare data patterns (Java's hash table does something similar I heard).

25 Aug 2022, 13:32

Goto page Previous 1, 2, 3, 4, 5, 6

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum