Hi! I wonder what's the typical SVM training time on your side for the 50000 samples? I ran on a very good machine. 20 minutes passed and it seems it will still go on for ever... (Should I add the "-h 0" suggested by libsvm to speed up?)
\r\nThanks!
", "messages": [ { "id": "5881", "postDate": "10/04/2011 03:25:18", "content": "Hi! I wonder what's the typical SVM training time on your side for the 50000 samples? I ran on a very good machine. 20 minutes passed and it seems it will still go on for ever... (Should I add the "-h 0" suggested by libsvm to speed up?)
\r\nThanks!
", "rawMarkdown": "", "votes": null }, { "id": "5885", "postDate": "10/04/2011 07:47:12", "content": "I have the same issue with libsvm; Furthermore, using probabilities make the runtime even worse. I now use liblinear for my submissions, instead of probabilities I submit the confidence scores - this is really fast (less than a minute) and gives comparable\r\n results (though libsvm and liblinear optimize slightly different objective functions)
\r\nbest,
\r\nPeter
I just got started on this a few days ago, so I'm a bit behind the curve...
\r\nDid anybody "solve" the svm-train run-time problem, or at least determine whether or not this is normal behavior?
\r\nI ask because, like the original poster, I have a decent quad-core processor and adequate memory, but svm-train seems to be taking forever; nearing an hour at the moment, which seems extreme for 50,000 samples. I don't usually use libsvm - I wrote my own\r\n kernel machine library/utilities years ago - but I'm trying not to stray too far off the path due to the severe time constraint. And learning how to use a new tool is rarely a bad thing.
\r\nIf it matters, the exact command (executed from the host's perl script) is:
\r\nsvm-train -s 0 -t 0 -c 1.0 -b 1 tmp.train.txt tmp.model.txt
\r\nAny advice or assistance is appreciated. Otherwise I guess I'll just let it run until it either completes or dies.
\r\n------------------
\r\nUpdate: 3 hours and counting? What the heck?
", "rawMarkdown": "", "votes": null }, { "id": "6009", "postDate": "10/11/2011 01:39:28", "content": "I'm at 48 hours of runtime for libsvm & counting, just trying to recreate the K-means results described on the "Benchmark minibatch k-means, step by step" thread. This is pretty ridiculous. (I also wonder, how did libsvm get picked for this contest\r\n if the runtime is this bad?) Anyway, I'm going to try liblinear tonight on a different core (specifically, the LiblineaR package in R).
\r\nUPDATE: I tried LiblineaR & it's much much faster, just like Peter reported above (1 to 2 minutes on the 50k rows).
", "rawMarkdown": "", "votes": null }, { "id": "6010", "postDate": "10/11/2011 02:02:38", "content": "Wow, that's terrible. Libsvm ran in about 10 minutes on my laptop, so we thought it would be okay for general use.\r\n
\r\nI'll do some comparison tests with liblinear tomorrow to make sure the results are consistent with libsvm, and assuming they are it should be fine to use either package.\r\n
", "rawMarkdown": "", "votes": null }, { "id": "6016", "postDate": "10/11/2011 05:09:42", "content": "Another update: I don't have Chris' patience, so I killed svm-train after 5 hours.
\r\nRather than skip right to liblinear I first tried building a "tuned" version of libsvm by making it multicore (-fopenmp and #pragma ... - as spelled out in the libsvm FAQ). I also added the appropriate -march and -mtune to CFLAGS. Not much difference except\r\n that it cranked my CPU usage from 100% to 200% because of openmp (it would have been 400%, but the other 2 cores are currently very busy crunching HHP data so I set OMP_NUM_THREADS=2). In any case it still looked like it would run forever.
\r\nAfter reading a little more about libsvm, it seemed like there might be a data scaling problem that was preventing convergence. I had the same problem with my own SVM implementation way back when, and as a result mine scales the data by default (although\r\n there is a command-line flag to leave it unscaled). I wrongly assumed that libsvm would behave the same way. Not very bright of me. My solution: Create a modified version of runLeaderboardEval.pl that uses svm-scale on both the train and test data.
\r\nThe result: svm-train finished in 18 minutes using 2 cores (although with a plethora of "Warning: using -h 0 may be faster" messages). I'll check the data to make sure it makes sense, but for now this seems to have solved my problem.
", "rawMarkdown": "", "votes": null } ], "comments": [ { "id": 5885, "author_name": "pprett", "author_url": "", "post_date": "10/04/2011 07:47:12", "content": "I have the same issue with libsvm; Furthermore, using probabilities make the runtime even worse. I now use liblinear for my submissions, instead of probabilities I submit the confidence scores - this is really fast (less than a minute) and gives comparable\r\n results (though libsvm and liblinear optimize slightly different objective functions)
\r\nbest,
\r\nPeter
I just got started on this a few days ago, so I'm a bit behind the curve...
\r\nDid anybody "solve" the svm-train run-time problem, or at least determine whether or not this is normal behavior?
\r\nI ask because, like the original poster, I have a decent quad-core processor and adequate memory, but svm-train seems to be taking forever; nearing an hour at the moment, which seems extreme for 50,000 samples. I don't usually use libsvm - I wrote my own\r\n kernel machine library/utilities years ago - but I'm trying not to stray too far off the path due to the severe time constraint. And learning how to use a new tool is rarely a bad thing.
\r\nIf it matters, the exact command (executed from the host's perl script) is:
\r\nsvm-train -s 0 -t 0 -c 1.0 -b 1 tmp.train.txt tmp.model.txt
\r\nAny advice or assistance is appreciated. Otherwise I guess I'll just let it run until it either completes or dies.
\r\n------------------
\r\nUpdate: 3 hours and counting? What the heck?
", "votes": null, "replies": [] }, { "id": 6009, "author_name": "chefele", "author_url": "", "post_date": "10/11/2011 01:39:28", "content": "I'm at 48 hours of runtime for libsvm & counting, just trying to recreate the K-means results described on the "Benchmark minibatch k-means, step by step" thread. This is pretty ridiculous. (I also wonder, how did libsvm get picked for this contest\r\n if the runtime is this bad?) Anyway, I'm going to try liblinear tonight on a different core (specifically, the LiblineaR package in R).
\r\nUPDATE: I tried LiblineaR & it's much much faster, just like Peter reported above (1 to 2 minutes on the 50k rows).
", "votes": null, "replies": [] }, { "id": 6010, "author_name": "argv", "author_url": "", "post_date": "10/11/2011 02:02:38", "content": "Wow, that's terrible. Libsvm ran in about 10 minutes on my laptop, so we thought it would be okay for general use.\r\n
\r\nI'll do some comparison tests with liblinear tomorrow to make sure the results are consistent with libsvm, and assuming they are it should be fine to use either package.\r\n
", "votes": null, "replies": [] }, { "id": 6016, "author_name": "clueless0", "author_url": "", "post_date": "10/11/2011 05:09:42", "content": "Another update: I don't have Chris' patience, so I killed svm-train after 5 hours.
\r\nRather than skip right to liblinear I first tried building a "tuned" version of libsvm by making it multicore (-fopenmp and #pragma ... - as spelled out in the libsvm FAQ). I also added the appropriate -march and -mtune to CFLAGS. Not much difference except\r\n that it cranked my CPU usage from 100% to 200% because of openmp (it would have been 400%, but the other 2 cores are currently very busy crunching HHP data so I set OMP_NUM_THREADS=2). In any case it still looked like it would run forever.
\r\nAfter reading a little more about libsvm, it seemed like there might be a data scaling problem that was preventing convergence. I had the same problem with my own SVM implementation way back when, and as a result mine scales the data by default (although\r\n there is a command-line flag to leave it unscaled). I wrongly assumed that libsvm would behave the same way. Not very bright of me. My solution: Create a modified version of runLeaderboardEval.pl that uses svm-scale on both the train and test data.
\r\nThe result: svm-train finished in 18 minutes using 2 cores (although with a plethora of "Warning: using -h 0 may be faster" messages). I'll check the data to make sure it makes sense, but for now this seems to have solved my problem.
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "5881": "", "5885": "", "6004": "", "6009": "", "6010": "", "6016": "" }, "source": "meta" }